JEP 284: New HotSpot Build SystemJEP 284: New HotSpot Build SystemAuthorMagnus Ihse BursieOwnerErik JoelssonTypeInfrastructureScopeImplementationStatusClosed / DeliveredRelease9Componentinfrastructure / buildDiscussionbuild dash infra dash dev at openjdk dot java dot netEffortLDurationLReviewed byIris Clark, Mikael VidstedtEndorsed byMikael VidstedtCreated2015/03/26 08:52Updated2017/01/20 13:02Issue8076052Summary
Rewrite the HotSpot build system using the build-infra framework.
Goals
The goal of this project is to replace the current build system with a new,
much simplified one, that is based on the build-infra framework. More
specifically:

Leverage the functionality present in the build-infra framework, to minimize
code duplication.
Simplify the HotSpot build system to provide a more maintainable code base
and to lower the threshold for future improvement.

Non-Goals
We expect no specific performance improvement from this change, since the
current HotSpot build system is quite heavily tuned for good performance.
Motivation
The current HotSpot build system contains lots of duplicated code and redundant
functionality that is better handled by the overall build-infra framework. The
structure and flow of information is hard to follow, even for experienced
developers.  This creates a reluctance to fix issues and add new features to the
build system.
The lack of full integration into build-infra is also blocking further
improvements in the overall build process, which could possibly enable more
performance gains in the overall JDK build process.
Description
Building HotSpot is, on a high level, not really different from building any
other native component in the JDK. In essence, we need to call the build-infra
function SetupNativeCompilation() for libjvm.so. In practice, the HotSpot
build has evolved differently from the native libraries in the JDK repo, so
there are several adaptations that need to be done.
Some examples of technical differences:

HotSpot uses precompiled headers, which needs to be supported.
HotSpot uses its own set of compiler flags, which differs from the ones
used in the rest of the product.
libjvm.so is possibly built several times for different variants, such as
server and client.
HotSpot uses several different features that can be enabled or disabled, such
as C1 and JVMCI.
For historical reasons, HotSpot uses different names for platforms and
compilers.

On top of compiling the libjvm.so native library, there are also other
pre-/post-build things that needs to happen, such as:

Creating build tools like the adlc compiler.
Creating gensrc using adlc and the JVMTI tooling.
Dtrace support needs both pre- and post-processing.
Additional libraries such as libjsig.so need to be built.

Testing
The main testing method will be the same as when the JDK build was converted,
that is to use the compare.sh script. By building the product twice, once with
the old build system and once with the new, and then running the compare script,
any differences in the resulting build will be pointed out.
Native build artifacts will never achieve a 100% byte-by-byte equality, since
technical differences will affect even rebuilds using the same build system.
However, any remaining differences as pointed out by the compare script should
be accounted for and explained to be within reason. (For instance, such changes
could be debug data differences due to different build output directories.)
If the build system re-creates the same binary, this should in theory be enough
testing. For safeguarding, a suitable set of normal product tests will also be
run before final integration.
InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
