Well, quite a few people already use AOT with PGO from GraalVM to build native executables of Clojure programs. Those start stupidly fast. I never heard of anyone doing so with OpenJ9, how good is the AOT of OpenJ9?
AppCDs in OpenJDK currently has terrible ergonomics. Clojure can't really offer it. Each user must go out of their way to leverage it. So you can't really release an app that automatically leverage it, the user needs to launch it with all the command incantations, etc. And it's so sensitive to class path changes, etc. It kind of sucks to be honest. But some people still use it for prod release, since you can set it up in a docker easily. But the use-case for fast startup are desktop apps, CLIs, scripts, etc. And for all those, AppCDs are super annoying to setup. See: https://ask.clojure.org/index.php/8353/can-we-use-appcds-to-...
Still, AppCDs don't fully solve the startup issue, because all the static initializations stuff takes a considerable amount of time, and that does not get cached by AppCDs.
There's also the OpenJDK CraC project (coordinated checkpoint and restore) which isn't a native AOT compiler as such but which also delivers faster starting applications by starting a service and storing the entire JVM state including compiled code.
OpenJDK supports various kinds of AOT too, which also supports dynamic class loading. However the performance boost at startup is not as significant as with native-image/SubstrateVM/GraalVM because it stays spec compliant.
Any savy Java developer knows how to AOT compile to native code, if that really matters.
There are plenty of JDKs that support it, and even Oracle is finally adding support for it with Java 9, initially only for Linux x64.
By Java 10 timeframe no one that only knows about OpenJDK and not the several other JDKs can state that Java starts slow vs C, because both will be AOT compiled to native code, loading native .so files.
I've run small services built with Java, Go and Crystal to achieve good startup and throughput performance while minimizing memory usage. My experience with Crystal is limited but has been positive thus far.
The sweet spot for me is using Java with OpenJ9 which has very fast startup time while sacrificing only a bit of top-end throughput.
I would only choose AOT if packaging/deployment were issues with the JIT approach. In the case of Go, AOT is practically free but I prefer not being limited to array/slice, map, and channel generics.
OpenJDK's AOT compiler, when you also allow it to include the JIT and still recompile hotspots, is about 5% slower than just using the JIT. The only reasons to use it are startup times, ease of distribution (no JVM to ship, sort of), and for use in places that don't allow JITs (iOS).
Maybe I'm missing something or I'm just blind but where is there AOT compilation in your example since you seem to run the same jar with the same command-line options.
That said I'm not that surprised that class aot compilation didn't really speed up a clojure app.
I think it was an error from Sun not to offer AOT in addition to JIT, but apparently they were religious against the idea, only offering it on the embedded JDKs.
This could have made Java actually relevant on the desktop, ignoring for a second how clueless Sun was about doing good desktop libraries.
However with Java 9 you will be able to use the new Java linker and create you own little VM + AOT startup code.
So that coupled with the large Java eco-system is already good enough for many of us.
Swift does compile to AOT today, but the tooling and libraries outside Apple platforms is almost insignificant, and only good enough for startups willing to bet on it.
Many don't use them, because they are commercial tools, and many developers nowadays don't like to pay for software.
The only limitation is that for reflection code one needs to white list which classes end up on the binary.
All major third party commercial JVMs always had the capability of AOT to native code, it was just tabu at Sun.
Oracle has other point of view thus kept the Maxime project alive, rebranded it into Graal, and now those that don't like to pay for developer tools can also enjoy AOT compilation to native code via SubstrateVM, GraalVM and Graal integration into OpenJDK.
Just Windows support is not yet fully done for the time being.
Their long term roadmap is to rewrite the C++ parts of OpenJDK in Java itself, also known as Project Metropolis.
OpenJDK 11 also adopted a feature already common in another commercial JVMs, which allows a JVM to dump a JIT image before existing. Which then allows for AOT like startup on the 2nd execution onwards.
Also Java isn't the only safe alternative to C, those that don't mind lack of generics can just pick Go instead of dealing with C.
Which then we already have several high profile projects using it, including Google's exploratory microkernel based OS.
An AOT compiler was definitely the primary goal in the early years (my employer was contracted to deliver one for embedded developers). However, for a few of us at least, the main driver eventually became just to have a Free Software implementation of a high-performance Java-compatible toolchain and runtime for Linux. An AOT compiler based on GCC seemed like the best way to get there at the time. And for a while we were right. The GCJ compiled Eclipse was faster than any JIT-compiled Eclipse a few years back.
AOT compilation has come back to JVM languages both on HotSpot and Graal. There are now lots of ways to remove JVM startup time penalties and most of them provide for startup times that are as fast as Python independent of code size.
You can do either. You can compile a snapshot and run that on the JIT VM. This basically gives you faster startup because it doesn't have to do all the source parsing, resolution, type-checking, etc. but gives you the general runtime performance of a JIT VM (think V8 or the JVM).
Or you can AoT compile your app all the way to native code. It's similar to how a shipped Go or OCaml works where it compiles your code and the language's runtime together into a single executable.
Since around 2000 there has been support for AOT in Java commercial JDKs, or JIT caches across execution runs.
So living with slow-ish startup times and let the JIT warm up was mostly a matter for those not wanting to shell out money for them.
Actually, most likely Graal Community edition and its integration in OpenJDK, alongside AppCDS (from J/Rockit), while IBM also brought their AOT/JIT tooling into OpenJ9 that made Excelsior JET decide it wasn't worth any longer.
So besides the BEA, Oracle, IBM commercial compilers now turned into free beer, PTC, Aicas are the surviving ones, but they target embedded scenarios.
And then there is Android Java with JIT/AOT as well.
Do you mean the Graal JIT compiler or AOT compiling? The former may at times be better at escape analysis, but I don’t think there would be a significant difference. Using an up-to-date GC implementation is already night-and-day (I use G1GC with slightly decreased target pause time and larger heap size. But ZGC would be probably the best for this use case)
I’m not sure whether Intellij could be AOT compiled, would be interesting due to faster startup time but AOT compiled binaries can be somewhat slower than what the JIT compiler is capable of.
From what I've seen Java/JVM AOT won't produce binary executables but shared libraries that will be loaded on startup by the JVM.
When I first read about Java AOT-compilation I expected it to produce real executables that's why I think this is important to mention.
But please correct me if I am wrong.
So if this is true even with AOT compilation you still need the JVM as dependency (although I think you can get a minimal JVM in under 10MB).
It also seems that the AOT compiled code needs to be recompiled on Java updates.
Although I quite like Java and the JVM, I still wouldn't choose Java for writing simple command line tools.
Nevertheless it is quite useful for improving startup for tools like Gradle or server applications.
But sure, I also don't expect Java startup performance to be a problem in the mid- to long-run.
AppCDs in OpenJDK currently has terrible ergonomics. Clojure can't really offer it. Each user must go out of their way to leverage it. So you can't really release an app that automatically leverage it, the user needs to launch it with all the command incantations, etc. And it's so sensitive to class path changes, etc. It kind of sucks to be honest. But some people still use it for prod release, since you can set it up in a docker easily. But the use-case for fast startup are desktop apps, CLIs, scripts, etc. And for all those, AppCDs are super annoying to setup. See: https://ask.clojure.org/index.php/8353/can-we-use-appcds-to-...
Still, AppCDs don't fully solve the startup issue, because all the static initializations stuff takes a considerable amount of time, and that does not get cached by AppCDs.
reply