Quarkus puts Project Leyden’s compiled-code cache through a production reality check

Project Leyden is moving Java’s ahead-of-time cache beyond class metadata and profiles. In a Quarkus engineering discussion published Nov. 2, OpenJDK committer Maria Arias de Reyna Dominguez walked through the newly integrated compiled-code layer and the operational constraints that come with it.

What changed

JEP 544 extends HotSpot’s existing AOT cache so a training run can store optimized native code for selected hot methods. A later production run can load that code immediately instead of starting those methods in the interpreter and waiting for tiered JIT compilation to catch up.

This is not an AOT-only Java mode. HotSpot can discard cached assumptions, deoptimize and compile new code when production traffic differs from the training workload. The proposal keeps the existing -XX:AOTCacheOutput and -XX:AOTCache workflow rather than introducing a separate compilation system.

The first implementation targets x64 and AArch64. JEP 544 also rules out cross-compilation: the training and production environments must use the same processor architecture and feature set.

Why Quarkus teams should care

The Quarkus write-up frames startup as two different problems. Framework work determines how quickly an application opens its port, while JVM warmup determines how quickly it begins returning responses at steady speed. Leyden’s cache is aimed chiefly at the second path, although earlier cache layers already move class loading, linking and profiling work into the training run.

That distinction matters for container platforms. A service can be technically ready while still spending CPU and memory on compilation during its first burst of requests. Preloading compiled code can move more of that cost into an image-build or preparation stage without closing the application to later JIT adaptation.

Quarkus also cautions against reading normalized framework charts as a ranking. Each framework is compared with its own uncached baseline, and Quarkus already performs substantial work at build time.

What to try

Teams evaluating JDK 28 early-access builds should treat the cache as a deployable artifact tied to a specific application, JDK and processor target. The training workload should exercise the startup and request paths that matter in production; unrepresentative traffic will still run, but HotSpot may need to deoptimize and compile different paths.

A useful test should separate port-open time, first-response latency and sustained throughput. It should also account for the CPU and memory saved during warmup, not just wall-clock startup. For mixed-architecture fleets, produce and validate separate caches rather than assuming one training artifact will travel across nodes.

Leyden’s design preserves HotSpot’s adaptive behavior. The engineering question is therefore less “native or JVM” than where a platform team wants to pay the compilation cost—and how reliably its build pipeline can reproduce the workload and hardware assumptions behind the cache.