AOT cache distribution with my application

[ioi.lam at oracle.com]

Hi Joffrey,

Thanks for you feedback.

You're correct that we have changed the AOT configuration file to a 
binary format that's tied to the same JDK executable that generated it. 
It cannot be used on a different OS, or CPU, or even a different version 
of the JDK on the same OS/CPU.

The Leyden design philosophy is that the training/assembly should be 
done in an environment as close to the production run as possible. In 
your scenario, since you are creating the AOT cache on first execution, 
would it be possible to do a training run on first execution as well? 
E.g, from something like:

     java -XX:AOTMode=create -XX:AOConfiguration=pregenerated.config 
-XX:AOTCache=app.aot

to

     java -XX:AOTCacheOutput=app.aot -cp $JARS myapp.Training

For short running programs such as command-line tools, I think the 
training run can be relatively short, and should take less time than it 
takes to create the AOT cache (especially when AOT code compilation is 
supported in the future). Therefore, I think this will not take 
significantly longer than your proposed approach.

Technically it's not impossible to support an alternative format for the 
AOT configuration file to be portable. We probably need a way to 
serialize the existing contents into a text file, and then read it back 
in the AOT assembly phase. One disadvantage is it will not cover 
platform-dependent classes, so this could be sub-optimal (e.g., for 
programs that makes a lot of file operations).

$ cd openjdk/src/java.base
$ find windows -name \*.java | wc
      70      70    3745
$ find linux -name \*.java | wc
      32      32    1804
$ find macosx -name \*.java | wc
      36      36    2043

Therefore, we are a bit hesitant to go back to the text-based config 
file due to development cost and performance implication.

Thanks

- Ioi


On 11/5/25 3:21 AM, Joffrey Bion wrote:

> Hi,
>
> At JetBrains we're working on a JVM-based command-line tool called 
> Amper. We're trying to optimize startup time using AOT features, but 
> we're in a bit of a pickle regarding the AOT cache portability.
>
> The way our application is setup is the following:
> * we build our project, and package our runtime classpath jars into a 
> .tgz, which we call our "distribution". This is done from a single 
> (Linux) host on our CI.
> * we provide a wrapper script to users, which they should check into 
> their VCS repo (akin to gradlew). This wrapper script downloads the 
> proper JRE for Amper and the distribution tgz (if they are not already 
> present on the machine), and then runs the application.
>
> Our plan was the following:
> * perform an AOT training run on a single CI host (the one that 
> publishes our application), record the amper.aotconf once, and package 
> it within our distribution tgz
> * then, have our wrapper script generate the AOT cache from the 
> aotconf on the end user machine during the first run.
>
> This way, we remove the training run hassle (and time overhead) from 
> the users, but still generate the OS/arch/environment-specific cache 
> on the end user machine.
>
> However, it seems that the AOT config (output of the training run) 
> will no longer be portable:
> https://bugs.openjdk.org/browse/JDK-8348426
>
> And the response here seems to confirm this:
> https://mail.openjdk.org/pipermail/leyden-dev/2025-March/001781.html
>
> > In JDK 25 and going forward, we are collecting execution profile during
> > AOT training. As a result, we have changed the AOT configuration 
> file to
> > a binary file format that's tied to the execution platform of the JVM.
> > You can see more information from
> > https://bugs.openjdk.org/browse/JDK-8348426
> >
> > The profile data is difficult to be represented in a cross-platform
> > format (e.g., a text file). The need for "cross platform builds" has
> > come up before in our design discussion. We have decided to defer it 
> and
> > focus on delivering optimizations for the most common use cases first.
> > We might re-evaluate this decision in the future when we have more user
> > feedback (and more time :-)
>
> So my question is: what is the plan of the project Leyden team 
> regarding our use case (non-server applications that run on different 
> types of user machines)? Are there any plans to allow app authors to 
> somehow bundle AOT data from a training run in a portable format 
> together with the jars of the application?
> We're using the JVM for the "write once, run anywhere" benefit, so it 
> feels a bit awkward for us to create individual distributions for our 
> users (and it's a CI hassle). On the other hand, moving the training 
> run to the user machine means that we might have to expose part of 
> this to the users, or make them wait for a long time in some sort of 
> installation/optimization phase. Neither of these options are ideal, 
> hence why we're hoping for a solution right from the AOT feature.
>
> Thanks a lot in advance,
> Joffrey