This chapter describes the class data sharing (CDS) feature that helps reduce the startup time and memory footprints for Java applications.
Class data sharing (CDS) offers dynamic sharing of data between multiple Java Virtual Machines (JVM), which helps to reduce the startup time and memory footprint.
When the JRE is installed using the installer, the installer loads a set of classes from the system Java Archive (JAR) file into a private internal representation, and dumps that representation to a file called a shared archive. If JRE installer is not being used, then you can generate the shared archive manually.
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. The startup time is reduced thus saving the cost because restoring the shared archive is faster than loading the classes.
Class data sharing is supported with the G1, serial, parallel, and parallelOldGC garbage collectors. The shared string 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 needed. These savings allow more applications to be run concurrently on the same system. In Windows applications, the 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 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.
You can regenerate the shared archive for all supported platforms.
The default class list 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>
The class list created based on profiling should be used for generating the shared archive.
You can find the archive file along with the shared library for the JVM in the following locations:
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
If the archive file exists, when you generate a new archive file, then it overwrites the existing one. 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 on to a computer of the same architecture as the Java SE installation. Ensure that you have permission 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.