- Sources: primary, discussion
- Summary: JEP 544, owned by John Rose and updated 2026-09-10, is at Candidate status and extends the existing AOT cache rather than adding a workflow, following JEP 483 in JDK 24 for class loading and linking and JEP 515 in JDK 25 for method profiling. A training run compiles hot methods with C1 and C2 and stores the native code, which a production run loads instead of recompiling, and on five framework benchmarks run on a two-core Linux and x64 system the cache without AOT code cuts startup by 50 to 70 percent against 65 to 80 percent with it, while a javac benchmark shows about 30 percent against about 75 percent. Cached code is used only when the production run has the same CPU architecture and feature set and the same garbage collector, otherwise HotSpot warns and falls back to the interpreter and JIT while still using the cached classes and profiles, and only AArch64 and x64 are supported initially.
- Why it matters: This is where Project Leyden's cache stops holding preparation work and starts holding compiled code, and the reuse constraints decide whether a deployment can rely on it.
- Follow-up: Whether JEP 544 is targeted to a release, and whether more architectures follow AArch64 and x64.
send feedback on this story