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 Solaris, 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 G1, serial, parallel, and parallelOldGC 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 Platform, Standard Edition Tools Reference.

Regenerating the Shared Archive

You can regenerate the shared archive for all supported platforms.

The default class that is installed with the JRE contains only a small set of core library classes. You might want to include other classes in the shared archive. To create a class list from the class loading tracing output or running applications, enter the following command to dump all loaded library classes:

java -XX:DumpLoadedClassList=<class_list_file>

Use the class list created based on profiling to generate the shared archive.

If the archive file exists, it is overwritten when you generate a new archive file. You don’t need to manually remove the old archive before you generate a new archive.

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:

java -XX:SharedClassListFile=<class_list_file> -Xshare:dump

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 and may cause intermittent failures due to the use of address space layout randomization by the operating system. This option should not be used in production environments.
-Xshare:auto: To enable class data sharing by default. Enable class data sharing whenever possible.