Java's new AOT cache cuts startup time by up to 80%
JEP 544: Ahead-of-Time Code Compilation
JEP 544 stores optimized native code from a training run in the AOT cache, making it instantly available when HotSpot starts. Benchmarks show startup improvements of 65–80% and a javac warmup gain of about 75%. If workloads change, HotSpot deoptimizes and reoptimizes dynamically, blending AOT and JIT compilation without requiring any code or configuration changes.
Thus Java applications will gain some of the benefits of static compilation while retaining the agility, portability, and compatibility of dynamic compilation.
- cogman10
Leyden has been relying pretty heavily on training runs which I get, but man is that a pretty hard burden to setup.
The tooling for doing these sorts of training runs doesn't really exist, you end up needing to do something more bespoke as part of your build pipeline if you want it there. That can be especially tricky with more complicated applications like the ones I maintain.
I like what these can deliver, but dislike the effort needed to get it going.
- treyd
What are the architectural differences between this and Android's ahead-of-time runtime?
- cyberax
Excelsior JET did that 25 years ago: https://en.wikipedia.org/wiki/Excelsior_JET
It's a shame that Sun/Oracle never partnered with them to bring native apps. This could have saved Java on the desktop.
- java-man
I hope at some point we'll get AOT-only mode (or compile to native) and maybe even cross-compilation.
- ledo9915
Data point from a small side project: I run user code in a Piston sandbox for a coding challenge site. A trivial Java program costs 2.5-3 s wall clock on a 4 vCPU box, almost all of it javac plus JVM startup. Go takes about 1.7 s for build plus run, and Swift running through the interpreter is at 0.4 s. Java is the reason I had to put a global rate limit on compiled languages at all. If AOT gets the JVM side down to a few hundred ms, that changes what a small box can serve.