JEP 483: Ahead-of-Time Class Loading and Linking

What does this mean for Clojure? At least loading the Clojure runtime should benefit, but what about app code loading.

The concern that jumps out at me is: what about flags that affect code generation? Some are tied to the subarch (e.g. "does this amd64 have avx2?" - relevant if the cache is backed up and restored to a slightly different machine, or sometimes even if it reboots with a different kernel config), others to java's own flags (does compressed pointers affect codegen? disabling intrinsics?).

For reference this is part of Project Leyden [1][2] which was introduced in 2022 with the first ideas showcased at JVMLS 2023 [3].<p>[1] <a href="https:&#x2F;&#x2F;openjdk.org&#x2F;projects&#x2F;leyden&#x2F;" rel="nofollow">https:&#x2F;&#x2F;openjdk.org&#x2F;projects&#x2F;leyden&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;inside.java&#x2F;tag&#x2F;leyden" rel="nofollow">https:&#x2F;&#x2F;inside.java&#x2F;tag&#x2F;leyden</a><p>[3] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=lnth19Kf-x0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=lnth19Kf-x0</a>

Note that OpenJ9 and Azul already do similar optimizations.<p>And Android while not being a Java&#x2F;JVM proper, more of a cousin, also has similar JIT cache concept as intermediate step before doing AOT compilation of selected code.<p>Naturally also welcomed on the OpenJDK distributions.

Nice, any time optimization is welcome :)

Sweet!

I&#x27;m a dunce

i’m curious if any of this was inspired from aws lambda snapstart

&gt; [example hello world] program runs in 0.031 seconds on JDK 23. After doing the small amount of additional work required to create an AOT cache it runs in in 0.018 seconds on JDK NN — an improvement of 42%. The AOT cache occupies 11.4 megabytes.<p>That’s not immediately convincing that it will be worth it. It is a start I guess.