Java - Java Class Data Sharing (CDS) and AppCDS

Introduction

Java applications often spend a noticeable amount of time loading class metadata into memory during startup. Every Java program depends on numerous classes from the Java Standard Library and application-specific libraries. Each time a Java application starts, the Java Virtual Machine (JVM) reads these classes, verifies them, prepares metadata, and stores the information in memory. Although this process is necessary, it increases startup time and consumes additional memory, especially when multiple Java applications are running on the same system.

Class Data Sharing (CDS) is a JVM feature that improves application startup performance and reduces memory usage by allowing multiple Java processes to share preprocessed class metadata. Instead of loading and preparing common classes every time an application starts, the JVM can use a pre-created archive containing class information.

Application Class Data Sharing (AppCDS) extends this concept by allowing developers to include their own application classes and third-party libraries in the shared archive, providing even greater performance improvements.


What is Class Data Sharing (CDS)?

Class Data Sharing (CDS) is a feature introduced in the HotSpot JVM that stores commonly used class metadata in a shared archive file. When an application starts, the JVM loads class information directly from this archive instead of recreating it from scratch.

This reduces:

  • JVM startup time

  • Memory consumption

  • CPU usage during startup

The shared archive can be used by multiple Java processes running on the same machine.


Why is CDS Needed?

Consider a system where several Java applications are running simultaneously.

Without CDS:

  • Every application loads Java core classes independently.

  • Each JVM creates its own copy of metadata.

  • More RAM is consumed.

  • Startup becomes slower.

With CDS:

  • Core class metadata is stored once.

  • Multiple JVM processes share the same archive.

  • Startup becomes faster.

  • Overall system memory usage decreases.


Understanding Class Metadata

When Java loads a class, the JVM stores information such as:

  • Class name

  • Package information

  • Fields

  • Methods

  • Constructors

  • Interfaces

  • Annotations

  • Constant pool

  • Method bytecode references

This information is called class metadata.

Instead of rebuilding this metadata every time, CDS stores it inside an archive.


How CDS Works

The process follows several steps.

Step 1: JVM Loads Classes

During the first execution, Java loads all required system classes.

Example:

String
Object
ArrayList
HashMap
Scanner
Math
Integer
Thread

Step 2: Metadata is Prepared

The JVM verifies each class.

It checks:

  • Bytecode correctness

  • Security rules

  • Symbol resolution

  • Internal data structures


Step 3: Archive Creation

The processed metadata is stored inside a shared archive file.

Example:

classes.jsa

The archive contains only metadata—not application data or object instances.


Step 4: Future JVM Starts

Next time the application starts:

JVM
   ↓
Open Shared Archive
   ↓
Load Metadata
   ↓
Start Application Faster

No repeated processing is required.


What is Stored in the Archive?

The archive generally contains:

  • Class metadata

  • Method information

  • Constant pools

  • Symbol tables

  • Internal JVM structures

  • Loaded system classes

It does not store:

  • Objects

  • Variables

  • Application data

  • Heap memory

  • User input


What is AppCDS?

Originally CDS shared only Java system classes.

Application Class Data Sharing (AppCDS) allows developers to include:

  • Application classes

  • External libraries

  • Framework classes

Examples:

MyApplication.class

Student.class

Employee.class

Customer.class

Framework libraries like:

Spring

Hibernate

Jackson

Apache Commons

Log4j

can also become part of the archive.


Difference Between CDS and AppCDS

CDS AppCDS
Shares Java system classes Shares application classes
Automatically available Archive must be created
Improves JVM startup Improves complete application startup
Uses standard library classes Includes project-specific classes
Requires minimal configuration Requires archive generation

CDS Architecture

          Java Application

                |

         Java Virtual Machine

                |

      Shared Archive (classes.jsa)

      -------------------------

      Java Core Classes

      Metadata

      Constant Pools

      Method Information

      Symbol Tables

      -------------------------

                |

      Shared Among JVM Processes

Creating a CDS Archive

A JVM archive can be created using the Java command.

Example:

java -Xshare:dump

This generates the default shared archive.

The archive is commonly stored as:

classes.jsa

Using the Shared Archive

Applications can use the archive during startup.

Example:

java -Xshare:on MyProgram

The JVM loads metadata from the archive instead of preparing it again.


Creating an AppCDS Archive

For application classes, developers first collect the list of loaded classes.

Example:

java -XX:DumpLoadedClassList=classes.lst MyProgram

This creates:

classes.lst

Next, generate the archive.

Example:

java

-XX:SharedClassListFile=classes.lst

-XX:SharedArchiveFile=app.jsa

-Xshare:dump

Finally, run the application using:

java

-Xshare:on

-XX:SharedArchiveFile=app.jsa

MyProgram

The JVM loads both Java system classes and application classes from the archive.


Benefits of CDS

Faster Startup

The JVM skips repeated class verification and metadata creation.

Applications become ready much faster.


Lower Memory Usage

Shared metadata is stored once.

Multiple JVM processes use the same memory pages.

This significantly reduces RAM usage.


Reduced CPU Utilization

Class loading requires CPU time.

CDS minimizes repeated processing.


Better Cloud Performance

Cloud platforms frequently start and stop containers.

CDS helps reduce startup latency.

This is especially useful for:

  • Docker

  • Kubernetes

  • Serverless deployments


Improved Scalability

When hundreds of JVM instances run simultaneously, CDS reduces both memory consumption and startup overhead.


Practical Example

Suppose a server hosts five Java applications.

Without CDS:

Application A

↓

Loads String

Loads Object

Loads HashMap

Creates Metadata

Consumes Memory

The same process repeats independently for Applications B, C, D, and E.

Total memory usage becomes much higher.

With CDS:

Shared Archive

↓

String

Object

HashMap

↓

Application A

Application B

Application C

Application D

Application E

All applications reuse the same metadata.


Real-World Use Cases

CDS is commonly used in:

  • Enterprise Java applications

  • Microservices

  • Spring Boot applications

  • Banking systems

  • Insurance software

  • Healthcare platforms

  • Cloud-native applications

  • Large-scale web servers

  • Continuous Integration (CI) environments

  • Containerized deployments


Limitations of CDS

Although CDS offers many benefits, it has some limitations.

  • The archive is JVM-version specific and generally cannot be reused across different Java versions.

  • Changes to application classes require regeneration of the AppCDS archive.

  • It primarily optimizes startup and memory usage; it does not directly improve business logic execution speed.

  • Dynamic class generation at runtime (such as some proxy classes or bytecode-generated classes) may not benefit from AppCDS.


Best Practices

  • Enable CDS for production environments where applications start frequently.

  • Use AppCDS for applications with many custom classes or large third-party libraries.

  • Regenerate the archive after significant code or dependency changes.

  • Benchmark startup time and memory usage before and after enabling CDS to measure improvements.

  • Combine CDS with other JVM optimizations, such as appropriate garbage collection settings, for better overall performance.


Summary

Java Class Data Sharing (CDS) is a JVM optimization feature that stores processed class metadata in a shared archive so that multiple Java applications can reuse it. This reduces startup time, lowers memory usage, and decreases CPU overhead during application initialization. Application Class Data Sharing (AppCDS) extends this capability to include application-specific and third-party library classes, making it particularly valuable for enterprise applications, cloud deployments, and microservices. By minimizing repeated class-loading work, CDS and AppCDS help Java applications start faster and use system resources more efficiently.