JEP 483: Ahead-of-Time Class Loading & Linking says:
For a representative server application, consider Spring PetClinic, version 3.2.0. It loads and links about 21,000 classes at startup. It starts in 4.486 seconds on JDK 23 and in 2.604 seconds on JDK NN when using an AOT cache — also an improvement of 42%, by coincidence. The AOT cache occupies 130 megabytes.
Curious about the statistics I tried to replicate the result:
java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -jar target/spring-petclinic-3.4.0-SNAPSHOT.jar
java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -jar target/spring-petclinic-3.4.0-SNAPSHOT.jar
java -XX:AOTCache=app.aot -XX:AOTMode=on -jar target/spring-petclinic-3.4.0-SNAPSHOT.jar
Unfortunately I haven't obtained the same results. First of all the Spring PetClinit has ~17000 classes. On my machine startup time is ~3.2s
while with cache ~2.8s
, the relative difference is quite far from what mentioned by the jep 483. Supposing that the Oracle team didn't made up the numbers :), it's not clear to me why there is such an important difference between my test result and the statistics published.
JEP 483: Ahead-of-Time Class Loading & Linking says:
For a representative server application, consider Spring PetClinic, version 3.2.0. It loads and links about 21,000 classes at startup. It starts in 4.486 seconds on JDK 23 and in 2.604 seconds on JDK NN when using an AOT cache — also an improvement of 42%, by coincidence. The AOT cache occupies 130 megabytes.
Curious about the statistics I tried to replicate the result:
java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -jar target/spring-petclinic-3.4.0-SNAPSHOT.jar
java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -jar target/spring-petclinic-3.4.0-SNAPSHOT.jar
java -XX:AOTCache=app.aot -XX:AOTMode=on -jar target/spring-petclinic-3.4.0-SNAPSHOT.jar
Unfortunately I haven't obtained the same results. First of all the Spring PetClinit has ~17000 classes. On my machine startup time is ~3.2s
while with cache ~2.8s
, the relative difference is quite far from what mentioned by the jep 483. Supposing that the Oracle team didn't made up the numbers :), it's not clear to me why there is such an important difference between my test result and the statistics published.
1 Answer
Reset to default 1You have to extract the JAR first as described in the Spring Blog.
The reason for this is that Spring boot uses a custom class loader for nested JARs.
Java does not provide any standard way to load nested jar files (that is, jar files that are themselves contained within a jar). This can be problematic if you need to distribute a self-contained application that can be run from the command line without unpacking.
And Launching Executable Jars
The
Launcher
class is a special bootstrap class that is used as an executable jar’s main entry point. It is the actualMain-Class
in your jar file, and it is used to setup an appropriateClassLoader
and ultimately call yourmain()
method.
From the description of the JEP:
It is not a goal to cache classes that are loaded by user-defined class loaders.
java -Djarmode=tools -jar spring-petclinic-3.4.0-SNAPSHOT.jar extract --destination application
java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -jar application/spring-petclinic-3.4.0-SNAPSHOT.jar
java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -jar application/spring-petclinic-3.4.0-SNAPSHOT.jar
java -XX:AOTCache=app.aot -jar application/spring-petclinic-3.4.0-SNAPSHOT.jar