AppCDS, application class data-sharing, is an easy way to improve the startup performance of a Java application. This is done by the JVM creating a pre-processed shared archived of classes loaded at startup. Since its initial release, AppCDS has become easier to use, going from a three-step process to a two-step process, and now with JDK 19, AppCDS can be done in a single step. Let’s look at this feature added to AppCDS in JDK 19.

AppCDS Overview

When the JVM launches a Java application, class loaders will load the classes needed to launch the application. For many applications, this can be tens of thousands of classes. This process would be identical every time the application is launched, and with it being CPU and memory intensive, it represents an opportunity for improvement.

CDS, class data-sharing, goes back to JDK 5, where the bootstrap loader could use a pre-processed shared archive of JDK classes at startup. In JDK 10, this functionality was extended to include application classes.

Loading classes from a pre-processed archive can provide a noticeable improvement to startup performance. However, the specific improvement will depend upon factors including; the size of the application, startup behavior, hardware, and others. Additionally, the archive is memory-mapped, allowing other JVM processes running on the same host and using the same shared archive to use the same memory address. AppCDS is also quite robust as the JVM will, by default, silently ignore issues encountered when attempting to load classes from the shared archive and fall back to loading them from the file system.

AppCDS has seen incremental advancements since its addition in JDK 10. Initially, creating and using a shared archive was a three-step process of; creating a list of the classes to be archived, generating the archive, and then using the archive. This process was refined in JDK 13 as a two-step process combining creating lists of classes to be archived and generating the archive into a single step. However, even this relatively simple process was an issue when upgrading between JDK releases as a shared archive would need to be regenerated as the JDK version of the shared archive needs to match the JDK version of the JVM.

Autogenerating an Archive

JDK 19 introduces the ability for an archive to be autogenerated. Instead of creating and using an archive being two discrete steps, with JDK 19, these can be combined into a single step allowing the same java launch command to be used when creating and using a shared archive. The below command demonstrates how to use the autogenerate feature:

java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=my-archive.jsa Main

The JVM will check the SharedArchiveFile location for the shared archive on launch. If it exists, the JVM will load from the shared archive. If the archive does not exist, the JVM at exit will generate a shared archive at the SharedArchiveFile location. The JVM will also check the JDK version with which the shared archive was built. If the version does not match the version of the JVM, the JVM will, at exit, generate a new shared archive and overwrite the existing one.

Simplifying the creation and usage of a shared archive into a single step will make upgrading between JDK versions easier.

Additional Reading

• Class Data Sharing
• JBS entry - Automatically generate the CDS archive if necessary

Happy coding!