<div dir="ltr"><div>I agree with Dan. We don't want users to force compilation of methods, rather we should let that happen organically.</div><div><br></div><div><div>As for excluding the test framework from compilation, we already have options to do that in the premain branch.</div><div>For instance there is DontPrecompile to exclude a method from AOT compilation in the assembly phase.</div><div>There is IgnorePrecompiled to ignore the AOT code for a method in the production run.</div></div><div><br></div><div>Apart from the canary deployments, there is another scenario where the users may have an offline training run and drive it through the synthetic load.</div><div>In such a scenario, it may make sense to lower the execution count threshold that triggers compilation to reduce the execution time of the training run required to get a good quality cache.</div><div>For example if the user knows beforehand a hot code path of the application, then the compilation of this code path can be triggered early by reducing the threshold.</div><div>Theoretically this sounds useful, but in practice it can be difficult to do this right.</div><div><br></div><div><div>@Maria, btw the link you referred to is for IBM SDK which is likely based on OpenJ9. I don't think these options exist for Hotspot.</div><div><div>But there may be options in Hotspot with similar behavior. My understanding is most of these options are for diagnostic purposes, not for end users to tune their application.</div></div></div><div><br></div><div><div>Thanks,</div></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">- Ashutosh Mehra</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 15, 2025 at 10:58 AM Dan Heidinga <<a href="mailto:dan.heidinga@oracle.com" target="_blank">dan.heidinga@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">



<div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
That’s a great question - restating my understanding of it: “Is it useful to hardcode specific JIT options that compile early, force methods to be compiled, etc while training?”</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
We’ve always said that training should match production as closely as possible.  The more closely they match (ie: training in production using canary deployments) the better as the training produces training data that exactly matches what the JVM is doing during
 startup and warmup (and will likely continue to do in future deployments).</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
If we tweak the JIT settings from the side for training, we may distort the training run in ways that are less useful and result in us missing training data (like profiles) that would be useful if we need to deopt+recompile in the production run.</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
That’s my long way of saying if you wouldn’t deploy those options on your production runs, you probably don’t want them on your training runs either.</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
—Dan</div>
<div dir="ltr" style="font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div id="m_-4341907213839479424m_-676066462383760632mail-editor-reference-message-container">
<div dir="ltr"></div>
<div style="text-align:left;padding:3pt 0in 0in;border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor;font-family:Aptos;font-size:12pt;color:black">
<b>From: </b>leyden-dev <<a href="mailto:leyden-dev-retn@openjdk.org" target="_blank">leyden-dev-retn@openjdk.org</a>> on behalf of María Arias de Reyna Dominguez <<a href="mailto:mariasde@redhat.com" target="_blank">mariasde@redhat.com</a>><br>
<b>Date: </b>Monday, December 15, 2025 at 4:36 AM<br>
<b>To: </b>leyden-dev <<a href="mailto:leyden-dev@openjdk.org" target="_blank">leyden-dev@openjdk.org</a>><br>
<b>Subject: </b>Does it make sense to tweak compilation for training?<br>
<br>
</div>
<div dir="ltr">Hi!<br>
<br>
</div>
<div dir="ltr">While searching for good documentation to link to when explaining Leyden, I found this (rather old) page:
<a href="https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-xjit-xnojit" target="_blank">
https://www.ibm.com/docs/en/sdk-java-technology/8?topic=options-xjit-xnojit</a> with compilation options I didn't know existed.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">And I was wondering: does it make sense to force some things during training run to make sure we get the best training? I'm thinking for example on forcing a high level of compilation on
 some methods, so we arrive to production with more things optimized. Or excluding some "testing framework" methods from compilation.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Or is it better not to touch anything and let Java run normally because this may become too unpredictable?</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Or... should I play with this and see what happens because we don't really know? :)</div>
<div dir="ltr"><br>
</div>
<div dir="ltr" class="gmail_signature">Kind regards,<br>
María Arias de Reyna Domínguez<br>
Senior Software Engineer<br>
She / Her / Hers<br>
<a href="mailto:ariasdereyna@redhat.com" target="_blank">ariasdereyna@redhat.com</a></div>
</div>
</div>

</blockquote></div>