CDS has been a commercial feature with Oracle JVM since Java 8. CDS helps in two ways—it helps to reduce the startup time of a Java application and reduces its memory footprint with multiple Java Virtual Machines (JVMs).

When you start up your JVM, it performs multiple steps to prepare the environment for execution. This includes bytecode loading, verification, linking, and initializing of core classes and interfaces. The classes and interfaces are combined into the runtime state of JVM so that they can be executed. It also includes method areas and constant pools.

These sets 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 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 set of 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 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—a shared archive file. When JVM starts or restarts, classes.jsa is memory-mapped to save loading those classes.

When JVM's metadata is shared among multiple JVM processes, it results in a smaller memory footprint. Loading classes from a populated cache is 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.