4 Class Data Sharing
This chapter describes the class data sharing (CDS) feature that can help reduce the startup time and memory footprints for Java applications.
Class Data Sharing
The Class data sharing (CDS) feature helps reduce the startup time and memory footprint between multiple Java Virtual Machines (JVM).
-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.
-
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.
java -XX:ArchiveClassesAtExit=<dynamic archive> -cp <app jar> MyApp
See Dynamic CDS Archive 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, add the following option in the command line:
java -XX:ArchiveClassesAtExit=<dynamic
archive>
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
-XX:ArchiveClassesAtExit
option.
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. 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.