OpenJDK JEP 544 adds ahead-of-time compiled native code to the HotSpot AOT cache, cutting startup by 65 to 80 percent

OpenJDK published JEP 544, Ahead-of-Time Code Compilation, on 2026-09-10. The proposal extends the HotSpot AOT cache to hold native code compiled during a training run, so a production run can load that code at startup instead of spending the first minutes of the process in the bytecode interpreter and the C1 and C2 just-in-time compilers. The JEP is at the Candidate stage, and John Rose is the owner.

What changes for a running JVM

Today, HotSpot starts every process by interpreting bytecode, profiles which methods are hot, and then compiles the hot ones through C1 and C2 into optimized native code. The compilers take CPU time and memory that the application would otherwise use, and the process only reaches peak performance after that warmup finishes.

JEP 544 shifts the compilation itself into a training run. HotSpot runs the application once with AOTCacheOutput set, records the hot methods, compiles them, and writes the resulting native code into the AOT cache file alongside the pre-linked classes and profile data that JEP 483 and JEP 515 already put there. In a later run, HotSpot loads the native code from the cache and executes it immediately. If the workload changes, HotSpot can still deoptimize and reoptimize using the ordinary JIT path, so the AOT code and the JIT code coexist and are interchangeable because the same C1 and C2 compilers produced them.

The measured effect

OpenJDK ran five benchmark applications built with popular Java frameworks on a two-core Linux x64 system to emulate a microservice where the JIT competes with the application for CPU. Without AOT code, the AOT cache alone cut startup time by 50 to 70 percent across the five benchmarks. Adding AOT code took the total reduction to 65 to 80 percent, according to the JEP.

For warmup, OpenJDK ran a javac benchmark that recompiles the same 50 source files twenty times in a row. Compared to a JVM with no cache, the AOT cache without AOT code improved the first iteration by 30 percent, and adding AOT code brought a further 45 percent improvement, for a first-iteration reduction of 75 percent in total. The curve with AOT code was close to its steady state by the fourth iteration.

The constraints attached

The AOT code only loads if the CPU architecture and feature set of the production run match the training run, because code compiled for a CPU with AVX-512 will not run on one without it. The garbage collector has to match too, because the generated code contains GC-specific read and write barriers. Only AArch64 and x64 are supported. If the constraints are violated HotSpot warns and falls back to the interpreter and JIT, still using the classes and profile data in the cache, so the run stays correct.

For a service team, the shape of the pipeline is the same as JEP 483: a training run that exercises the code paths worth optimizing, one build artifact carrying the cache, and a production start that reads it. What is new is that the machine code travels in the artifact too, alongside the loaded classes and profile data already carried by JEP 483 and JEP 515. On a JVM microservice with a strict cold-start budget, this shortens the window between the process starting and the pod becoming useful, which is the window autoscalers pay for.

Source

Primary source: JEP 544: Ahead-of-Time Code Compilation. Discussion: Hacker News.