Investigate alignment with Project Leyden

[sdeleuze]

Closely related to the "Spring AOT and Project Leyden" section of the "Runtime efficiency with Spring" blog post, we should explore how combining AppCDS support (see #31497) with a first class support of Spring AOT on the JVM (see #31501) can allow a synergy with Project Leyden premain optimizations (CDS + AOT on steroids for the JVM) upcoming developments and how Spring developers can take advantage of it.

[sdeleuze]

I have updated https://github.com/sdeleuze/spring-boot-leyden-demo to leverage the new Leyden 1 step workflow that is much simpler to use than the previous 5 steps workflow. I think not all optimizations are enabled yet, but the data points seems promising. Notice I have for now only measured the startup time improvements, not yet the warmup time improvements.

The -XX:CacheDataStore option is intended to be a replacement for the existing -XX:SharedArchiveFile option

In practice, this is indeed a drop in replacement for Class Data Sharing which can take advantage of Spring Framework CDS support. If I am not mistaken, the meaning of CDS will evolve from Class Data Sharing to Cache Data Store and provide improved performances and extended scope (warmup improvement in addition to startup time ones).

[sdeleuze]

See #32044 related documentation issue.

[sdeleuze]

Spring team feedback sent to the leyden-dev mailing list about:

• Leyden-premain optimizations
• Negative lookup cache for class loaders

[sdeleuze]

I turn this issue into a task as a significant amount of exploration has been done, with a lot of potential but no short/middle term actionable item identified at Spring Framework level in Spring Framework 6.2 timeframe.

In terms of vocabulary, it looks like what was initially named Cache Data Store, tentatively reusing the CDS acronym, is going to be named "AOT", which we can maybe qualify with "JVM AOT" or "AOT cache" to avoid confusions with Spring AOT, GraalVM AOT, etc.

The full list of JEPs related to Project Leyden are currently:

• JEP 483: Ahead-of-Time Class Loading & Linking
• JEP draft: Ahead-of-Time Code Compilation
• JEP draft: Ahead-of-Time Method Profiling

In terms of feature, the AOT cache introduced by Project Leyden can be seen as a CDS successor that is based on our measurements approximatively twice as fast on typical Spring Boot applications, but is also more than that since it allows to store the warmness of a JVM for signficantly better performance after cold start and faster warmup to reach peak performance. Memory consumption has not yet been a focus, but we hope to observe middle/long term the same or better benefits than CDS.

The faster startup use case is very similar to CDS, and continue to take advantage of -Dspring.context.exit=onRefresh at Spring Framework level, of the self-extract capabilities provided by Spring Boot 3.3+, and the Buildpacks CDS support could potentially evolve to support AOT cache by using a future JDK supporting it and adapting the command line parameters.

The warmup capabilities are very different, because they will likely require an integration at Platform level with a regular startup rather than at Spring Boot or Buildpacks level with -Dspring.context.exit=onRefresh because the remote services need to be reachable to warm the JVM. Even if local options like Docker Compose or TestContainers were used, the constraints in terms of classpath, JVM versions, and workload generation make it hard to imagine an arrangement that will work at Spring Boot or Buildpacks level. Creating the AOT cache with integration tests is possible in theory but extremely difficult in practice due to various AOT cache constraints not fulfilled, especially on class loading side.

The Spring team continues to collaborate closely with Project Leyden team, upcoming progresses will be shared in conferences (like in the upcoming Devoxx BE 2024 Project Leyden joint talk) and Spring blog.