search

JEP! 483: Ahead-of-Time Class Loading & Linking

"mprove startup time by making the classes of an application instantly available, in a loaded and linked state, when the HotSpot Java Virtual Machine starts. Achieve this by monitoring the application during one run and storing the loaded and linked forms of all classes in a cache for use in subsequent runs. Lay a foundation for future improvements to both startup and warmup time."

hashtag
🧠 JEP 483: Ahead-of-Time Class Loading & Linking

hashtag
🔍 What is it?

JEP 483 introduces a new way to pre-link Java classes during application build or testing — before your app even starts.

It extends the existing CDS (Class Data Sharing) system by allowing the JVM to record and cache class linking steps, like:

  • Bytecode verification

  • Constant pool resolution

  • Method/field linking

📜 CDS (Class Data Sharing) was first introduced in:

Java 5 (JDK 1.5), released in 2004.

hashtag
✅ Quick Timeline

Version
Feature/Change

Java 5 (2004)

CDS introduced for core JDK classes only (boot classpath)

Java 9 (2017)

AppCDS added: support for user-defined classes in the archive

Java 13+

CDS improved with support for dynamic archiving (recording class list at runtime)

Java 21+

Continuous improvements in heap object archiving, layered archives, and module support

Java 24 (JEP 483)

Ahead-of-Time class linking cache added as a separate optimization

hashtag
🛠 How it works (in 3 steps)

  1. Record linking behavior during app execution -XX:AOTMode=record

  2. Create a binary cache of that data -XX:AOTMode=create

  3. Run your app with that prelinked cache -XX:AOTMode=on -XX:AOTCache=...

hashtag
DEMO

run :

Logs:

app.aotconf

Says:

Inside MiniApp.class, the JVM accessed constant pool entries #8, #15, #16, etc., during execution.

What each of those indexes actually refer to depends on the compiled .class file.

hashtag
📦 What is app.aot?

The file created by:

is a compiled AOT cache — a binary file that contains:

hashtag
✅ Pre-resolved class linking and constant pool data:

  • Class-level metadata

  • Constant pool resolutions

  • Method handles and symbolic references

  • Resolved field/method/class names

  • Potentially some intermediate compiler structures

hashtag
✅ Purpose:

This allows the JVM to:

  • Skip the linking and symbol resolution phase

  • Avoid reflection costs at startup

  • Preload certain method metadata and types before the app even begins

hashtag
🧠 Analogy:

Think of app.aotconf as the blueprint, and app.aot as the compiled cache based on that blueprint.

File
Purpose
Human-readable?

app.aotconf

Text list of classes & CP indexes used

✅ Yes

app.aot

Binary cache for AOT linking

❌ No (JVM only)

hashtag
💡 When is app.aot used?

When you run with:

➡️ The JVM loads the .aot file at startup, checks the current heap layout, and links in the pre-recorded class resolutions without doing it live.

PreviousJEP 479: Remove the Windows 32-bit x86 PortNextJEP! 484: Class-File API

Last updated