Payara Micro 5.201 adds two command line options that make preparation of container images easier, as well as enable class data sharing on HotSpot Java Virtual Machine.
We recently looked at utilizing class data sharing (CDS) with OpenJ9. Java virtual machines may store their internal representation of class data in a CDS archive, sparing time spent on finding and parsing class files. Since the Payara Micro Runtime consists of tens of thousands of classes, this brings tangible improvements to startup time.Before the Payara Micro release 5.201, there were two drawbacks to utilizing CDS:
- The startup gains are only visible on second startup, which doesn't play well with immutable containers; it was hard to do prepare the container during its build phase.
- While OpenJDK has application class data sharing feature, it only works with System classloader, which was not where most of Payara Micro classes resided.
We are happy to announce that these limitations don't exist anymore with Payara Micro 5.201!
In this article we'll explain the new features that enable it and show how to prepare pre-warmed Docker image that utilizes Class Data Sharing with OpenJDK 11.
Runtime Root Directory Launcher
When you start Payara Micro you are usually greeted with this first log message:
Payara Micro Runtime directory is located at .../payaramicro-rt....tmp
The bootstrap process extracts all of the configuration files as well as runtime libraries into this directory and then passes control to actual server implementation. It is possible to specify persistent location for this runtime directory by specifying command line argument
--rootdir, however this dynamic nature of bootstrap doesn't change in this case.
Payara Micro 5.201 adds new execution mode with flat classpath launcher bound to specific runtime directory. To create such launcher, execute:
java -jar payara-micro.jar --rootdir micro-root --outputlauncher
This will extract runtime directory into directory micro-root and add two extra files in there:
.env. To launch Payara Micro you can now use
java -jar micro-root/launch-micro.jar
The jar file has all of the runtime libraries directly on its classpath and therefore all runtime classes are eligible for CDS optimization on OpenJDK. The extraction step of runtime libraries is also skipped in this case, so neither special option
noTimestampChecks is needed when running on OpenJ9. Resulting root directory is self sufficient, and you will not need
payara-micro.jar for running the instance.
You can pass any arguments to
launch-micro.jar just as you would to
payara-micro.jar, with two exceptions:
--rootdirargument is ignored. The launcher assumes it resides in a root directory and will use its location as one.
--addlibsto extend runtime classpath is not supported. You can however pass it to
--outputlauncherand the libraries will be added to classpath of the launcher statically.
In case you cannot use
-jar to run the launcher, file
.env contains classpath, main class as well as additional arguments to use to launch micro with other command line options to
The second ingredient to preparing your runtime image is an ability to configure your runtime directory in a script. To enable that we added a very simple command line switch
--warmup. It will cause the instance to shutdown as soon as it finishes its startup, which includes executing pre-boot and post-boot scripts, deployment of all applications and executing post-deploy scripts.
This can be used for variety of use cases, like
- Preparing resources like database connection pools separately from deployment, simplifying number of command line arguments necessary for productive run
- Preparing Docker image with applications already deployed into runtime directory
- Collecting class loading information for preparing class data sharing archive
Preparing warmed-up Docker image
So let's combine these two features to get our optimized Docker image. Let's assume you've got
payara-micro.jar handy (with Payara version >= 5.201), and your application is
app.war. This is the what the Docker file would look like:
CDS Speeds Up Deployment About 40%
In our measurements, CDS speeds up deployment by approximately 40%. Its only drawback is that the CDS archive is quite big, 160 to 180 megabytes. We believe that it is a reasonable price to pay for startup improvement.
Also, when you run multiple containers based on the same image or on same layer with CDS archive, only a single copy of that archive resides in the memory and is shared across all of the containers, sparing memory usage of your host.
Take a look at "What's New in Payara Platform 201" for more info about the latest release.