CDS and AppCDS: Class Data Sharing for Faster JVM Startup

Every time a JVM starts, it spends time loading the same classes over and over. The Java runtime itself, the standard library classes in java.base, and your own application classes that have not changed since the last run: all of them get loaded, verified, and laid out in memory from scratch. For short-lived processes or serverless functions where startup latency matters, this is a meaningful tax.

Class Data Sharing (CDS) addresses this by dumping the internal representation of already-loaded classes into a shared archive. The next JVM that starts can memory-map that archive and skip the loading and parsing step for those classes entirely. The result is faster startup and reduced memory footprint because multiple JVM processes can share the same class data in memory.

CDS has been in the JVM since Java 5. AppCDS, introduced in Java 8 update 191, extended it to include application classes. Understanding how to use both effectively can shave hundreds of milliseconds off your startup time.

This covers how CDS and AppCDS work under the hood, how to create and use shared archives, and what the practical tradeoffs are. For related JVM tuning, see the container memory limits post.

Introduction

Every JVM startup pays a tax in class loading time. Core JDK classes from java.base, your application classes, and every library on the classpath: all get parsed, verified, and laid out in memory from scratch on every process start. For short-lived processes like serverless functions, CLI tools that run for seconds, or microservices that restart frequently, this startup cost can dominate total execution time. A function that runs for 500ms but spends 400ms starting is the entire story of optimizing startup latency.

Class Data Sharing (CDS) addresses this by extracting the internal representation of already-loaded classes into a shared archive file. On subsequent JVM starts, the process memory-maps this file and skips the parsing step for archived classes entirely. Multiple JVM processes on the same machine can share the mapped pages in physical memory, reducing RSS per process. CDS has been in the JVM since Java 5, and AppCDS (introduced in Java 8) extended the mechanism to include application classes and libraries beyond the core JDK.

This post explains how CDS and AppCDS work under the hood, when they provide meaningful benefit versus when the maintenance overhead outweighs the gains, how to create and validate shared archives, and the practical tradeoffs of baking archives into container images versus generating them dynamically. For serverless and short-lived process scenarios, AppCDS is one of the highest-leverage JVM optimizations available.

When to Use

CDS and AppCDS help most when startup time is a real constraint, not just a theoretical one. Serverless functions, CLI tools that run for seconds, and microservices that restart often are where the gains show up. If your function runs for 500ms but takes 400ms to start, cutting startup to 100ms is the whole game. The class-loading cost gets paid on every invocation, so when invocation time is short, the tax is high.

The memory savings matter in container environments. When multiple JVM processes on the same node share the mapped archive file, the kernel can dedupe the physical pages. RSS drops for each process, which helps with container density and cost.

Use AppCDS when you own the JVM version end-to-end and can bake the archive into your container image. If your CI builds the archive once and ships it with the app, you get consistent wins without runtime overhead.

When NOT to Use

Skip CDS for long-running services. A JVM that starts in 2 seconds and runs for 8 hours gets almost nothing from a faster startup. The archive maintenance burden (regenerate on every JVM upgrade, store it somewhere, validate it in CI) is real cost for a negligible benefit when the startup time is a rounding error on total runtime.

Avoid AppCDS when your application loads classes dynamically in ways that are hard to predict. A static class list only captures what you knew about at archive creation time. If your framework loads plugins, generates classes at runtime, or exercises code paths that vary between runs, the archive is incomplete and your startup gains evaporate. Dynamic archives help here, but they introduce their own unpredictability.

The archive is tied to the exact JVM version and the exact set of classes. Upgrade a library and the archive may silently break, or worse, seem to work but produce wrong results. If you do not have a build pipeline that regenerates the archive with each release, the maintenance overhead will bite you.

How CDS Works

When the JVM loads a class, it parses the bytecode, performs verification, resolves constants, and creates an internal representation called a class file structure in the Metaspace. This parsing is repeatable. The same class bytecode produces the same internal structures every time.

