Reduce Java Application Startup and Warmup Times with CRaC and Join the CRaC Forum

When a Java application runs, the JVM goes through the process of loading, initializing, and optimizing the code used by the application, including libraries, frameworks, and other components to reach the optimal performance level.

Each time the application restarts, it has no record or memory of previous times it has run and the work it performed.

As a result, it has to restart, extending valuable startup and warmup times and using precious resources.

Azul Zulu Builds of OpenJDK for Java 17 with CRaC

Speeding up startup and warmup has been one of Java’s perennial challenges. OpenJDK’s CRaC (Coordinated Restore at Checkpoint) project is one of the most promising solutions.

Frameworks like Micronaut, Quarkus and Spring have realized orders of magnitude improvement with CRaC.

Now developers can try CRaC for themselves. Today Azul announces the general availability of Azul Zulu Builds of OpenJDK for Java 17 with CRaC support in x86, 64-bit configurations.

The builds are commercially supported as part of Azul Platform Core and are also available for free download and use with no restrictions.

For discussions and questions on this topic, see the CRaC Discussion Forum.

From Micronaut to Spring Boot

"CRaC has generated immense interest among the Java developer community and provides a compelling, resource-efficient approach for improving startup and warmup times. Azul is well known for originating this project, so it came as no surprise that they would also deliver the world’s first production-ready builds of OpenJDK with commercial CRaC support. "

— Sergio del Amo, Micronaut Product Development Lead.

"Project CRaC’s checkpoint restore approach is very promising for the immediate startup of Spring applications on the JVM. Our collaboration with Azul delivered some great initial results already."

— Juergen Hoeller, project lead and co-founder of the Spring Framework project.

What Does CRaC Do?

The OpenJDK CRaC Project defines public Java APIs that allow for coordinating application resources during checkpoint and restore operations. This is important because applications can be restored in different environments than where the checkpoint was created; they may have different time zones, database connection strings, etc.

For discussions and questions on this topic, see the CRaC Discussion Forum.

CRaC allows a running application to pause, snapshot its state, and store it for later use – even on a different machine. It saves the full context of the application process as an image, including its state and memory.

When the application restarts later, it skips startup and warmup and jumps right to that stored profile. It rapidly reloads the entire application and its state so it can continue from the point where the checkpoint was created. This approach reduces Java application startup and warmup times by several orders of magnitude, meaning milliseconds instead of seconds or minutes.

CRaC allows Java applications to leverage checkpoint-and-restore mechanisms and coordinate with them as necessary. Checkpoint-and-restore operations save the state of the JVM and the Java application to an image. The Java application can then be resumed from the image at a future point in time. Think of when you finish using a laptop, and you close it. Later, when you open it, CRaC would be like having the laptop operating at the same to performance as when you closed the lid. 

In tests performed in 2022, OpenJDK builds with CRaC support showed some very impressive results:

Learn how to get CRaC in your build of OpenJDK  

To use CRaC with the Azul Zulu Build of OpenJDK for Java 17, visit our Downloads page and select your build. You can also learn more about Azul Platform Core from our website.

For discussions and questions on this topic, see the CRaC Discussion Forum.

For discussions and questions on this topic, see the CRaC Discussion Forum.