AOT code usage restrictions

[Sanne Grinovero]

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>
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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20260127/89430cdd/attachment.htm>