graph TD
    A[JVM Process 1<br/>First Start] --> B[Load java.base classes]
    B --> C[Parse bytecode<br/>Verify types<br/>Build internal structures]
    C --> D[Write class data to<br/>shared_archive.jsa]
    D --> E[Exit]

    F[JVM Process 2<br/>Subsequent Start] --> G[Memory-map<br/>shared_archive.jsa]
    G --> H[Class data loaded<br/>from memory map]
    H --> I[Skip parsing<br/>for archived classes]
    I --> J[Start running<br/>faster]

CDS dumps the internal class metadata to a file on the first run. On subsequent runs, the JVM memory-maps this file directly, making the class data instantly available without parsing. Multiple JVM processes on the same machine can also share the mapped file in physical memory, reducing total memory consumption.

The shared archive is specific to the JVM version and the set of classes that were archived. A CDS archive created with Java 11 cannot be used with Java 17.

CDS vs AppCDS

CDS alone only archives the core JDK classes from java.base. AppCDS extends this to include your application classes and any library classes you choose to include.

CDS (Class Data Sharing):

• Ships with the JDK by default
• Archives only JDK core classes
• Automatic: the JDK includes a default archive for java.base
• Controlled by -Xshare:{on,off,dump,auto}

AppCDS (Application Class Data Sharing):

• Extends CDS to include application classes
• Requires creating a custom archive with -Xshare:dump
• Specify which classes to archive with -XX:SharedClassListFile
• Archive path set with -XX:SharedArchiveFile
• Available since Java 8 update 191, became more flexible in Java 11+

Creating a Shared Archive

Creating a shared archive involves running the JVM with -Xshare:dump to produce the archive file, then referencing it at runtime.

# Step 1: Create a class list of classes to archive
# You can use -XX:+UseAppCDS and dump application classes
java -Xshare:off -XX:+UnlockCommercialFeatures \
     -XX:+UseAppCDS \
     -XX:DumpLoadedClassList=classes.lst \
     -cp myapp.jar com.myapp.Main

# Step 2: Create the shared archive
java -Xshare:dump \
     -XX:+UseAppCDS \
     -XX:SharedClassListFile=classes.lst \
     -XX:SharedArchiveFile=shared_archive.jsa \
     -cp myapp.jar

# Step 3: Use the archive at runtime
java -Xshare:on \
     -XX:SharedArchiveFile=shared_archive.jsa \
     -cp myapp.jar com.myapp.Main

In Java 11 and later, the process is simpler because AppCDS is no longer a commercial feature.

# Java 11+: Create archive with class list
java -Xshare:off \
     -XX:APP_CDS_CACHE_SIZE=64M \
     -XX:+UseContainerSupport \
     -XX:SharedClassListFile=classes.lst \
     -XX:SharedArchiveFile=shared_archive.jsa \
     -cp myapp.jar \
     --module-path mods \
     com.myapp.Main

# Java 11+: Runtime with archive
java -Xshare:on \
     -XX:SharedArchiveFile=shared_archive.jsa \
     -cp myapp.jar \
     --module-path mods \
     com.myapp.Main

Automatic Archive Creation

Java 13 introduced automatic CDS archives. The JVM can create an archive automatically on the first run if the directory is writable and the -Xshare:auto mode is enabled (the default).

# First run: creates archive automatically
java -Xshare:auto -cp myapp.jar com.myapp.Main

# Second run: uses the archive
java -Xshare:auto -cp myapp.jar com.myapp.Main

The archive is stored in java.io.tmpdir by default and includes the classes loaded during the first run. This is the simplest way to get CDS benefits with no configuration.

Production Failure Scenarios

