A commercial feature with Oracle JVM since Java 8, CDS helps to reduce the start up time of a Java application and its memory footprint. This is especially notable when you are working with multiple JVMs.

On startup, JVM prepares the environment for execution. It includes bytecode loading, verification, linking, and initializing of the core classes and interfaces. The classes and interfaces are combed into the runtime state of the JVM so that they can be executed. It also includes method areas and constant pools.

These set of core classes and interfaces don't change unless you update your JVM. So, every time you start your JVM, it performs the same steps to get the environment up for execution. Imagine that you could dump the result to a file, which could be read by your JVM at startup. The subsequent startups could get the environment up and running without performing the intermediate steps of loading, verification, linking, and initialization; welcome to CDS.

When you install JRE, CDS creates a shared archive file from a predefined set of classes from the system JAR file. Classes are verified by the class loaders before they can be used and this process applies to all of the classes. To speed up this process, the installation process loads these classes into an internal representation and then dumps that representation to classes.jsa—the shared archive file. When the JVM starts or restarts, the shared archive file is memory mapped to save the loading of those classes.

When the JVM's metadata is shared among multiple JVM processes, it results in a smaller memory footprint. Loading classes from a populated cache are faster than loading them from the disk; they are also partially verified. This feature is also beneficial for Java applications that start new JVM instances.

Using CDS archives have reportedly resulted in the reduction of the application start up time by more than 30% on basic programs such as HelloWorld with JDK 11. This number is even higher on numerous 64-bit platforms.