<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>The way our application is setup is the following:</div><div>* 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.</div><div>* 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.</div><div><br></div><div>Our plan was the following:<br>* 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</div><div>* then, have our wrapper script generate the AOT cache from the aotconf on the end user machine during the first run.</div><div><br></div><div>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.</div><div><br></div><div>However, it seems that the AOT config (output of the training run) will no longer be portable:<br><a href="https://bugs.openjdk.org/browse/JDK-8348426">https://bugs.openjdk.org/browse/JDK-8348426</a></div><div><br></div><div>And the response here seems to confirm this:<br><a href="https://mail.openjdk.org/pipermail/leyden-dev/2025-March/001781.html">https://mail.openjdk.org/pipermail/leyden-dev/2025-March/001781.html</a></div><div><br></div><div>> In JDK 25 and going forward, we are collecting execution profile during</div>> AOT training. As a result, we have changed the AOT configuration file to <br>> a binary file format that's tied to the execution platform of the JVM. <br>> You can see more information from <br>> <a href="https://bugs.openjdk.org/browse/JDK-8348426">https://bugs.openjdk.org/browse/JDK-8348426</a><br>> <br>> The profile data is difficult to be represented in a cross-platform <br>> format (e.g., a text file). The need for "cross platform builds" has <br>> come up before in our design discussion. We have decided to defer it and <br>> focus on delivering optimizations for the most common use cases first. <br>> We might re-evaluate this decision in the future when we have more user <br>> feedback (and more time :-)<div><br></div><div>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?</div><div>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.</div><div><br></div><div>Thanks a lot in advance,</div><div>Joffrey</div></div>