Why JVM boots a bit faster starting Java 12

Question

It's a slight but noticeable difference:

$ for j in {5..12}; do . chjdk $j; time (java -version; for i in {1..1000}; do java x >/dev/null; done); echo ""; done
java version "1.5.0_22"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_22-b03, mixed mode)

real    2m4.988s
user    0m59.832s
sys 0m18.856s

java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

real    0m28.055s
user    0m24.012s
sys 0m4.216s

java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)

real    0m31.225s
user    0m24.836s
sys 0m3.564s

java version "1.8.0_202"
Java(TM) SE Runtime Environment (build 1.8.0_202-b08)
Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode)

real    0m43.463s
user    0m35.948s
sys 0m6.516s

java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)

real    1m29.909s
user    1m37.892s
sys 0m12.972s

java version "10.0.1" 2018-04-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.1+10)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.1+10, mixed mode)

real    1m21.161s
user    1m24.412s
sys 0m13.044s

openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

real    0m56.932s
user    1m8.892s
sys 0m9.516s

openjdk version "12" 2019-03-19
OpenJDK Runtime Environment (build 12+33)
OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)

real    0m39.930s
user    0m38.876s
sys 0m9.520s

Has something changed specifically as part of Java 12 release or it's a measurement error?

---

Update

Indeed JVM boots faster. Thanks to LppEdd and Holger for the reference.

JEP 341 - Default CDS Archives.

When you start a Java application, thousands of classes are being loaded, which seems like JVM slows down the startup.

Class Data Sharing is a feature which was introduced as a commercial feature starting JDK 8 Update 40. It allows you to pack all the startup classes into an archive of specific format, after which the application start up time has increased. After a while, the JEP 310: Application Class-Data Sharing was introduced, which allowed us to do the same not only with the system classes, but also with the application classes.

For JDK classes, it looks like this. First we dump the classes with the java -Xshare:dump, and then launch the application, telling it to use this cache: java -Xshare:on -jar app.jar. And the startup speed has improved a little.

But it seemed strange to write -Xshare: dump every time, if the default result of executing this command is a bit predictable at the stage of creating the JDK distribution. According to the documentation, if the Java 8 distribution was installed using the installer, then right at the time of installation it should run the necessary commands for you. But why? And what to do with the distribution kit, which is distributed not in the form of an installer, but as a zip archive?

Since the JDK 12 CDS archive will be generated by the creators of the distribution, immediately after linking. Even for nightly builds (assuming they are 64-bit and native, not for cross-compiling).

Starting with JDK 11, -Xshare: auto is enabled by default, and such an archive will be picked up automatically. Thus, simply updating to JDK 12 speeds up the launch of the application!

Answer 1

This might be related to JEP 341 - default CDS Archives, which is new for JDK 12.

Summary
Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

Goals
Improve out-of-the-box startup time
...

From what I've understood, the same behaviour could have been accomplished even in previous releases, by using the -Xshare:dump / -Xshare:on parameters. This JEP just makes it a default.

---

Thanks to Holger for the Oracle article on Class Data Sharing.