An overview of Project CRaC and JVM performance improvements.
In a world where microservices are becoming more of a standard architecture
for Java-based applications running in the cloud, the JVM warmup time can become a limitation.
A new OpenJDK project called CRaC (Coordinated Restore at Checkpoint) aims to address the JVM warmup problem with a different approach. Basic idea is: take a snapshot of a running JVM, store it in files and restore the JVM at a later point in time or even on another machine.
2. What the CRaC?!
2
Coordinated Restore at Checkpoint (CRaC)
on the Java Virtual Machine
https://openjdk.org/projects/crac
3. OpenJDK vs Project CRaC
“OpenJDK is a place, not a thing” (73 projects)
Source code for the Java Development Kit:
• Virtual Machine (HotSpot)
• Java Class Library
• Java Compiler (javac)
Project CRaC
• Proposed and led by Azul
• OpenJDK Zulu builds (binary distributions) by Azul include CRaC features
• OpenJDK vs builds is like Linux vs its distributions
3
8. CRaC API
• Coordination - ability to react on before and after events (resource management)
• The API enables coordination of resources during checkout and restore
• Checkpoint and restore notifications, awareness of checkpoint/restore events (callbacks)
• Java frameworks and libraries are adopting CRaC, eg. Apache
• CRaC implementation creates the checkpoint safely
• Ensures reliable restart from a given checkpoint
• org.crac dependency
8
9. Resource & Context
public class MyResource implements Resource {
public MyResource() {
org.crac.Core.getGlobalContext().register(this);
}
@Override
public void beforeCheckpoint(Context<? extends Resource> context) throws Exception {
// free your resources
}
@Override
public void afterRestore(Context<? extends Restore> context) throws Exception {
// load your resources
}
}
9
10. Benefits
● Provides immediate application start with peak performance
○ Faster deployment process as well
● Eliminates JIT compilation overhead or JVM warm-up
○ Hotspot identification, method compiles, recompiles and deoptimisations
● Reduces costs in cloud/K8s environments (pay-as-you-use)
○ When scaling resources to meet demand
○ Less time and computing resources used
○ Ideal for apps that perform a lot of work during startup & warmup
● Major frameworks are supported: Micronaut, Quarkus and Spring (Boot)
10
11. Limitations
1. No auto-dump for open files and sockets
(we need to take care of that)
2. Must be restored on the same architecture
(Linux x64,Arm64 | JDK 17 & 21 Azul Zulu builds of OpenJDK)
3. Changes in the value of the system clock (time difference)
(for syncing or caching)
11
13. GraalVM Native Images - Ahead-of-Time
• Ahead of Time is static compilation
• Native instructions give full speed from the start
• No need to start the app ahead of time
• No CPU overhead to compile code at runtime
• 3x smaller memory consumption
• Smaller image than the snapshot
13
• All classes must be available at build time
• No JIT (runtime) compilation optimisations
• Lower performance than JIT optimised JVM
• Debugging is harder
19. 19
Thank you.
“Java: the elegant simplicity of C++ and the
blazing speed of Smalltalk.“
James Gosling
https:/
/openjdk.java.net/projects/crac/
https:/
/github.com/crac