JEP 284: New HotSpot Build System

AuthorMagnus Ihse Bursie
OwnerErik Joelsson
Created2015/03/26 08:52
Updated2017/01/20 13:02
TypeInfrastructure
StatusClosed / Delivered
Componentinfrastructure / build
ScopeImplementation
Discussionbuild dash infra dash dev at openjdk dot java dot net
EffortL
DurationL
Priority2
Reviewed byIris Clark, Mikael Vidstedt
Endorsed byMikael Vidstedt
Release9
Issue8076052

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:

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:

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

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.