JEP 341: Default CDS Archives

Summary

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

Goals

• Improve out-of-the-box startup time
• Eliminate the need for users to run -Xshare:dump to benefit from CDS

Non-Goals

• We will generate the default archive only for native builds, not for cross-compiled builds.
• We will generate the default archive only for 64-bit builds; support for 32-bit builds may be added later.

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:

• It doesn't change the default behavior immediately.
• It improves CDS usability with the default archive by eliminating the java -Xshare:dump step for common cases.
• It provides more testing exposure by providing users the default archive without the risk of changing the default behavior immediately.

The problems with this approach are:

• We would be going back and forth with -Xshare:auto, causing confusion.
• It is based on the incorrect assumption that including the CDS archive is high risk. The CDS default archive has been enabled on Windows (client) for over a decade, and there are rarely any issues.
• Users can test this feature only if they explicitly turn on the -Xshare:auto option. However, users who care (or know) about CDS will have already created CDS archives and modified their command lines for past releases, which means they have already been testing CDS without us shipping a default archive. It's doubtful that this approach would actually result in more testing.

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.