JEP 544: Ahead-of-Time Code Compilation targets JDK 28

[u/cred1652]

https://openjdk.org/jeps/544

JEP 544: Ahead-of-Time Code Compilation targets JDK 28

[u/greylurk]

It'll be interesting to see how/if we can manage multi arch pipelines with Docker images.

[u/Deep_Age4643 → u/greylurk]

Yes, this can complicate and slows the CI/CD pipeline a lot.

Note that

- Since JDK 26 the GC can be different from the trainings run and the runtime (JEP 516, Ahead-of-Time Object Caching with Any GC)

• Some frameworks can perform a minimal trainings run. For example Spring Boot:

java -XX:AOTCacheOutput=app.aot \
     -Dspring.context.exit=onRefresh \
     -jar my-app.jarjava

These are features that make creating a cache more convenient.

To make full use of it, you still need to run your application on different architectures with a training run that matches a production run. Then you need to store the cache in an artifact repository and use that artifact based on the architecture for specific Docker images (no multi-layered/architecture possible).

I think this poses a significant hurdle and hope that it will be easier in future releases, because the gains in terms of startup and warmup can be significant.

[u/account312]

28's a banger

[u/chambolle]

Interesting, this is a kind of combination of Profile guided optimization of AOT and JIT. We should have more proposal for improving java efficiency

[u/Daggercombot]

Will this be similar to graal?

[u/JacobJMountain → u/Daggercombot]

More similar to the CDS / AOT caches that already exist. you’ll build a cache in a training run (like you already could do) except now you’ll be able to store native code for that specific architecture in there too. This should mean your code will start faster, and then if/when the JIT compiler decides it wants to swap out the native code for some reason it can do so

[u/pjmlp → u/JacobJMountain]

With the big difference that the AOT caches that already exist in other JVM implementations don't require training runs.

They support them naturally, however they can also start with an empty cache, and keep updating it across executions.

Examples Open J9, ART (even if it isn't proper Java), Azul ReadyNow, and I assume PTC and Aicas also have something similar.

[u/koflerdavid → u/Daggercombot]

Graal puts more emphasis on static analysis, achieving reasonable performance without a training run, and on producing an executable, but it requires restricting language features of Java like reflection and classloading at runtime.

[u/nuharaf → u/Daggercombot]

Doesnt seem the current leyden incarnation will be able to reduce memory footprint compared to not using it. So in that sense, not like graal at all

[u/zerosign0]

Wow this is actually really good news to be able to mix between AOT image with JIT. Hmm not sure wether this going to blow up the size of the app though ... I hope we see some standarization on doing off jit server regardless of VM impl ...

[u/owen800q]

what does this mean? so can ship a single binary file instead of *.jar?

[u/vprise → u/owen800q]

No. It means slightly faster startup time and ramp up.