AOT code usage restrictions

[Vladimir Kozlov]

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.
>