Quarkus Insights #266: What's new in Leyden? - Quarkus

Blog Quarkus Insights #266: What's new in Leyden?
This summary was generated using AI, reviewed by humans - watch the video for the full story.
Java gets faster the longer it runs, but what if an application could start out already warmed up? That is the goal of Project Leyden, and a lot has changed since Maria Arias de Reyna Dominguez last appeared on the show roughly a year ago. In episode 266, Maria, a committer on the OpenJDK project who works on Leyden at IBM, joins hosts Eric Deandrea and Holly Cummins to explain how the AOT cache works, what the newly merged ahead-of-time code compilation adds, what it takes to use the cache in production, and why the Leyden team wants feedback from real users now.
Holly noted that the finish line for Quarkus 4 is in sight, and encouraged everyone to try Quarkus 4 Beta 2 if they have not already. The Quarkus:Dev conference call for papers is coming soon, so start thinking about the stories and projects you would like to share.
Project Leyden is one of several OpenJDK projects improving the Java language, the JVM, or the wider ecosystem, alongside efforts such as Project Valhalla. Leyden targets startup and warm-up time.
Maria explained the underlying trade-off. A natively compiled C or C++ binary runs the same code from start to finish. Java instead ships bytecode that the JVM interprets, profiles, and recompiles repeatedly. Along the way it learns runtime-only facts, such as which branches are hot, which code is never used, and exactly which CPU instructions the hardware supports. That is why long-running Java applications can end up faster than ahead-of-time compiled code, but it also means the application is slowest right when it starts.
Leyden’s approach is a three-step workflow:
Run the application in a training run to reach peak performance and collect runtime information.
Store what was learned in an AOT cache.
Start the real production run with the cache, so the JVM has that information from the first request.
Last year’s work already delivered roughly a 50 to 60 percent improvement in startup and time to first response. The cache stores the class metadata model (including class hierarchy and field relationships), method counters and profiling data, class, method, and compile training data, and the adapter handlers that convert method signatures and arguments to hardware-specific native calling conventions.
Maria also made a useful distinction between the two metrics teams usually measure. Time until the port is open mostly depends on the framework, while time until responses arrive quickly depends on application warm-up, which is where the cache has the most impact.
The big new addition is JEP 544, available from JDK 28, which stores compiled native code in the cache in addition to profiling data. Maria explained that this was harder than simply saving machine code, because memory addresses differ on every load and pointers must be translated. The change was ready by summer but had to wait while the large Valhalla pull request was merged, since every new commit to the main source tree broke it.
To show why this matters, Maria walked through JVM tiered compilation:
Tier 0, the interpreter: Translates bytecode instruction by instruction without optimizing, which is why the JVM is slowest at the start.
Tiers 1 to 3: Method counters trigger compilation with C1 at increasing levels of profiling. If the C2 compiler queue is busy, a method may go to tier 2 instead of tier 3, and trivial methods with no loops or branches stop at tier 1.
Tier 4: Fully optimized C2 code with peak performance, which most one-time methods such as startup logic never need.
Cached code does not freeze behavior. If a method behaves differently in production than it did during training, the JVM still recompiles it. Maria used a "Black Friday" branch as an example: when that branch is finally taken, the JVM deoptimizes and recompiles accordingly. Code loaded later is also compiled dynamically as usual. Code compilation in the cache is currently supported on two architectures, and the team chose not to hold the JEP back while waiting for more.
Maria showed the official normalized chart from the JEP, which compares frameworks against their own baseline without a cache. She stressed that it does not rank frameworks against each other. Holly added that Quarkus appeared to gain less in the chart simply because it already does so much work ahead of time, and the data shown was also from an older Quarkus version.
For her own tests, Maria used a REST benchmark project from a colleague, with 25,000 requests and a rate limit of 5,000, running a basic Quarkus REST endpoint and a variant backed by Hibernate. She was upfront that these were laptop numbers with Slack and streaming software running, and recommended real servers for real measurements. The shape of the results was still clear:
Time to port open was slightly slower with the cache, but Maria argued it does not matter if responses arrive much sooner.
Without a cache, per-request latency started around 60 milliseconds and reached peak performance after about 1,000 requests.
With the AOT cache and code compilation, requests started around 20 milliseconds and reached peak performance after about 400 requests.
The more complex Hibernate application took longer to warm up overall, but it also showed the biggest gains from the cache.
Compared with the previous cache without code, startup latency in the Hibernate case roughly halved, from around 200 milliseconds to 100.
Eric and Holly highlighted the practical consequence: the improvement requires no code changes, no different arguments, and the same training run. Upgrading the JDK is enough, which makes a performance case for moving to newer Java versions in addition to the security case. Faster warm-up can also mean fewer instances when scaling out under load, which saves real money in the cloud.
Maria said Quarkus has been the framework most involved with Leyden, and that its ea