Failure Scenario	Symptoms	Root Cause	Solution
Incompatible archive	Error: ” Unable to use shared archive”	Archive created with different JVM version	Recreate the archive with current JVM version
Corrupted archive	Crash on startup when loading archive	Archive file modified after creation	Delete and recreate the archive
Class list mismatch	Classes missing from archive, no speedup	Classes loaded dynamically not in class list	Include all possible classes in the list
Read-only filesystem	Cannot create archive	No write access to archive directory	Use writable directory with -XX:SharedArchiveFile
Archive too old	Old classes used from archive	Archive not regenerated after code changes	Regenerate archive with each release

Trade-off Analysis

Understanding when CDS helps and when it does not helps you decide where to invest effort.

Aspect	Without CDS	With AppCDS
Startup time	Slower (full class loading)	Faster (memory-mapped archive)
Memory usage	Higher (each process loads own copy)	Lower (shared memory pages)
Disk space	None	Archive file size (typically 10-50MB)
Maintenance	None	Archive must be regenerated on JVM upgrade
Benefit magnitude	Baseline	20-50% startup improvement for typical apps
Short-lived processes	Full cost every time	Amortized across runs

CDS provides the most benefit for short-lived processes where startup time dominates total execution time. For long-running server applications, the startup savings are amortized over a longer runtime and matter less.

Implementation Snippets

Full Java 11+ AppCDS Workflow

#!/bin/bash
# build_and_archive.sh

APP_JAR="build/libs/myapp.jar"
ARCHIVE_FILE="myapp.jsa"
CLASS_LIST="classes.lst"

# Step 1: Run once to generate class list
echo "Generating class list..."
java -Xshare:off \
     -XX:+UseAppCDS \
     -XX:SharedClassListFile=${CLASS_LIST} \
     -XX:SharedArchiveFile=${ARCHIVE_FILE} \
     -cp ${APP_JAR} \
     com.myapp.Main --help 2>/dev/null

# Step 2: Create the archive
echo "Creating shared archive..."
java -Xshare:dump \
     -XX:+UseAppCDS \
     -XX:SharedClassListFile=${CLASS_LIST} \
     -XX:SharedArchiveFile=${ARCHIVE_FILE} \
     -cp ${APP_JAR}

echo "Archive created at ${ARCHIVE_FILE}"
ls -lh ${ARCHIVE_FILE}

Using AppCDS in Kubernetes

# Dockerfile
FROM openjdk:17-slim AS builder

COPY build/libs/myapp.jar /app/
COPY create_archive.sh /app/

RUN chmod +x /app/create_archive.sh && \
    /app/create_archive.sh

FROM openjdk:17-slim
COPY --from=builder /app/myapp.jsa /app/
COPY --from=builder /app/myapp.jar /app/
ENTRYPOINT ["java", "-Xshare:auto", "-XX:SharedArchiveFile=/app/myapp.jsa", "-jar", "/app/myapp.jar"]

Verifying Archive Usage

# Check if CDS is active
java -Xshare:on -XX:+PrintSharedArchiveInfo -cp myapp.jar com.myapp.Main 2>&1 | head -30

# Example output when archive is working:
# ...
# ...

# SharedArchiveInfo section:
#     Base address: 0x0000000800000000
#     Mapping: shared_archive.jsa
#     ...

Dynamic Archive with Java 17+

Java 17 introduced the ability to create a dynamic archive that includes classes loaded at runtime, not just those in a static class list.

# Create a dynamic archive (Java 17+)
# First run: create archive
java -Xshare:auto \
     -XX:ArchiveClassesAtExit=myapp_dynamic.jsa \
     -cp myapp.jar \
     com.myapp.Main

# Subsequent runs: use dynamic archive
java -Xshare:auto \
     -XX:SharedArchiveFile=myapp_dynamic.jsa \
     -cp myapp.jar \
     com.myapp.Main

The dynamic archive captures whatever classes were actually loaded during the first run, which can be more complete than a static class list.

Observability Checklist

When using CDS/AppCDS in production, these points help you verify it is working correctly.

