Spring Boot BackgroundPreinitializer

[Sebastien Deleuze]

I like the idea of a property, but it would be really nice if it could be
set automatically by the AOT support without requiring an additional action
from the users because they typically don't add such property when
documented and we just want to detect the actual AOT caching mode in a
reliable and consistent way.

What about having an aot.mode property reflecting the actual mode:
 - "record" when "-XX:AOTMode=record" is specified or a potential future
"-XX:AOTMode=autocreate" (replacement of "-XX:CacheDataStore=app.cds") is
specified and no cache files exist
 - "on" when "-XX:AOTMode=on" is specified or a potential future
"-XX:AOTMode=autocreate" (replacement of "-XX:CacheDataStore=app.cds") is
specified and cache files exist
- "off" when "-XX:AOTMode=off" is specified

I can see multiple use cases for that with Spring (reporting, disabling
BackgroundPreinitializer, refining Spring behavior during the training run,
etc.) that will likely be useful for others as well.

Side note: we really hope that a "-XX:CacheDataStore=app.cds" successor
will be introduced because it really helps to not have to change the java
command line between training and deployment runs for some deployment
scenarios.

On Fri, Oct 4, 2024 at 8:03 AM <ioi.lam at oracle.com> wrote:

> On 10/3/24 12:59 AM, Sebastien Deleuze wrote:
>
> Hi,
>
> I would like to bring to the attention of the working group
> https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/BackgroundPreinitializer.java
> that we are using to speedup Spring Boot startup time on machines with at
> least 2 cores on the JVM.
>
> It creates and drops instances of popular but costly to initialize
> instances (Jackson, Hibernate Validator, etc.) and invoke some JDK methods (
> StandardCharsets.UTF_8.name(), 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.
>
>
> 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.
>
> I would like to ask feedback on those 3 points:
>  - 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.
> - 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).
>
>
> 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.
>
> 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?
>
>
>  - 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.
>
> 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"?
>
> Thanks
>
> - Ioi
>
>
>  Any thoughts?
>
> 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.
>
>

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