All 15 Class Loading & Bytecode Verification questions
More in Class Loading & Bytecode Verification
How would you implement a custom ClassLoader to load classes from a non-standard source, such as loading plugin JARs dynamically at runtime, and what challenges arise with class unloading? What is bytecode verification, and what specific categories of invalid or unsafe bytecode does the JVM's verifier reject before allowing a class to run? How does the same class name loaded by two different ClassLoaders create two genuinely distinct types in the JVM, and what problems does this cause (such as with singletons or ClassCastException)? How would you diagnose and resolve a 'split package' problem when using JPMS, where the same package is defined across two different modules on the module path? How does a thread context ClassLoader (Thread.currentThread().getContextClassLoader()) solve the problem of a core JDK class needing to load an application-provided implementation class, given parent delegation normally prevents this?
Advertisement
Back to results for “Class Loading & Bytecode Verification”
Java › Class Loading & Bytecode Verification

How does Class Data Sharing (CDS) and Application Class Data Sharing (AppCDS) improve JVM startup time, and how does it relate to class loading and verification?

Advanced

Answer

CDS pre-processes and stores commonly-used core JDK class metadata (including already-verified bytecode structure) into a shared archive file at build/deployment time; when the JVM starts, it can memory-map this pre-built archive directly rather than re-parsing and re-verifying those classes from scratch on every single JVM startup -- AppCDS extends this same mechanism to your own application's classes and third-party library classes (not just JDK classes), meaningfully reducing both class loading and bytecode verification overhead specifically for scenarios with frequent JVM restarts, like short-lived serverless functions or containers.
# Generate a CDS archive listing classes used during a representative application run
java -Xshare:off -XX:DumpLoadedClassList=app.classlist -jar myapp.jar

# Create the AppCDS archive from that class list
java -Xshare:dump -XX:SharedClassListFile=app.classlist -XX:SharedArchiveFile=app.jsa -cp myapp.jar

# Use the archive on subsequent startups for faster class loading
java -Xshare:on -XX:SharedArchiveFile=app.jsa -jar myapp.jar
Real-world example A serverless function platform running the same JVM-based application thousands of times per day (each a fresh, short-lived process) adopts AppCDS to pre-share both JDK and application class metadata across invocations, meaningfully reducing the per-invocation cold-start latency that would otherwise be dominated by repeated class loading and verification work.

Common follow-ups: How does AppCDS interact with JPMS modules compared to the traditional classpath?;What's the operational overhead of maintaining and regenerating a CDS archive as application code changes over time?

Diagnostics & Performance;JVM JRE & Memory
All 15 Class Loading & Bytecode Verification questions