He clarified that the GIF showed only the first N seconds of the program running, where the AOT binary required no warmup. But what was really interesting, is his comment about how AOT mode is still able to perform potentially slightly better than JIT:
> "The GIF is showing the first n seconds, and the JIT just needs noticeable more time to warm up. But even at peak, AOT can outperform JIT although not by an order of magnitude of course."
https://twitter.com/alina_yurenko/status/1582772754902052864
> AOT can be faster than JIT, because:
> - in AOT 100% of the code is compiled (on JIT cold code can still be interpreted)
> - some optimizations are only possible under a closed-world assumption (AOT)
> - AOT can dedicate time and resources to perform more expensive optimizations> - in AOT 100% of the code is compiled
If the code hasn’t been run enough times to become eligible for JIT compilation, it likely doesn’t contribute any significant time to the whole runtime, so I doubt it would be a meaningful change.
> some optimizations are only possible under a closed-world assumption (AOT)
Which a JIT compiler is more than free to assume much more strictly than an AOT one can? Like, if it sees that only a single implementing class of an interface is loaded it can assume that every virtual method call can be replaced by a static one. Upon a class load, this assumption can be revisited and the native code can be deoptimized in cases. In an AOT compiler you have to optimize based on the worst case, while JIT compiler may avoid loading that class based on some dynamic property. Also, Graal is not only an AOT compiler, it is also a JIT compiler with.. closed-world assumptions, so it is quite meaningless comparison.
The last point is true on paper, but as far as I know it is not true that JIT compilers produce worse code, and even if it is it is not due to lack of time/resources.
But I just wanted to refute the performance claims — Graal Native executables do start up much faster and have significantly less memory usage, which are worthwhile goals in themselves. But most Java code will perform better under a JIT compiler (which can be Graal’s as well)
> " But most Java code will perform better under a JIT compiler (which can be Graal’s as well)"
It does seem sort of counterintuitive though, doesn't it? Like, what's the point of an optimizing JIT then?
I understand the Native Image stuff becoming part of OpenJDK, but what does it mean for OpenJDK to get the GraalVM JIT? does it replace the one in OpenJDK? will OpenJDK have two JIT implementations to choose from?
This is different than using GraalVM, which has all the polyglot stuff too. And the Native Image AOT stuff is different yet again ... I think! There's a lot of uses of the same core technology. It's pretty cool stuff!
https://spring.io/blog/2022/09/26/native-support-in-spring-b...
My experience has involved zero headaches or serious problems due to Graal, and it comes with appreciable performance improvements.
One of the more impressive and badass hardcore programming language engineering efforts, and still under active development right now. It's remarkable technology.
Amazing that it comes from within Oracle, I was surprised.
It's a kickass JVM with stellar performance and bonus profiling/observability tools.
Every other part of Graal is also ordinary java classes, for example Truffle, which can execute interpreters and JIT optimize them very effectively (Truffle’s javascript can run after warm up with comparable speed as V8, while the former has orders of magnitude smaller team/budget). This is possible because the JIT compiler has a few special intrinsics for these libraries that allow for this magic, and also the reuse of the many many thousands of workhours that went into the OpenJDK project, reusing its killer GCs, etc.
I would guess they see this a way to actually trigger adoption of GraalVM CE, beyond the language nerds, a couple of more adventurous companies and also it is a safer way for other JVM vendors to enter the game.
What JIT does definitely better is when coupled with PGO data that survives between execution sessions.
[1] https://www.graalvm.org/22.3/reference-manual/java/compiler/
1. The new JIT
2. The Native Image, AOT
Reflection is an issue for (2), not (1).