AOT code usage restrictions

[Astigeevich, Evgeny]

In AOT code of most common applications, what percentage of code usually uses the latest CPU features?
If the percentage is small, would it be more practical not to use only that code?
Also to make the percentage smaller, C2 might make a decision whether to use those feature or not.
For example, if a function contributes 1% to a profile, 0.5% improvement would be when CPU features speed up the function 2x times.

Thanks,
Evgeny Astigeevich

--

From: leyden-dev <leyden-dev-retn at openjdk.org> on behalf of Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date: Friday, 23 January 2026 at 19:32
To: leyden-dev at openjdk.org <leyden-dev at openjdk.org>
Subject: RE: [EXTERNAL] AOT code usage restrictions

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.



Thank you, Andrew, for your thoughts.

I just want to point out that using generic instructions in AOT code
(AOTed adapters, stubs, nmethods) in deployment will force new JITed
code also use generic instructions. That is it - VM runtime (stack
walking, deoptimization, registers saving) requires generated code
(JITed and AOTed) to use the same set of instructions and registers. As
result we may not reach peak performance on modern machines which we
will get when running without such AOT code.

I did not measure difference in peak performance. But even if it is
"small" for some our customers it will be showstopper.
The cases 1. and 2. will work better for them.

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

Thanks,
Vladimir K

On 1/23/26 10:34 AM, Andrew Haley wrote:
> On 1/23/26 2:04 AM, Vladimir Kozlov wrote:
>> What do you think about this proposal?
>
> I think Options 1 and 2, "AOT code will not be used if CPU features on
> machine for production run does not match" is unlikely to be practical
> for production code because of the enormous variety of machine
> capabilities. So even on a system like AWS, you might not be able to
> move code from Graviton 4 to Graviton 3. Everybody will hate that.
>
> It is very important that our default target be really simple and really
> generic, such as Armv8.0 or x86-64.
>
> GCC's x86-64 default is simply x86-64, which means Opteron of 2003.
>
> GCC's AArch64 default is Armv8.0, with some instructions that are
> available on later ISA versions handled by library stubs. For example,
> the compare-and-swap instructions are callouts. We could do that
> ourselves, or perhaps decide that Armv8.1, which has a full set of
> compare-and-swap instructions, is our baseline.
>
> It's interesting to note that most operating systems and other programs
> people install are compiled with default options that correspond to
> really old machines. I don't think that many people are troubled by
> that. Few people tune compiled code to specific architecture versions,
> except for super-critical tweaked code such as video codecs.
>
> GCC also allows the option "-march=native", which will use every feature
> you've got, and it also allows many named sub-arch options if you know
> the name of the exact target. I don't think we'll want to have hundreds
> of options like GCC, though.
>
> In the end, I think we're just going to have to do Option 3, as GCC
> does. Default to generic, maybe with callouts to stubs in some cases,
> with a command-line option to compile for this native machine.
>
> Andrew.
>




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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20260123/23930835/attachment.htm>