Learnitweb

Class Data sharing

—

by

Editorial Team
in

1. Introduction

Class data sharing (CDS) helps reduce the startup time for Java programming language applications, particularly in smaller applications. CDS helps reducing memory footprint between multiple Java Virtual Machines (JVM). 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”. During subsequent JVM invocations, the “shared archive” is mapped in memory and this results in saving the cost of loading classes. This also allows JVM’s metadata for the classes to be shared among multiple JVM processes.

CDS provides better results in case of smaller applications as smaller applications use relatively less number of core classes.

Starting from JDK 12, a default CDS archive is pre-packaged with the Oracle JDK binary. The default CDS archive resides in the following location:

  • In 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

Class data sharing is supported with the serial, G1, ZGC 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.

There are two ways in which the footprint cost of new JVM instances has been reduced:

  • A segment of the shared archive is mapped as read-only on the same host, allowing it to be shared among multiple JVM processes. This removes the necessity of replicating the data in each JVM instance and therefore reducing the startup time of your application.
  • The shared archive contains class data in the form that the Java Hotspot VM uses it. The memory typically needed to access the original class details within the runtime modular image is spared. This reduces footprint and allows more applications to be run concurrently on the same system.

2. Application class data sharing

In order to enhance both the startup speed and the overall memory usage, Application Class-Data Sharing (AppCDS) has been introduced, expanding upon the concept of CDS to encompass chosen classes from the application’s class path. This functionality permits the placement of application classes on a shared drive, facilitating the sharing of common class metadata among various Java processes. AppCDS enables the built-in system class loader, platform class loader, and custom class loaders to load the archived classes. When multiple JVMs share the same archive file, it conserves memory and overall system response time improves.

The classes within the CDS archive are stored in an optimized format, typically 2 to 5 times larger than classes stored in JAR files or the JDK runtime image. Hence, it’s advisable to archive solely those classes utilized by your application, which typically constitute only a fraction of all available classes. For instance, your application might only utilize a handful of APIs from a vast library.

To use CDS for the exact set of classes used by your application, you can use the -XX:SharedArchiveFile option, which has the general form:

-XX:SharedArchiveFile=<static_archive>:<dynamic_archive>

  • The <static_archive> overrides the default CDS archive.
  • The <dynamic_archive> provides additional classes that can be loaded on top of those in the <static_archive>.
  • On Windows, the above path delimiter : should be replaced with ;

The JVM can use up to two archives. To use only a single <static_archive>, you can omit the <dynamic_archive> portion:

-XX:SharedArchiveFile=<static_archive>

For convenience, the <dynamic_archive> records the location of the <static_archive>. Therefore, you can omit the <static_archive> by saying only:

-XX:SharedArchiveFile=<dynamic_archive>

3. Disable the default shared archive

By default, the default CDS archive is enabled at the runtime. You can specify -Xshare:off to disable the default shared archive.

4. Manually Creating CDS Archives

CDS archives can be created manually using several methods:

  • -Xshare:dump
  • -XX:ArchiveClassesAtExit
  • jcmd VM.cds

These steps are taken from the Oracle documentation. We believe it is the best place to refer for CDS.
The link for the same is here:

These steps are taken from the Oracle documentation. We believe it is the best place to refer for CDS.
The link for the same is here: https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#application-class-data-sharing

4.1 Creating a Static CDS Archive File with -Xshare:dump

The following steps create a static CDS archive file that contains all the classes used by the test.Hello application.

  1. Create a list of all classes used by the test.Hello application. The following command creates a file named hello.classlist that contains a list of all classes used by this application:
    java -Xshare:off -XX:DumpLoadedClassList=hello.classlist -cp hello.jar test.Hello
    The classpath specified by the -cp parameter must contain only JAR files.
  2. Create a static archive, named hello.jsa, that contains all the classes in hello.classlist:
    java -Xshare:dump -XX:SharedArchiveFile=hello.jsa -XX:SharedClassListFile=hello.classlist -cp hello.jar
  3. Run the application test.Hello with the archive hello.jsa:
    java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello

4.2 Creating a Dynamic CDS Archive File with -XX:ArchiveClassesAtExit

The following steps create a dynamic CDS archive file that contains the classes that are used by the test.Hello application, excluding those that are already in the default CDS archive.

  1. Create a dynamic CDS archive, named hello.jsa, that contains all the classes in hello.jar loaded by the application test.Hello:
    java -XX:ArchiveClassesAtExit=hello.jsa -cp hello.jar Hello
  2. Run the application test.Hello with the shared archive hello.jsa:
    java -XX:SharedArchiveFile=hello.jsa -cp hello.jar test.Hello

4.3 Creating Dynamic CDS Archive File with -XX:+AutoCreateSharedArchive

-XX:+AutoCreateSharedArchive is a more convenient way of creating/using CDS archives. Unlike the methods of manual CDS archive creation described in the previous section, with -XX:+AutoCreateSharedArchive, it’s no longer necessary to have a separate trial run. Instead, you can always run the application with the same command-line and enjoy the benefits of CDS automatically.

java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=hello.jsa -cp hello.jar Hello

5. Conclusion

In conclusion, Class Data Sharing (CDS) in Java offers significant benefits in terms of reducing startup times and memory footprint for Java applications, particularly smaller ones. By storing commonly used classes in a shared archive, CDS allows for quicker loading of applications and conserves system resources. Additionally, with the introduction of Application Class-Data Sharing (AppCDS), developers have even more flexibility in optimizing their applications for improved performance. However, it’s essential to carefully select which classes to archive to ensure maximum efficiency. Overall, leveraging CDS can greatly enhance the efficiency and responsiveness of Java applications, making it a valuable tool for developers looking to optimize their software.