AOT cache distribution with my application

[Joffrey Bion]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20251105/cdfaa43a/attachment.htm>