Initialization code that never got trained
María Arias de Reyna Dominguez
mariasde at redhat.com
Wed Jan 7 08:18:42 UTC 2026
Hi!
Thanks! I will try to take a closer look and see what is exactly what is
happening.
Right now, a comparison on a Quarkus native vs Quarkus Leyden (J26 main
latest) is close to six or seven times faster on the tests I have done. But
that may be test-dependent, so I have to dig further.
On Sun, Jan 4, 2026 at 6:23 PM Dan Heidinga <dan.heidinga at oracle.com> wrote:
> Happy new year!
>
> > For example: a REST API. It has some initialization, port opening,
> reading configurations,
> > etc... that run only once. So the code will never be trained. But it
> always runs at startup,
> > impacting the time to first response.
>
> Historically, JVMs have looked at run-once code - like the body of
> <clinit> - as not being worth compiling as the return on the investment in
> compile time is too low. There have always been exceptions but even
> template style jits have avoided run once code.
>
> Can you quantify how much of the applications startup is spent in these
> run-once methods?
>
> > So, how can I tell Leyden to please compile and cache those functions,
> even if they are
> > going to be run just once, even if they are not optimized at all, even
> if those compilations
> > can get discarded after a couple of seconds?
>
> Compiling the code isn’t enough. There’s a lot of work with careful
> timing required to get the code ready for use before the first invocation.
> If we miss that window, then the compiled code is just overhead.
>
> For “expensive” or long running single use code, we may be able to
> precompile with C1 and get out of the interpreter earlier at the cost of
> some coordination overhead to ensure the methods are installed immediately.
>
> I think we’d need to understand better where the time is being spent to
> see why this run once code is slowing down startup.
>
> —Dan
>
> *From: *leyden-dev <leyden-dev-retn at openjdk.org> on behalf of María Arias
> de Reyna Dominguez <mariasde at redhat.com>
> *Date: *Tuesday, December 30, 2025 at 4:13 AM
> *To: *leyden-dev <leyden-dev at openjdk.org>
> *Subject: *Initialization code that never got trained
>
> Happy New Year!
>
> I have been doing some experiments with Leyden and realized something:
> there is some code at startup/initialization that never gets optimized but
> is impacting on startup and warmup time.
>
> This was a realization while doing comparisons with native/graalvm images
> of the same code.
>
> For example: a REST API. It has some initialization, port opening, reading
> configurations, etc... that run only once. So the code will never be
> trained. But it always runs at startup, impacting the time to first
> response.
>
> Compared to a native image, the native image may not have it optimized,
> but at least it is already compiled, not interpreted. Therefore, the native
> image starts faster.
>
> So, how can I tell Leyden to please compile and cache those functions,
> even if they are going to be run just once, even if they are not optimized
> at all, even if those compilations can get discarded after a couple of
> seconds?
>
> Or are we just going to assume that that code, which is impacting startup
> time, doesn't need to be pre-compiled because we are focusing only on
> optimizations made by the JVM on runtime?
>
> Kind regards,
> María Arias de Reyna Domínguez
> Senior Software Engineer
> She / Her / Hers
> ariasdereyna at redhat.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20260107/c7f344df/attachment.htm>
More information about the leyden-dev
mailing list