Initialization code that never got trained

[Dan Heidinga]

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>