From dan.heidinga at oracle.com  Sun Jan  4 17:23:10 2026
From: dan.heidinga at oracle.com (Dan Heidinga)
Date: Sun, 4 Jan 2026 17:23:10 +0000
Subject: Initialization code that never got trained
In-Reply-To: <CAH4CYDVjBvMP3D5DNbv8J6j7h7015pRzMVn7a5iu37QmrE50+Q@mail.gmail.com>
References: <CAH4CYDVjBvMP3D5DNbv8J6j7h7015pRzMVn7a5iu37QmrE50+Q@mail.gmail.com>
Message-ID: <PH0PR10MB458499E8E32D41C699F8EC42E7B9A@PH0PR10MB4584.namprd10.prod.outlook.com>

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<mailto:ariasdereyna at redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20260104/8832ff55/attachment.htm>

From mariasde at redhat.com  Wed Jan  7 08:18:42 2026
From: mariasde at redhat.com (=?UTF-8?Q?Mar=C3=ADa_Arias_de_Reyna_Dominguez?=)
Date: Wed, 7 Jan 2026 09:18:42 +0100
Subject: Initialization code that never got trained
In-Reply-To: <PH0PR10MB458499E8E32D41C699F8EC42E7B9A@PH0PR10MB4584.namprd10.prod.outlook.com>
References: <CAH4CYDVjBvMP3D5DNbv8J6j7h7015pRzMVn7a5iu37QmrE50+Q@mail.gmail.com>
 <PH0PR10MB458499E8E32D41C699F8EC42E7B9A@PH0PR10MB4584.namprd10.prod.outlook.com>
Message-ID: <CAH4CYDWn7GwQpX3-KrF8Z8nAE7tBqPZTbfENgALJp+J-=eiiKg@mail.gmail.com>

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>