AOT code usage restrictions

[Glavo]

Hi Vladimir,

I also vote for "General" as the default.

We can imagine the following scenario:


   1. A user has been using JDK NN to run training in an environment that
   supports the XYZ instruction.
   However, JDK NN does not support XYZ instructions, so the AOT cache they
   generate can run on devices that do not support XYZ instructions.
   If JDK NN+1 supports the XYZ instruction, then after a user migrates
   from JDK NN to JDK NN+1 and performs a training run with the same options,
   the generated AOT cache becomes invalid on devices that do not support
   the XYZ instruction.
   2. A user performs a training run on a 12th-generation Intel Core
   platform, generating an AOT cache that includes AVX-512 instructions.
   Initially, this AOT cache worked on other devices with the same
   hardware, but after some devices updated their firmware,
   the AVX-512 instruction set was disabled by Intel, causing the AOT cache
   to become invalid on these devices.


It can be seen that if the instructions used in the AOT cache depend on the
training environment, then it will contain many fragile assumptions.
JDK version, firmware version, firmware settings, system version, kernel
settings, etc., can all break these assumptions.

I believe that correctly using -march=native to generate AOT caches is a
task that requires expertise and should not be the default behavior.

Glavo


On Fri, Jan 23, 2026 at 10:05 AM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Hi,
>
> I would like to get opinion from community regarding AOT code usage
> restrictions for JEP https://openjdk.org/jeps/8335368.
>
> For current AOT features in JDK 25 and 26 it is not the issue - CPU
> features do not affect them.
>
> CPU features affect generated AOT code - the instructions set is defined
> by machine on which AOT training is done. But CPU instructions on
> machine where AOT cache is used could be different.
>
> Our current proposal is next:
>
> 1. The best startup and peak performance with AOT code could be achieved
> when training and production runs use the same type of machines (same
> CPU and OS).
>
> 2. AOT code will not be used if CPU features on machine for production
> run does not match one used for training. Other AOT features (cached
> classes and profiling info) will still be used.
>
> 3. In a future, when user requested during training run (with VM's
> flag[s]), we will allow to use AOT code generated for old CPU
> instructions (for example, AVX2) on machines with new instructions (for
> example, AVX512) by restricting online (normal JIT) code generation to
> old CPU instructions. This will allow to use the same cached AOT code on
> variety of machines. But you may not get the best peak performance on
> newer machines.
>
> What do you think about this proposal?
>
> Thanks,
> Vladimir K
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20260126/552a5513/attachment.htm>