Spring Boot BackgroundPreinitializer

[ioi.lam at oracle.com]

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