JEP 341: Default CDS Archives

AuthorsJiangli Zhou, Calvin Cheung, Ioi Lam
OwnerJiangli Zhou
TypeFeature
ScopeJDK
StatusIntegrated
Release12
Componenthotspot / runtime
Discussionhotspot dash dev at openjdk dot java dot net
EffortM
DurationM
Reviewed byErik Joelsson, Ioi Lam, Karen Kinnear, Mikael Vidstedt
Endorsed byMikael Vidstedt, Vladimir Kozlov
Created2018/06/01 18:48
Updated2018/11/06 20:50
Issue8204247

Summary

Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

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 CDS have increased significantly. Measurements done on Linux/x64 using JDK 11 early-access build 14 show a 32% startup time reduction running HelloWorld. On other 64-bit platforms, similar or higher startup performance gains have been observed.

Currently, a JDK image includes a default class list, generated at build time, in the lib directory. Users who want to take advantage of CDS, even with just the default class list provided in the JDK, must run java -Xshare:dump as an extra step. This option is documented, but many users are unaware of it.

Description

Modify the JDK build to run java -Xshare:dump after linking the image. (Additional command-line options may be included to fine-tune GC heap size, etc., in order to obtain better memory layout for common cases.) Leave the resulting CDS archive in the lib/server directory, so that it is part of the resulting image.

Users will benefit from the CDS feature automatically, since -Xshare:auto was enabled by default for the server VM in JDK 11 (JDK-8197967). To disable CDS, run with -Xshare:off.

Users with more advanced requirements (e.g., using custom class lists that include application classes, different GC configurations, etc.) can still create a custom CDS archive as before.

Alternatives

Build the default CDS archive but disable -Xshare:auto.

This approach would be safer. CDS has been enabled by default on Windows for many releases, since the default CDS archive was created by the JDK Windows installer, but that's not the case for other platforms. If we suddenly enable CDS without users making a conscious choice then existing applications could be affected if, e.g., they depend upon undocumented aspects of the JVM’s startup sequence.

If -Xshare:auto is disabled (i.e., we revert JDK-8197967) then, even if the default CDS archive is included in the JDK, users would need to explicitly specify -Xshare:auto on the command line in order to use CDS. This would give users an assimilation period with the default CDS archive, after which we could reinstate JDK-8197967 in a future release.

The advantages of this approach are:

The problems with this approach are:

By contrast, with the approach proposed in this JEP many developers will test CDS implicitly when they build the JDK or use an early-access release, clearly resulting in more testing.

Testing

Existing automated testing with CDS enabled is sufficient.