<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="moz-cite-prefix">On 10/3/24 12:59 AM, Sebastien Deleuze
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAG5jep8yGapirKOmpM6ennZmVn4GqiUCz+oav++8OMyOcMrhmw@mail.gmail.com">
<div dir="ltr">Hi,<br>
<br>
I would like to bring to the attention of the working group <a href="https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java</a>
that we are using to speedup Spring Boot startup time on
machines with at least 2 cores on the JVM.<br>
<br>
It creates and drops instances of popular but costly to
initialize instances (Jackson, Hibernate Validator, etc.) and
invoke some JDK methods (<a href="http://StandardCharsets.UTF_8.name" moz-do-not-send="true">StandardCharsets.UTF_8.name</a>(),
ZoneId.systemDefault()) to pre-load related classes and
pre-initialize related static fields on a dedicated thread. I
think with the AOT cache, the class-preloading effect is not
visible anymore, maybe the pre-initialization of static fields
still has an impact. <br>
<br>
</div>
</blockquote>
<br>
<blockquote type="cite" cite="mid:CAG5jep8yGapirKOmpM6ennZmVn4GqiUCz+oav++8OMyOcMrhmw@mail.gmail.com">
<div dir="ltr">Ideally, I would hope that this kind of
optimization will not be needed anymore with Leyden AOT cache in
order to avoid creating instances that we drop, avoid to throw
related exceptions when the libraries are not in the classpath,
etc.
<div><br>
</div>
<div>I would like to ask feedback on those 3 points:<br>
- It may be interesting to compare what
BackgroundPreinitializer does at runtime and the effect of AOT
cache on related classes as we know those ones are impacting
badly the startup time of typical enterprise applications and
see if AOT cache could be refined with optimizations similar
to what BackgroundPreinitializer does at runtime.
<div>- If we can't optimize more automatically, I am wondering
if the idea of giving the possibility to frameworks to
specify a list of costly classes safe to initialize in the
AOT cache makes sense or not (Spring Boot could configure
the one present in BackgroundPreinitializer for example).<br>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>In the near term, we will not be able to support pre-initialized
classes that are outside the JDK core libraries. There are many
issues with class initlization and cached Java heap objects that
we haven't solved yet. We are starting to have some
pre-initialized classes inside the core libraries. We hope we can
learn from the experience so we can open up the feature to other
use cases.<br>
</p>
<p>However, if the initialization of some classes are indeed
bottlenecks, maybe such code paths would be picked up by the AOT
compiler so that they can finish faster than with JIT only?</p>
<p><br>
</p>
<p></p>
<blockquote type="cite" cite="mid:CAG5jep8yGapirKOmpM6ennZmVn4GqiUCz+oav++8OMyOcMrhmw@mail.gmail.com">
<div dir="ltr">
<div>
<div> - It could be potentially useful to publish an API to
know if AOT caching is enabled or not to allow us to disable
this kind of mechanism in that case, something simple and
fast like a method returning a boolean.<br>
<br>
</div>
</div>
</div>
</blockquote>
<p>We could add an API or a property to indicate if AOT cache is
used. But perhaps the user can simply specify a property like
"java -XX:AOTCache=xxx -Dusing.aot.cache=true ... MyApp"?</p>
<p>Thanks</p>
<p>- Ioi<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CAG5jep8yGapirKOmpM6ennZmVn4GqiUCz+oav++8OMyOcMrhmw@mail.gmail.com">
<div dir="ltr">
<div>
<div> Any thoughts?<br>
</div>
</div>
</div>
<br>
<span style="background-color:rgb(255,255,255)"><font size="2">This
electronic communication and the information and any files
transmitted with it, or attached to it, are confidential and
are intended solely for the use of the individual or entity to
whom it is addressed and may contain information that is
confidential, legally privileged, protected by privacy laws,
or otherwise restricted from disclosure to anyone else. If you
are not the intended recipient or the person responsible for
delivering the e-mail to the intended recipient, you are
hereby notified that any use, copying, distributing,
dissemination, forwarding, printing, or copying of this e-mail
is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your
computer, and destroy any printed copy of it.</font></span>
</blockquote>
</body>
</html>