Java Virtual Machine Guide (original) (raw)

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:

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:

  1. 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.
  2. 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.