Class Data Sharing
Overview
Class data sharing (CDS) helps reduce the startup time for Java programming language applications, in particular smaller applications, as well as reduce footprint. When the JRE is installed using the installer, the installer loads a set of classes from the system jar file into a private internal representation, and dumps that representation to a file, called a "shared archive". If the JRE installer is not being used, this can be done manually, as explained below. During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes.
Class data sharing is supported only with the Java HotSpot Client VM, and only with the serial garbage collector.
The primary motivation for including CDS in Java SE is the decrease in startup time it provides. CDS produces better results for smaller applications because it eliminates a fixed cost: that of loading certain core classes. 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. First, a portion of the shared archive, currently between five and six megabytes, is mapped read-only and therefore shared among multiple JVM processes. Previously this data was replicated in each JVM instance. Second, since the shared archive contains class data in the form in which the Java Hotspot VM uses it, the memory which would otherwise be required to access the original class information in rt.jar is not needed. These savings allow more applications to be run concurrently on the same machine. On Microsoft Windows, the footprint of a process, as measured by various tools, may appear to increase, because a larger number of pages are being mapped in to the process' address space. This is offset by the reduction in the amount of memory (inside Microsoft Windows) which is needed to hold portions on rt.jar. Reducing footprint remains a high priority.
Regenerating the Shared Archive
Under some circumstances the system administrator may need to manually regenerate the shared archive. This is typically only necessary on Solaris if the Java SE packages were installed over the network to a machine of a different architecture than that performing the installation. Regardless, these regeneration instructions apply to all supported platforms.
The shared archive file is colocated with the shared library for the JVM. On Solaris, Linux, or Mac OS X platforms, it is stored in jre/lib/[arch]/client/classes.jsa and on Microsoft Windows platforms in jre/bin/[client or server]/classes.jsa. If this file exists, it must be manually removed before regeneration.
To regenerate the archive, log in as the administrator; in networked situations, log on to a machine of the same architecture as the Java SE installation and ensure that you have permission to write to the installation directory. Then execute the command
java -Xshare:dump Diagnostic information will be printed as the archive is generated.
Manually Controlling Class Data Sharing
The class data sharing feature is automatically enabled when conditions allow it to be used. The following command line options are present primarily for diagnostic and debugging purposes and may change or be removed in future releases.
-Xshare:off- Disable class data sharing.
-Xshare:on- Require class data sharing to be enabled. If it could not be enabled for various reasons, print an error message and exit.
-Xshare:auto- The default; enable class data sharing whenever possible.
