AOT code usage restrictions

[Vladimir Kozlov]

Thank you, Sanne and other

Note, AOT code presence "currently" affects only startup (first few 
[milli]seconds). We observed that we need to replace it ASAP with JITed 
code to reach peak performance sooner. So even if AOT code is not used 
(due to different instructions set), it will most likely will not be 
noticed in deployment scenarios.

During today Leyden meeting we agreed to go with "native" AOT code 
generation default (instructions set on training machine) and not use 
AOT code if AOT cache is used on machine with different instructions set.

It is safest approach for the JEP. After this JEP we can work on 
improving situation to provide simple way to generate and use "generic" 
AOT code and other usages of AOT code.

Thank you all for this discussion,
Vladimir K


On 1/27/26 8:42 AM, Sanne Grinovero wrote:
> Hello all,
> 
> As a lead developer on Quarkus, I’ve been following Leyden closely and 
> collaborating with our team (Andrew Dinn, Andrew Haley, Ashutosh, Maria, 
> et al.) on its implications for Java. I intend to get into the habit of 
> sharing feedback here directly more often.
> 
> I prefer Vladimir's initial proposal, as it favors the "first 
> impression" and provides better defaults for the audience least likely 
> to tune their settings. Most developers will first evaluate Leyden on a 
> single machine or identical hardware. If we restrict out-of-the-box 
> benefits to avoid edge-case hardware mismatches, we risk a "lukewarm" 
> initial experience. The edge-case you'd be addressing isn't a critical 
> failure. Java should feel fast by default; we shouldn't penalize the 90% 
> to protect the 10% who are already equipped to handle configuration.
> 
> In Quarkus, we intend to ship container images with preloaded AOT 
> archives.This implies I should be advocating for the opposite as we’ll 
> need portability, but as an image maintainer, I expect to customize the 
> bootstrap with ad-hoc parameters better fitting our intent, and anyone 
> shipping a specialized end-user product will exercise that same 
> discretion. So this won't at all be be a problem for us.
> 
> Finally, I’d like to stress the importance of the JVM maintaining its 
> edge when compared to GCC/LLVM-compiled alternatives. We spend enough 
> time debunking the myth that Java is slow; the JVM needs to demonstrate 
> its peak performance potential to individuals who may not be aware of 
> its full capabilities.
> 
> Large-scale users with heterogeneous cloud environments might need 
> different settings, but they have both the resources and the motivation 
> to implement staging environments in which such problems will be caught, 
> and aren't going to be intimidated by the need to set any new flag.Let’s 
> keep the entry barrier low for everyone else.
> 
> Thanks,
> Sanne
> 
> On Mon, Jan 26, 2026 at 11:24 AM Andrew Haley <aph- 
> open at littlepinkcloud.com <mailto:aph-open at littlepinkcloud.com>> wrote:
>  >
>  > On 26/01/2026 09:38, Severin Gehwolf wrote:
>  > > IMHO, the default should be "generic".
>  >
>  > While I (slightly) agree with you about the default, as long as the
>  > options are easy to select with a single command-line argument, it might
>  > not matter very much in practice.
>  >
>  >  > Consider that they could run into the trap
>  >  > of thinking they'd get a good boost, but then are disappointed on the
>  >  > production run because the AOT code cache cannot be used and is being
>  >  > thrown away. The user walks away being disappointed and might only >
>  >  > > come back trying the feature with a later JDK release.
>  >
>  > That's a good point, well made. I'd say something radical: don't have a
>  > default, but force the user to choose. They'd get used to that wuickly
>  > enough.
>  >
>  > Andrew.
>  >
>  >