JEP draft: Include default CDS archive in JDK binary

AuthorsJiangli Zhou, Calvin Cheung, Ioi Lam
OwnerJiangli Zhou
TypeFeature
ScopeJDK
StatusSubmitted
Componenthotspot / runtime
Discussionjdk dash dev at openjdk dot java dot net
EffortM
DurationM
Reviewed byErik Joelsson, Ioi Lam, Karen Kinnear, Mikael Vidstedt
Endorsed byVladimir Kozlov
Created2018/06/01 18:48
Updated2018/08/15 23:03
Issue8204247

Summary

Generate a CDS archive using the default classlist at JDK build time; include this archive in 64-bit binary distributions of the JDK.

Goals

Non-Goals

Motivation

Numerous enhancements have been added to the base CDS feature since JDK 8u40. The startup time and memory sharing benefits provided by enabling base CDS have increased significantly. Measurements done on linux-x64 using an official JDK 11 binary (JDK 11 EA build 11-ea+14) show 32% JVM startup time reduction running HelloWorld. On other 64-bit platforms, similar or higher startup performance gains have been observed with base CDS enabled.

Currently, a JDK image includes a default classlist generated at build time in the lib/ directory. For any users who want to take advantage of CDS even with the default classlist provided by the JDK, they need to run -Xshare:dump as an extra step. It would be beneficial to create a default CDS archive (run -Xshare:dump using the default classlist) as part of the build and package the archive together with the JDK binary.

Description

At JDK build time, after linking the image, run 'java -Xshare:dump' (extra command-line options may be included to fine-tune GC heap size, etc., in order to obtain most optimal memory layout for common cases) using the final linked JDK image. Then, copy the created CDS archive into the lib/server directory.

Users who download a JDK binary packaged with a default CDS archive can use CDS feature automatically. Users with more advanced requirements (e.g. using customized class list with application classes, different GC configurations, etc) can still create an archive using the method described in CDS/AppCDS documentation as before.

In JDK 11, -Xshare:auto has been enabled by default for server VM (JDK-8197967). With a default CDS archive included in the JDK binary, the JVM will automatically try to run with CDS enabled. To disable CDS, users need to run with -Xshare:off.

Alternatives

Pre-package the default CDS archive in JDK binary distributions (same as the main proposal of this JEP), but disable -Xshare:auto.

This approach was made as a safety backup -- although CDS has been enabled on Windows (default CDS archive was created by the JDK Windows installer) for many releases, that's not the case for other platforms. If we suddenly enable CDS without the user making a conscious choice, it's possible that some incompatibility may occur, especially in esoteric environments.

If -Xshare:auto is disabled (i.e., we revert JDK-8197967), then even if the default CDS archive is pre-packaged in the JDK, the user would need to explicitly specify -Xshare:auto in the command-line in order to use CDS. This would give the users an "assimilation period" with the pre-packaged CDS archive. We can reinstate JDK-8197967 in a future JDK release when we feel more comfortable.

The advantages of this approach are:

The alternative approach does not change the default JDK behavior immediately. It improves CDS usability with the default archive by eliminating the -Xshare:dump step for common cases. It also provides more testing exposure by providing users the default archive without the risks of changing the default JDK behavior immediately.

The problems with this approach are:

Risks and Assumptions

Testing