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.
It's a shame that Sun/Oracle never partnered with them to bring native apps. This could have saved Java on the desktop.
The big difference until GraalVM and OpenJ9 became available as open source, was that all those vendors made AOT compilation a commercial feature, and thus most devs never cared they existed.
In fact GraalVM was one of the main reasons Excelsior JET eventually closed doors.
I don't remember if GCJ supported loading and running code dynamically with a built-in JIT or interpreter. I think it was just pure AOT, which caused some compatibility headaches.
I wish we had GCJ resurrected, now that the java libraries are GPL'd.
Its biggest downside was the use of Boehm GC that had some issues with large heaps.
Therefore I don’t see AOT-only becoming an integral part of standard Java in the foreseeable future.
Existing code bases can be a pain, though, especially applications that heavily rely on things like C++/CLI and COM Interop that basically need to be rewritten from scratch.
Which is not to say that it's intended to replace the traditional JIT runtime in applications where it isn't troublesome, because it's not.
Yes, and that’s a significant limitation in the Java library and framework ecosystem.
i guess what i am saying is that AOT-only case is not "standard java", but something that will make a (more) useful replacement for things like c/c++.
[1] -- https://www.graalvm.org/latest/reference-manual/native-image... [2] -- https://github.com/oracle/graal/issues/11327
There's a reason why folks keep coming back to JIT compilation. It's hard to beat the value that can be gained from actually gathering data on how the code is actually used, which leads to a whole set of potential optimisations (which is the problem Profile Guided Optimisation attempts to solve for AOT compiled code.) The JVM is arguably one of the most advanced and capable JITing runtimes.
As with anything it's a trade off. Fast start times, pretty fast running (I think maybe less memory usage?); vs the full JIT speed you can get on the JVM at the cost of start-up speed and memory consumption. All depends on what you want to use the application for.
If you're talking something like a serverless function, go native. If you're talking production server where you're measuring runtime in more than dozens of minutes, probably better to stick to the JVM & JIT.
I suppose write once run anywhere is no longer a goal either.
"It is not a goal to support all CPU architectures currently supported by HotSpot."
This pretty much validates the point of view that VM design is now baggage, as a sandbox it has been flawed, for performance it's been prohibitive, and cross platform portability by virtue of being virtual, was just a convenient byproduct.
AI now handles the portability, sandbox security hasn't changed (cf. docker still has sandbox problems, LLMs have sandbox problems, it's always an ongoing concern) and that just leaves Java, as always, chasing performance.
- "Improve startup and warmup time by making optimized native code for an application instantly available when the HotSpot Java Virtual Machine starts."
- "If the workload changes in production, regenerate native code dynamically for continued peak performance, providing the best of both ahead-of-time (AOT) and just-in-time (JIT) compilation."
- "Ensure that shifting from AOT-compiled code to JIT-compiled code is invisible to applications."
That is JEP544 doesn't substitute JVM and JIT optimizations. It just changes the nature of the JIT's outcome.