Class Data Sharing

The Class data sharing (CDS) feature helps reduce the startup time and memory footprint between multiple Java Virtual Machines (JVM).

Starting from JDK 12, a default CDS archive is pre-packaged with the Oracle JDK binary. The default CDS archive is created at the JDK build time by running -Xshare:dump, using G1 GC and 128M Java heap. It uses a built-time generated default class list that contains the selected core library classes. The default CDS archive resides in the following location:

On Linux and macOS platforms, the shared archive is stored in /lib/[arch]/server/classes.jsa
On Windows platforms, the shared archive is stored in /bin/server/classes.jsa

By default, the default CDS archive is enabled at the runtime. Specify -Xshare:off to disable the default shared archive. See Regenerating the Shared Archive to create a customized shared archive. Use the same Java heap size for both dump time and runtime while creating and using a customized shared archive.

When the JVM starts, the shared archive is memory-mapped to allow sharing of read-only JVM metadata for these classes among multiple JVM processes. Because accessing the shared archive is faster than loading the classes, startup time is reduced.

Class data sharing is supported with the ZGC, G1, serial, and parallel garbage collectors. The shared Java heap object feature (part of class data sharing) supports only the G1 garbage collector on 64-bit non-Windows platforms.

The primary motivation for including CDS in Java SE is to decrease in startup time. The smaller the application relative to the number of core classes it uses, the larger the saved fraction of startup time.

The footprint cost of new JVM instances has been reduced in two ways:

A portion of the shared archive on the same host is mapped as read-only and shared among multiple JVM processes. Otherwise, this data would need to be replicated in each JVM instance, which would increase the startup time of your application.
The shared archive contains class data in the form that the Java Hotspot VM uses it. The memory that would otherwise be required to access the original class information in the runtime modular image, is not used. These memory savings allow more applications to be run concurrently on the same system. In Windows applications, the memory footprint of a process, as measured by various tools, might appear to increase, because more pages are mapped to the process’s address space. This increase is offset by the reduced amount of memory (inside Windows) that is needed to hold portions on the runtime modular image. Reducing footprint remains a high priority.

Application Class-Data Sharing

To further reduce the startup time and the footprint, Application Class-Data Sharing (AppCDS) is introduced that extends the CDS to include selected classes from the application class path.

This feature allows application classes to be placed in a shared drive. The common class metadata is shared across different Java processes. AppCDS allows the built-in system class loader, built-in platform class loader, and custom class loaders to load the archived classes. When multiple JVMs share the same archive file, memory is saved and the overall system response time improves.

See Application Class Data Sharing in Java Development Kit Tool Specifications.

Dynamic CDS Archive

Dynamic CDS archive extends application class-data sharing (AppCDS) to allow dynamic archiving of classes when a Java application exits.

It simplifies AppCDS usage by eliminating the trial runs to create a class list for each application. The archived classes include all loaded application classes and library classes that are not present in the default CDS archive.

To create a dynamic CDS archive, start the Java application with the command -XX:+RecordDynamicDumpInfo; don't use this flag with -XX:ArchiveClassesAtExit.

See Using CDS Archives in Java Development Kit Tool Specifications.

Regenerating the Shared Archive

You can regenerate the shared archive for all supported platforms.

The default class list that is installed with the JDK contains only a small set of core library classes. You might want to include other classes in the shared archive. To create a dynamic CDS archive with the default CDS archive as the base archive, start the Java application with the following command:

-XX:+RecordDynamicDumpInfo

A separate dynamically-generated archive is created on top of the default system for each application. You can specify the name of the dynamic archive as an argument to the jcmd <pid or AppName> VM.cds dynamic_dump <filename> command. If you don't specify the file name, then a default file name java_pid<number>_dynamic.jsa is generated, where <number> is the process ID.

To regenerate the archive file log in as the administrator. In networked situations, log in to a computer of the same architecture as the Java SE installation. Ensure that you have permissions to write to the installation directory.

To regenerate the shared archive by using a user defined class list, enter the following command:

jcmd <pid or AppName> VM.cds <subcommand> <filename>

Diagnostic information is printed when the archive is generated.

Manually Controlling Class Data Sharing

Class data sharing is enabled by default. You can manually enable and disable this feature.

You can use the following command-line options for diagnostic and debugging purposes.

-Xshare:off: To disable class data sharing.
-Xshare:on: To enable class data sharing. If class data sharing can't be enabled, print an error message and exit.

Note:
The -Xshare:on is for testing purposes only. It may cause the VM to unexpectedly exit during start-up when the CDS archive cannot be used (for example, when certain VM parameters are changed, or when a different JDK is used). This option should not be used in production environments.
-Xshare:auto: To enable class data sharing by default. Enable class data sharing whenever possible.

Generating CDS Archive Automatically

You can create Dynamic CDS Archive File automatically using the command -XX:+AutoCreateSharedArchive. For example:

java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=app.jsa -cp app.jar
    App

The specified archive file will be created if it does not exist, or if it was generated by a different JDK version.

See Creating Dynamic CDS Archive File with -XX:+AutoCreateSharedArchive in Java Development Kit Tool Specifications.