Reducing Java Startup Time: 4 Approaches
Transcript
Application Class Data Sharing (AppCDS)
Do you want to reduce the startup and warm-up time of your Java applications from minutes to milliseconds? In this video, we will explore four approaches to making your Java services start up faster or even almost instantly. Any application uses classes for its work, and all these application classes and core JVM classes must be loaded and initialized at application start. But this process repeats with every startup. So the idea behind application class data sharing for apps is ideas. Is to avoid repeating this process every time the application starts, but to load a set of system classes and application classes once and store this data in an archive. This archive is then used as a read-only metadata by the JVM. Reading the archive is faster than loading the classes from scratch, so the startup is faster. In addition, multiple JVM processes can use the same archive. With AppCDS, you can achieve about 40% better startup. If you use Spring Boot, you can enable ahead-of-time processing, and the application startup will be faster by more than 50%. The key advantage of AppCDS is that it enables tangible startup improvement without the need for code refactoring. Project Leyden is an open JDK project under development.
Project Leyden
The project is focused on shifting some commutations and optimizations from run time to some earlier stages, for instance, training runs. Then the application will use pre-compiled code and classes during the production run, and so the startup will be faster. Project Leyden uses apps CDS, ahead-of-time compilation and other techniques of shifting computations that will enable a reuse of transformed code without breaking the compatibility with the Java platform specification. But Java is a very dynamic language. It won't allow shifting computations randomly. So the project team will work towards introducing permitted constraints to the Java platform specification. They will be weaker than closed world constraints, where more applications and can use them. The goal is to introduce full closed world constraint in the future. Early access bills of project laden are already available. I have tried them out with a Springwood application and got three times faster startup. So we are looking towards production ready builds. Graal VM native image is the technology that uses ahead-of-time compilation to perform static analysis and convert Java code into machine code at build time. As a result, a Java app is turned into a fully compiled native executable. A single executable contains pre-initialized necessary application classes, required library classes, and statically linked code from the JDK
GraalVM Native Image
The key advantages of Graal VM native image are very rapid startup in one second or less, and immediate peak performance without warmup. One consideration when using Graal VM native image, you have to provide a metadata about all cases of dynamic features used in your application in a special config file, or else the native executable may behave unexpectedly or crash during the production run. Coordinated Restore Checkpoint, or CRaC for short, is an open JDK project. It enables you to create an image of a running and warmed up Java service, save it to the file.
Coordinated Restore at Checkpoint (CRaC)
Replicate this file among cloud instances and then restore the application from the file from the moment it was posted, like a video game. This way, the application starts in several milliseconds and at peak performance. And the JIT Compiler is still there, so dynamic performance optimizations are still possible. Some considerations when using crack. The technology preserves almost the exact state of a Java application, so the snapshot may contain sensitive data. Also, CRaC is a novel technology, and it is not subject to TCK testing yet. I encourage you to try all these solutions with your application and see which fits best.
You can find links to the relevant guides in the description box below
