bookmark-service<\/code> of my Quarkus Dojo bookmarkit<\/a> starts in 1,2s on my laptop.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/loicmathieu.fr\/wordpress\/wp-content\/uploads\/quarkus_metrics_graphic_bootmem_wide.png?resize=640%2C296&ssl=1\")
\nAnother point not mentioned, is the size of the Docker image. A native application will only contain the code used by the application (thanks to the dead code elimination of GraalVM), as well as a minimalist JVM (SubstrateVM), and will therefore be smaller than a standard image which embeds all the third parties libraries as well as a full JVM.<\/p>\n
However, deploying your Quarkus application as a native application has a few drawbacks:<\/p>\n
- Because of the close world assumption<\/em> of GraalVM, all the libraries used must be GraalVM compatible. This is guaranteed for Quarkus extensions, but for others, it’s up to you to check, and there can sometimes be unpleasant surprises.<\/li>\n\n
- SubstrateVM is a partial JVM, it does not support JMX or JVM-TI (and therefore no Java agents), which can greatly complicate monitoring and administration of your application.<\/li>\n\n
- A native application has peak performance that is lower than an application deployed in the JVM. Mainly because the Java Just-In-Time Compiler (JIT) will profile your application during its use and will therefore be able to make more relevant optimizations than GraalVM which performs these optimizations during compilation (Ahead-Of-Time compiler – AOT ).<\/li>\n<\/ul>\n
If you want to deploy your Quarkus application in a standard JVM, but optimize its startup time and the size of the Docker image, then Jlink<\/strong> and AppCDS<\/strong> can help you!<\/p>\nIn the following paragraphs, I will use the application bookmark-service<\/a> as example. A JVM at least 11 is necessary (I used OpenJDK 11.0.5).<\/p>\nJlink<\/h2>\n
Jlink<\/strong> allows to generate a custom JVM which will contain only the needed modules to make your application runnable and operationnal. This is made possible thanks to the modularization of the JDK which was made for Java 9 (JSR-376<\/a> – projet Jigsaw). Who says reduced size of JVM, also says smaller Docker image!<\/p>\nJlink<\/strong> takes as input the list of modules to include in your customized JVM. To know this list, you must use the tool jdeps<\/strong>.<\/p>\nFirst of all, you must configure Quarkus to generate a fat jar (or uber jar) so that jdeps <\/strong> can analyze all the code of your application. To do this, add the following property to your application.properties<\/code> :<\/p>\nquarkus.package.uber-jar=true<\/code><\/pre>\nWe then package the application via mvn clean package<\/code>.<\/p>\nThen we launch the jdeps<\/strong> command with the --list-deps<\/code> option which allows you to list the modules on which your application depends.<\/p>\nHere is the result of the jdeps <\/strong> command with the uber jar of the bookmark-service<\/code> application:<\/p>\n$ jdeps --list-deps target\/bookmark-service-1.0-SNAPSHOT-runner.jar \n JDK removed internal API\/org.relaxng.datatype\n java.base\/sun.security.util\n java.base\/sun.security.x509\n java.compiler\n java.datatransfer\n java.desktop\n java.instrument\n java.logging\n java.management\n java.naming\n java.rmi\n java.security.jgss\n java.security.sasl\n java.sql\n java.transaction.xa\n java.xml\n jdk.jconsole\n jdk.management\n jdk.unsupported\n<\/code><\/pre>\nTo create your custom JVM, you must use jlink<\/strong> by giving it the list of modules resulting from the call to the command jdeps<\/strong> via the option --add-modules<\/code>. Small subtlety, the two modules java.base\/sun.security.util<\/code> and java.base\/sun.security.x509<\/code> must not be integrated, but we must integrate the java.base<\/code> module instead. I don’t know where this result inconsistency of the jdeps<\/strong> command comes from, but the java.base<\/code> module is used by any Java application, so it must always be present.<\/p>\nFor the bookmark-service<\/code> application, here is the jlink<\/strong> command that I used:<\/p>\n$ jlink --no-header-files --no-man-pages --output target\/customjdk --compress=2 --strip-debug\\\n--module-path $JAVA_HOME\/jmods --add-modules java.base,java.base,java.base,java.compiler,\\\njava.datatransfer,java.desktop,java.instrument,java.logging,java.management,java.naming,\\\njava.rmi,java.security.jgss,java.security.sasl,java.sql,java.transaction.xa,\\\njava.xml,jdk.jconsole,jdk.management,jdk.unsupported\n<\/code><\/pre>\nAs I wanted to have the smallest possible JVM, I added the following options to the jlink <\/strong> command:<\/p>\n--no-header-files<\/code> : Do not include header files,<\/li>\n\n--no-man-pages<\/code> : Do not include man pages,<\/li>\n\n--compress=2<\/code> : ZIP level compression for compressible files,<\/li>\n\n--strip-debug<\/code> : Do not include debug information.<\/li>\n<\/ul>\nAfter that, we can use the JVM generated in the target\/customjdk<\/code> directory to launch our application:<\/p>\n$ target\/customjdk\/bin\/java -Xmx32m -jar target\/bookmark-service-1.0-SNAPSHOT-runner.jar\n<\/code><\/pre>\nIf we compare the startup of our application with our custom JVM and the standard JVM, there is no advantage to RSS or startup time. The only interest here is the size of the JVM which went from 314MB to 51MB!<\/p>\n
Ideally, this should be automated in your Docker build via a multi-stage Dockerfile …<\/p>\n
To go further on jlink<\/strong>, I invite you to consult this article: Using jlink to build java runtimes for non modular applications<\/a>.<\/p>\nAppCDS – Application Class Data Sharing<\/h2>\n
Warning: if you want to use AppCDS<\/strong> with jlink<\/strong>, you will have to use your custom JVM in the commands of this paragraph instead of your default JVM.<\/p>\nOne of the reasons for the consequent start-up time of a Java application is that, for each class, the JVM must load it from disk, verify it, then create a specific data structure (class metadata).<\/p>\n
Application Class Data Sharing (AppCDS) is a functionality with which we can create an archive of the metadata of our classes, to avoid doing it at startup. Once these metadatas are loaded, there is no difference in behavior with an application not using AppCDS.<\/p>\n
There are three steps for using AppCDS<\/strong>:<\/p>\nStep 1<\/strong>: Creating the list of classes to archive.<\/p>\njava -XX:DumpLoadedClassList=target\/classes.lst -jar target\/bookmark-service-1.0-SNAPSHOT-runner.jar\n<\/code><\/pre>\nI stopped the application right after launching it, but we can imagine using it a little longer (launching a functional test for example) to make sure that all the code of the application has been called, and therefore as many classes as possible will be listed.<\/p>\n
Step 2<\/strong>: Generating the archive with the JVM option -Xshare:dump<\/code> which asks AppCDS<\/strong> to create it.<\/p>\njava -Xshare:dump -XX:SharedClassListFile=target\/classes.lst -XX:SharedArchiveFile=target\/app-cds.jsa --class-path target\/bookmark-service-1.0-SNAPSHOT-runner.jar\n<\/code><\/pre>\nThis command does not launch the application. It will generate a 69MB app-cds.jsa<\/code> file that we can then use to launch our application.<\/p>\nStep 3<\/strong>: We launch the application by passing it the created archive as an argument.<\/p>\njava -XX:SharedArchiveFile=target\/app-cds.jsa -jar target\/bookmark-service-1.0-SNAPSHOT-runner.jar\n<\/code><\/pre>\nWith an archive, the application launches in 500ms instead of 1.2s, which makes a -60% startup time<\/strong>!<\/p>\nUnfortunately, there is no difference in terms of memory footprint.<\/p>\n