For full text search please use the '?' prefix. e.g. ? Onboarding

Class Data Sharing

There are two related CDS features:

  • CDS caches preprocessed JVM class metadata on-disk to improve startup performance and reduce memory footprint.
  • AppCDS extends CDS with support for application classes.

CDS

Where the archive is stored depends on the platform:

  • Linux and macOS: $JAVA_HOME/lib/$arch/server/classes.jsa
  • Windows: $JAVA_HOME/bin/server/classes.jsa

During start up the JVM memory maps the file to allow sharing read-only JVM metadata across multiple JVM processes.

  • -Xshare sets the CDS mode:
    • dump is used during the JVM build process to create CDS archives to ship with a distribution. By default this will generate an archive containing a predefined subset of Java classes, as defined in $JAVA_HOME/lib/classlist.
    • auto causes the JVM to use shared class data if available, and is the default.
    • on Requires use of shared class data, failing otherwise. Use only for testing purposes.
    • off prevents usage of shared class data.
  • -XX:SharedArchiveFile specifies the path to the CDS shared archive file.

GC support

  • CDS is supported with the ZGC, G1, Parallel, and Serial collectors.
  • Shared Java object heaps are supported only with the G1 collector on 64-bit, non-Windows platforms.

Regenerating

You can generate a dynamic CDS archive using the default archive as a base:

  • -Xlog:class+load will print [class,load] $className source: shared objects file for classes loaded from the CDS archive.
  • -XX:ArchiveClassesAtExit=$path .

Use the same Data areas and GC configurations as you intend to use at run-time when dumping the CDS archive.

AppCDS

Prior to SE 13 it was necessary to manually assemble and specify, using -XX:SharedClassListFile, a list of classes to include in the CDS archive:

java \
  -XX:DumpLoadedClassList=app-classlist \
  -jar app.jar

java \
  -Xshare:dump \
  -XX:SharedClassListFile=app-classlist \
  -XX:SharedArchiveFile=app-cds.jsa \
  --class-path app.jar

When created this way, AppCDS archives don't reference the JVM's own CDS archive, and all JVM classes need to be included in the AppCDS archive to avoid loading them from disk.

In more recent versions, the JVM can be configured to write the CDS archive during shutdown, and generated archives will reference the JVM's classes.jsa:

java \
  -XX:ArchiveClassesAtExit=app-cds.jsa \
  -jar app.jar

The application can now be launched using this dynamic CDS archive:

java \
  -XX:SharedArchiveFile=app-cds.jsa \
  -jar app.jar
  • -Xshare:dump is used during the JVM build process to create CDS archives to ship with a distribution.
  • -XX:DumpLoadedClassList lists the loaded classes.
  • -XX:SharedClassListFile specifies additional classes to store in the CDS archive, formatted one class per-line with dots (.) replaced by slashes (/).
  • -XX:SharedArchiveFile should be set to an application-specific path when including application classes.
  • -XX:SharedArchiveConfigFile specifies additional data: strings and symbols as dumped by jcmd's VM.*table commands.

History

  • p.r.comp.lang.java.jvm.versions.se5 (Private) (client): introduced as a startup performance improvement, but only for system classes and only for Serial.
  • SE 9:
    • Introduces support for the server VM and adds support for G1 and Parallel (and ParallelOld) garbage collectors.
    • Support for application classes is introduced as a commercial feature.

References