AOT code usage restrictions

[Charles Oliver Nutter]

Commenting from a user perspective, since we very much want to ship AOT
caches for JRuby users...

The restriction seems fine largely because I don't know how else you'd work
around it. But I think with this restriction there needs to be a clear way
to AOT for a lowest common denominator without having that exact hardware
on hand. I don't want to have to find some janky old x86 machine to train a
portable cache on.

On Thu, Jan 22, 2026, 20:05 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/20260122/2397e30f/attachment.htm>