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.
Java bytecode is what we mean when we say 'compile'. AOT is 'ahead of time' with regard to clojure, since it compiles to bytecode at run-time normally.
AOT already means something to clojurists. It means removing the extra runtime compilation phase of .clj into classfiles. The JIT is what the JVM does, which still occurs just like before.
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).
"AOT" in the clojure world means compiling your clojure source down to JVM bytecode, which also means compiled-in calls against a particular state of clojure's internal java api. By shipping clojure source, one avoids any concerns over incidental changes to internal code.
Wait, I didn't realize they implemented a JIT cache before their AoT compilation option. It seems like pre-populating a JIT cache, dumping it to disk, and throwing that in as an extra resource in a JAR would have a lot fewer caveats than at least their first implementation of AoT Java compilation.
It is a matter of implementation and tooling, not language.
Anyone is free to create a native AOT compiler for Clojure.
In fact many attempted to do so, but have given up due to the effort it means bringing a full eco-system up to speed to what Clojure already enjoys in JVM, .NET and JS runtimes, libraries and tooling.
Specially in quality of generated native code and GC implementations.
if you mean clojure AOT, it precompiles clojure to jvm bytecode. Usually the term JIT in this context is used to describe the native code generated by the VM on the flight, not the on the flight VM bytecode generation performed by a higher level language like clojure.
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.
>Make it compile low-level vs. byte code so it's fast as shit.
AOT compilation is not automatically faster than JIT compilation. Java already is fast as shit. If you're worried about that first 100 milliseconds, works is being done on AOT compilation.
AOT is actually often slower than the JVM because it doesn't have runtime profiling. It is possible to use AOT with runtime profiling (i.e. run your app in some real world manner, capture the data and then AOT with the runtime data).
But the point here is that JVM (and V8 actually) can do more than simple compiling by understanding the nature in which the program runs and therefore be quite fast often making up for the fact they are VMs.
The problem is that a lot of software in the Java world explicitly relies on it not being compiled AOT. Any standard tomcat or jboss/wildfly application for example.
> AOT compilation for Java alone is just a technique to improve startup time for command line apps vs actually native apps; AOT shared libs still need JVM infrastructure for GC.
That’s true with the JVM’s AOT project, but SubstrateVM is entirely separate – you get a single binary that runs standalone.
That said I'm not that surprised that class aot compilation didn't really speed up a clojure app.
reply