• Verify archive is loaded: -XX:+PrintSharedArchiveInfo
• Track startup time before and after archive creation
• Monitor RSS memory reduction with shared memory pages (ps aux | grep java)
• Check archive validity on JVM upgrade: recreate if version mismatch errors appear
• Store the archive in version control or build artifacts for reproducibility
• Use -Xlog:class+load=info to see which classes come from the archive
• Monitor for archive corruption errors after system updates
• Test with -Xshare:dump periodically to refresh archives for changed code

Security Notes

CDS archives are memory-mapped files. If the archive file is modified after creation, the JVM can crash or behave unpredictably when it tries to read corrupted structures. Protect archive files with the same care you give to native libraries.

CDS archives contain parsed class metadata including the structure of all fields and methods. This is generally not sensitive since it comes from class files which are already part of the JAR. However, be aware that the archive contains a complete picture of your application class structure.

CDS does not provide any security boundary. Any process with read access to the archive file can memory-map it. In multi-tenant environments, use file permissions to restrict access to archives if that is a concern.

Common Pitfalls / Anti-Patterns

Here are the most common mistakes when working with CDS and AppCDS.

Forgetting to recreate the archive on JVM upgrade. A CDS archive is tied to the exact JVM version and possibly the JVM implementation (HotSpot vs OpenJ9 vs others). Upgrading the JDK without regenerating the archive causes errors. Build the archive regeneration into your deployment pipeline.

Using -Xshare:auto without understanding what gets archived. With automatic archive creation, the archive only contains classes that were actually loaded during the first run. If your application has code paths that are not exercised on the first run, those classes are not archived and do not benefit from faster loading.

Not including dynamically loaded classes. Classes loaded via reflection, ClassLoader.newInstance, or agent premain are not in a static class list. Use dynamic archives (ArchiveClassesAtExit) to capture these.

Storing the archive in /tmp. The default location for automatic archives is java.io.tmpdir, which is often tmpfs and gets cleared on reboot. Store the archive in a persistent location or your application image.

Assuming archive helps on every workload. For long-running server processes where startup is a small fraction of total runtime, the overhead of managing the shared archive may not be worth it. CDS shines for short-lived processes.

Quick Recap Checklist

Use this checklist when deploying AppCDS for your application.

• Decide between static class list and dynamic archive for your use case
• Build archive creation into your CI/CD pipeline
• Verify the archive loads correctly with -XX:+PrintSharedArchiveInfo
• Store the archive alongside your application JAR or in the container image
• Plan to regenerate the archive on every JVM version upgrade
• Test startup improvement before and after in a representative environment
• Use -Xshare:auto for simplest configuration if dynamic classes are okay
• Monitor for shared archive errors in logs after system changes
• Protect archive files from modification after creation
• Consider dynamic archives (ArchiveClassesAtExit) for complex classloading

Interview Questions

Further Reading

• JEP 310: Application Class-Data Sharing - Official JEP covering AppCDS design, dynamic archives, and the archive file format.
• CDS Archive Format and Internal Structure - OpenJDK documentation on how class data is serialized into the shared archive and how it is memory-mapped at runtime.
• AppCDS Implementation in OpenJDK - Technical details on AppCDS implementation including class list format, archive validation, and cache management.
• Dynamic Archiving with ArchiveClassesAtExit - Oracle documentation covering dynamic archive creation with Java 17+ and when to use ArchiveClassesAtExit vs static class lists.
• Memory Mapping Benefits in Container Environments - Linux kernel documentation on how mmap sharing works across processes and why shared memory pages reduce RSS in container environments.

Conclusion

CDS and AppCDS are one of the quieter performance wins in the JVM. They require minimal configuration, provide meaningful startup improvements, and reduce memory footprint through shared memory mapping. The only real cost is maintaining the archive across JVM upgrades, which is manageable with proper build pipeline integration.

For serverless functions, short-lived CLI tools, and microservices where startup latency matters, AppCDS is worth the setup effort. For long-running servers, the benefit is smaller but still positive. Start with -Xshare:auto and graduate to a static archive if you need reproducible, controlled class coverage.