JEP 544 brings ahead-of-time native code to the JDK 28 AOT cache
Victoria Shinder2 min readJEP 544, Ahead-of-Time Code Compilation, is part of JDK 28. Its JEP page lists it as integrated into release 28, owned by John Rose, and it was announced as targeted to JDK 28 on Inside Java on 25 October. The feature extends Project Leyden's existing AOT cache: during a training run, HotSpot compiles application code to optimised native code and stores it in the cache, and later production runs load that code at startup instead of waiting for the interpreter and the C1 and C2 compilers to warm up.
The goals are narrow and practical. Applications should reach peak performance sooner and keep it when the workload changes; no change to application, library or framework code is required; and nothing in HotSpot's configuration changes beyond asking for the AOT cache. It keeps support for the Serial, Parallel, G1, Shenandoah and ZGC collectors, reuses the existing cache-creation workflow rather than adding a new one, and makes the hand-over from AOT-compiled to JIT-compiled code invisible to the application.
The non-goals are as informative. There is no AOT-only mode: a run mixes both kinds of code and moves between them as needed. There is no cross-compilation — native code from a training run must run on the same CPU architecture with the same features. Only x64 and AArch64 are supported for now. The JEP builds on JEP 483 (AOT class loading and linking) and JEP 515 (AOT method profiling).
What it means
This is the step after profiling: JDK 25 let the cache carry profiles so the JIT could start smarter, and JDK 28 lets it carry the compiled result. The same-CPU restriction is the operational catch — a cache trained on one instance type is not portable to a different one, so the training run belongs in the same pipeline that picks the hardware.