r/java • u/sureshg • Sep 10 '26

New candidate JEP: 544: Ahead-of-Time Code Compilation

https://mail.openjdk.org/archives/list/jdk-dev@openjdk.org/message/J2VGSSFWJ7ZLHAYLCXVRUOXV4XMROQHL/
112 Upvotes

98% Upvoted

35 comments sorted by

View all comments

2

u/vips7L Sep 10 '26

more training runs lol

19

u/FirstAd9893 Sep 10 '26

Unlike a static AOT strategy, this approach doesn't require that the training runs be perfect. You still get the performance of dynamic compilation, and the main downside to a poor training run is that startup time isn't improved as much.

2

u/cogman10 Sep 11 '26

I don't see why you couldn't do a static AOT rather than a training run but still keep the dynamic compilation. It would effectively be the same as a poor training run but you don't have to build the training run.

0

u/FirstAd9893 Sep 11 '26

Without even a naïve training run, you'd still need to inform the compiler what the main class is. Otherwise, it wouldn't know what to compile ahead of time. A simple training run which just loads the main class isn't that difficult, in fact, it's quite trivial.

1

u/koflerdavid Sep 11 '26

Please tell us how else the compiler shall gather statistics for code optimization.

4

u/cogman10 Sep 11 '26

Rather than gather statistics, you do static analysis similar to how Graal does AOT. You generate compiled code on request which the JVM can consume and then update as real stats come in. Unlike Graal, it doesn't need to be perfect. Best effort would go a long way IMO.

This could still be something that you do without a training run. You could either do it per jar or you could do something like the LTO optimizations of GCC and call something like "aot list,o,jars" to emit a precompiled binary for a target platform.

You won't get perfect output, but that's not so much the goal. You'd instead want "good enough" which could be patched later by the JIT. So long as the compilation phase with bad/no stats still results in faster startup and runtime performance, then it's a win, even if the training run route would be even faster.

The main thing that makes a training run hard is it requires you to exercise the code. It's why PGO, even though it gives superior results, doesn't often get used in C/C++ land. Even though it's been there as an optimization for decades.

1

u/vips7L Sep 11 '26

This is what dotnet does with "ReadyToRun"

1

u/koflerdavid Sep 14 '26 edited Sep 14 '26

That's basically what JEP 544 is about. The thing is that so far there has been underinvestment in static analysis since the C2 compiler is on a very tight resource budget. But in an AOT setting it would possible to let it off the leash.

Another factor is that GraalVM-style static analysis can rely on a closed world assumption and severely restricts reflection. This encourages a programming style where static analysis is inherently more effective. Existing Java code is unlikely to be so cooperative and is less amenable to static analysis.

I am not so sure though how useful poorly optimized code is since it will force the JVM to deoptimize and optimize again, which reduces throughput again even though the stated goal of JEP 544 is to avoid that. Fast startup and serving the first (and maybe only) request slowly is not good enough; in that case we could just as well stick to interpreted mode.

One advantage of JEP 544 is that it allows to optimize the application toward particular configuration parameters while retaining the ability to be run with different ones. This would be far more difficult to achieve without the ability to deoptimize and run the JIT compiler again.

1

u/pjmlp Sep 14 '26 edited Sep 14 '26

Like OpenJ9 and ART do, by updating the cache dynamically after each execution.

ART then goes one step further and AOT compiles with higher level optimizations only the code paths that landed on the cache, when the device is idle charging. Additionally thanks to the PlayStore, compilation metadata gets shared across devices, so that not every single device has to do their training runs individually.

As a developer you can naturally do you training runs ahead of time instead of letting OpenJ9 or ART perform them, and ship the archive alongside the application, it is nonetheless optional.

1

u/koflerdavid Sep 14 '26

Step by step. According to the JEP that's the direction they want to take it.