Class data sharing and startup

Key points

• CDS stores classes in an already-parsed, already-verified form that the JVM memory-maps at startup instead of reading a jar.
• Every JDK ships a default archive for the core library. That is why java -version ends with the word sharing.
• AppCDS extends this to your own classes. Record one real run with -XX:ArchiveClassesAtExit=app.jsa.
• Then start with -XX:SharedArchiveFile=app.jsa. If the archive no longer matches the jars the VM quietly ignores it.
• Typical saving is 20-40% of startup for a Spring Boot service, and the mapped archive is shared read-only between processes on the box.
• It removes parsing and verification, not JIT warm-up. Your first few thousand requests are still served by cold code.

Example

# 1. record which classes a real run actually loads
java -XX:ArchiveClassesAtExit=app.jsa -jar app.jar

# 2. start from that archive from now on
java -XX:SharedArchiveFile=app.jsa -jar app.jar

# in a Dockerfile: pay the cost once, at build time
# RUN java -XX:ArchiveClassesAtExit=/app/app.jsa -jar /app/app.jar --exit-after-startup
# ENTRYPOINT ["java","-XX:SharedArchiveFile=/app/app.jsa","-jar","/app/app.jar"]

# prove it is being used, and see anything that was rejected
java -Xshare:auto -XX:SharedArchiveFile=app.jsa -Xlog:class+load:file=load.log -jar app.jar
grep -c "shared objects file" load.log

# the JDK's own archive is why this line says "sharing"
java -version
#   OpenJDK 64-Bit Server VM (build 21.0.10+8-LTS, mixed mode, sharing)

AppCDS buys startup time, not steady-state speed.