<div dir="ltr"><div>Hi Vladimir,</div><div><br></div>I also vote for "General" as the default.<div><br></div><div>We can imagine the following scenario:</div><div><br></div><div><ol><li>A user has been using JDK NN to run training in an environment that supports the XYZ instruction.<br>However, JDK NN does not support XYZ instructions, so the AOT cache they generate can run on devices that do not support XYZ instructions.<br>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, <br>the generated AOT cache becomes invalid on devices that do not support the XYZ instruction.</li><li>A user performs a training run on a 12th-generation Intel Core platform, generating an AOT cache that includes AVX-512 instructions.<br>Initially, this AOT cache worked on other devices with the same hardware, but after some devices updated their firmware, <br>the AVX-512 instruction set was disabled by Intel, causing the AOT cache to become invalid on these devices.<br></li></ol><div><br></div></div><div>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. </div><div>JDK version, firmware version, firmware settings, system version, kernel settings, etc., can all break these assumptions.</div><div><br></div><div>I believe that correctly using -march=native to generate AOT caches is a task that requires expertise and should not be the default behavior.</div><div><br></div><div>Glavo</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 23, 2026 at 10:05 AM Vladimir Kozlov <<a href="mailto:vladimir.kozlov@oracle.com">vladimir.kozlov@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I would like to get opinion from community regarding AOT code usage <br>
restrictions for JEP <a href="https://openjdk.org/jeps/8335368" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8335368</a>.<br>
<br>
For current AOT features in JDK 25 and 26 it is not the issue - CPU <br>
features do not affect them.<br>
<br>
CPU features affect generated AOT code - the instructions set is defined <br>
by machine on which AOT training is done. But CPU instructions on <br>
machine where AOT cache is used could be different.<br>
<br>
Our current proposal is next:<br>
<br>
1. The best startup and peak performance with AOT code could be achieved <br>
when training and production runs use the same type of machines (same <br>
CPU and OS).<br>
<br>
2. AOT code will not be used if CPU features on machine for production <br>
run does not match one used for training. Other AOT features (cached <br>
classes and profiling info) will still be used.<br>
<br>
3. In a future, when user requested during training run (with VM's <br>
flag[s]), we will allow to use AOT code generated for old CPU <br>
instructions (for example, AVX2) on machines with new instructions (for <br>
example, AVX512) by restricting online (normal JIT) code generation to <br>
old CPU instructions. This will allow to use the same cached AOT code on <br>
variety of machines. But you may not get the best peak performance on <br>
newer machines.<br>
<br>
What do you think about this proposal?<br>
<br>
Thanks,<br>
Vladimir K<br>
<br>
</blockquote></div>