
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

In AOT code of most common applications, what percentage of code usually uses the latest CPU features?</div>

<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

If the percentage is small, would it be more practical not to use only that code?</div>

<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Also to make the percentage smaller, C2 might make a decision whether to use those feature or not.</div>

<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

For example, if a function contributes 1% to a profile, 0.5% improvement would be when CPU features speed up the function 2x times.</div>

<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Thanks,</div>

<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Evgeny Astigeevich</div>

<div style="direction: ltr; font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div id="ms-outlook-mobile-signature">

<div>-- </div>

<div style="direction: ltr;"><br>

</div>

</div>

<div id="mail-editor-reference-message-container">

<div class="ms-outlook-mobile-reference-message skipProofing">

<meta name="Generator" content="Microsoft Exchange Server">

</div>

<div class="ms-outlook-mobile-reference-message skipProofing" 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 <leyden-dev-retn@openjdk.org> on behalf of Vladimir Kozlov <vladimir.kozlov@oracle.com><br>

<b>Date: </b>Friday, 23 January 2026 at 19:32<br>

<b>To: </b>leyden-dev@openjdk.org <leyden-dev@openjdk.org><br>

<b>Subject: </b>RE: [EXTERNAL] AOT code usage restrictions<br>

<br>

</div>

<div class="PlainText" style="font-size: 11pt;">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.<br>

<br>

<br>

<br>

Thank you, Andrew, for your thoughts.<br>

<br>

I just want to point out that using generic instructions in AOT code<br>

(AOTed adapters, stubs, nmethods) in deployment will force new JITed<br>

code also use generic instructions. That is it - VM runtime (stack<br>

walking, deoptimization, registers saving) requires generated code<br>

(JITed and AOTed) to use the same set of instructions and registers. As<br>

result we may not reach peak performance on modern machines which we<br>

will get when running without such AOT code.<br>

<br>

I did not measure difference in peak performance. But even if it is<br>

"small" for some our customers it will be showstopper.<br>

The cases 1. and 2. will work better for them.<br>

<br>

When you said x86-64 do you mean SSE2 (default fro 64 bits), AVX0 or AVX2?<br>

<br>

Thanks,<br>

Vladimir K<br>

<br>

On 1/23/26 10:34 AM, Andrew Haley wrote:<br>

> On 1/23/26 2:04 AM, Vladimir Kozlov wrote:<br>

>> What do you think about this proposal?<br>

><br>

> I think Options 1 and 2, "AOT code will not be used if CPU features on<br>

> machine for production run does not match" is unlikely to be practical<br>

> for production code because of the enormous variety of machine<br>

> capabilities. So even on a system like AWS, you might not be able to<br>

> move code from Graviton 4 to Graviton 3. Everybody will hate that.<br>

><br>

> It is very important that our default target be really simple and really<br>

> generic, such as Armv8.0 or x86-64.<br>

><br>

> GCC's x86-64 default is simply x86-64, which means Opteron of 2003.<br>

><br>

> GCC's AArch64 default is Armv8.0, with some instructions that are<br>

> available on later ISA versions handled by library stubs. For example,<br>

> the compare-and-swap instructions are callouts. We could do that<br>

> ourselves, or perhaps decide that Armv8.1, which has a full set of<br>

> compare-and-swap instructions, is our baseline.<br>

><br>

> It's interesting to note that most operating systems and other programs<br>

> people install are compiled with default options that correspond to<br>

> really old machines. I don't think that many people are troubled by<br>

> that. Few people tune compiled code to specific architecture versions,<br>

> except for super-critical tweaked code such as video codecs.<br>

><br>

> GCC also allows the option "-march=native", which will use every feature<br>

> you've got, and it also allows many named sub-arch options if you know<br>

> the name of the exact target. I don't think we'll want to have hundreds<br>

> of options like GCC, though.<br>

><br>

> In the end, I think we're just going to have to do Option 3, as GCC<br>

> does. Default to generic, maybe with callouts to stubs in some cases,<br>

> with a command-line option to compile for this native machine.<br>

><br>

> Andrew.<br>

><br>

<br>

</div>

</div>

<br><br><br>Amazon Development Centre (London) Ltd.Registered in England and Wales with registration number 04543232 with its registered office at 1 Principal Place, Worship Street, London EC2A 2FA, United Kingdom.<br><br><br>

</body>

</html>