How does Class Data Sharing (CDS) improve JVM startup performance?

Class Data Sharing (CDS) pre-processes class metadata into a shared archive file, by default classes.jsa, ahead of time, so the JVM doesn't have to repeat that work on every single startup.

Normally, loading a class means reading its bytes from a JAR or the filesystem, running the bytecode verifier against it, and parsing its constant pool into internal JVM structures - work that's identical every single time a given JDK class is loaded, since the JDK's own classes don't change between runs.

CDS does this parsing and verification once, at archive-creation time, and stores the resulting internal representation directly in a format the JVM can memory-map into its address space at startup, essentially treating class metadata like a pre-built cache rather than something to reconstruct from scratch.

Because the archive is memory-mapped and read-only, multiple JVM processes on the same machine using the same archive can share the underlying physical memory pages for that class data too, reducing overall memory footprint across many short-lived JVM instances, not just startup time for any one of them.

Since JDK 12, a default CDS archive covering core JDK classes is enabled automatically with no extra flags required, though its benefit is limited to bootstrap classes unless extended with AppCDS.