CRaC is a novel technique that makes the JVM faster to start.
Azul's JDK build has just added support for it. Here are the details.

The JVM is notorious for its hefty requirements in startup and warmup times. The main reason for the slow startup is that it takes much time to load, link, and initialize classes. Of course we are talking micro-seconds here but the delay can make a difference when trying to spin VMs on the Cloud and run Microservices. There are ideas for speeding things up and CRaC is one of them.

CRaC stands for Coordinated Restore at Checkpoint. It is an API that helps to coordinate the JDK and an application's resources under a checkpoint/restore mechanism.
It allows applications to, for instance, close open files, dump their cache, and snapshot the required state for them to come alive when restored back.

As such the primary aim of the project is to offer a standard mechanism-agnostic API to notify Java programs about the checkpoint and restore events.

The concept of check pointing and restoring images has already been put to test under AWS Lambda SnapStart with the results being very encouraging. As we examined in AWS Lambda Updated With SnapStart, the way SnapStart works is that:

the function’s initialization is done ahead of time when you publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and caches it for low-latency access.

When your application starts up and scales to handle traffic, Lambda resumes new execution environments from the cached snapshot instead of initializing them from scratch, improving startup performance.

The CRaC API gives developers a way to react to the snapshotting process with pre and post hooks, in case they want to create unique data directly in a Lambda function initialization phase. They can use the beforeCheckpoint hook to run code immediately before a snapshot is taken, and use the afterRestore hook to run code immediately after restoring a snapshot. This helps in deleting any unique content before the snapshot is created, and restore any unique content after the snapshot is restored.

As such the Java managed runtime uses CRaC to provide that hook support, therefore the runtime contains a customized CRaC context implementation that calls the Lambda function’s runtime hooks before completing snapshot creation, and after restoring the execution environment from a snapshot.

But, if one of the aims is to foster a faster runtime, why not go for AOT and GraalVM which allows Ahead-Of-Time (AOT) compilation of applications to native images?

We already seen this in practice in "Compile Spring Applications To Native Images With Spring Native" which lets you compile Spring applications to native images using the GraalVM native-image compiler:

What's the advantage in that? Instant startup, instant peak performance, and reduced memory consumption, since the native Spring applications are deployed as a standalone executable, well docker image, without including a JVM installation.

What's the disadvantage? pure-AOT static compilers sacrifice key optimizations. The GraalVM build process, which tries to make the most optimal image possible, throws a lot of stuff out. This could be dependencies, resources or parts of your code. The resulting code is less optimized, runs slower, and requires more cost to carry the same load.

In contrast, CRaC retains the full power of JIT compilation and leverages the checkpoint mechanism.

Projects with CRaC support already are Micronaut and Quarkus while there also is a modification of Tomcat with CRaC support that enables CRaC for Spring Boot applications.

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

It is also important to note that Project CRaC is one of the three vehicles for Java quick start along with the JVM Runtime optimizations and static compilation (OpenJDK Leyden). Well now, there's a new player in town as examined in Google Joins Adoptium - What's The Deal?. Google, in partnership with Alibaba, has inaugurated the Eclipse Adoptium FastStartup Incubator project which aims to make Java faster by exploring the concept of class pre-initialization.

Which technique will prevail in the end will depend both on the benchmarks and strategy adopted.

At the time of writing, you can try CRaC with Azul's Zulu JDK 17 build on Linux x64 platforms. Available for download now.

More Information

Azul CraC

Related Articles

GraalVM Under The Covers
AWS Lambda Adopts Java 17

AWS Lambda Updated With SnapStart

Google Joins Adoptium - What's The Deal?

A New Era For Spring

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info