跳到主要内容

JEP 284: New HotSpot Build System

Summary​

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.