Comparing CRaC and ReadyNow for Faster Java Application Startup

This is the first article in a series describing how to use ReadyNow to accelerate Java application startup.

To help Java applications complete startup optimization faster, Azul offers several solutions, including Coordinated Restore at Checkpoint (CRaC) and ReadyNow, which address the same challenge with different methods.

Java faces a major challenge: application startup optimization .

Java powers many applications, from small workflows on a single device to large clusters handling massive data and transactions, and Azul focuses on improving startup performance in complex, time‑sensitive environments.

Azul proposes several solutions for Java startup optimization:

Coordinated Restore at Checkpoint (CRaC) : create a checkpoint and restore from it .

ReadyNow : store compilation decisions for reuse in subsequent runs.

Cloud Native Compiler : offload compilation tasks to a centralized service.

Although CRaC and ReadyNow share the same goal, their implementation paths are completely different; this article focuses on their differences.

Java Startup Process Analysis

When a Java application starts, it performs the following tasks:

JVM ( java ) itself starts.

JVM loads application classes from a jar package, initializes resources, and starts application logic.

Code executes and is optimized for the running device.

Tasks 1 and 2 constitute the “first‑response time,” after which the application can handle API calls and other critical functions.

During task 3, as code is compiled to native code ( compilation to native code ), performance gradually improves—this is the “startup optimization” phase.

Java Startup Optimization Stages

Java applications go through three stages to achieve full startup optimization:

JVM directly executes bytecode from the JAR.

JVM counts method invocation frequencies; once a threshold is reached, the Tier 1 compiler translates bytecode to native code.

The JVM continuously monitors code usage patterns; for example, if a switch statement’s case branches are never executed, a later threshold triggers the Tier 2 compiler to re‑compile based on observed patterns, producing the optimal native code for the device.

After these stages, the application reaches “full‑speed” operation.

De‑optimization Phenomenon

The Tier 2 compiler may make incorrect decisions, causing compiled code to be de‑optimized and fall back to bytecode until it is re‑compiled, which can cause slight performance drops.

In most cases this impact is negligible, but in latency‑critical industries (e.g., financial trading) it must be avoided .

Azul’s Solutions

Coordinated Restore at Checkpoint (CRaC)

CRaC is an OpenJDK project implemented in Azul Zulu builds. After startup optimization, the application can create a checkpoint that contains a “snapshot” of its state. The checkpoint can be used to restart the application instantly, bypassing the optimization phase.

Before checkpointing, the application must close all open connections (files, databases, sockets, etc.) and then terminate; frameworks like Quarkus, SpringBoot, Micronaut, and AWS Lambdas have CRaC integrations.

The checkpoint can be restored on the same device or another device with the same architecture; connections are re‑established, but performance resumes at the previous level.

Using CRaC requires code changes to handle connection shutdown and re‑establishment.

CRaC skips the startup optimization phase by storing a complete runtime snapshot, allowing rapid restoration to the previous state.

ReadyNow

ReadyNow is a feature of Azul Zing (a modern, TCK‑compliant OpenJDK‑based platform). It enables the compiler to generate optimal native code from the very start of application launch . ReadyNow is available to Azul Platform Prime customers.

Zing logs each compilation step to a configuration file, which engineers can analyze with tools like GC log analyzers. By supplying these logs as input on subsequent runs, ReadyNow uses prior execution information to guide the JVM in compiling the most efficient code, gradually producing a “trained” configuration that eliminates de‑optimizations.

Because ReadyNow is integrated into Zing, no code changes are required ; only a few command‑line options are needed to activate it.

ReadyNow records compilation decisions throughout the application’s lifecycle, allowing the JVM to generate optimal code from the first execution and completely avoid de‑optimizations.

For large‑scale deployments, Azul offers the Optimizer Hub service to store ReadyNow configuration files and offload compilation tasks.

ReadyNow stores previous compilation decisions in a text file, skipping the startup optimization phase and preventing any de‑optimization‑induced latency.

Cloud Native Compiler

The Cloud Native Compiler, part of Azul Platform Prime’s Optimizer Hub, provides a server‑side solution that offloads JIT compilation tasks to dedicated resources, increasing compute power for JIT while removing the client JVM’s local JIT burden.

Thus, the Cloud Native Compiler complements the challenges discussed and works alongside ReadyNow.

CRaC vs ReadyNow Comparison

Summary of differences:

CRaC

ReadyNow

Applicable Build

Zulu

Zing

Code Modification Required

Yes, or must use a CRaC‑supported framework (e.g., Spring, Micronaut, Quarkus…) (*)(**)

No

Required Space

Application heap size + extra storage

Limited‑size text file

Debug Difficulty

Higher

Rich debugging via GC logs and config files

Can Handle Java Modes (***)

Yes

Yes

Availability

Free builds provide basic features; Azul customers unlock extensions

Only available to Azul customers

(*): Even with frameworks, some code changes may still be needed.

(**): Some framework CRaC implementations snapshot at the first transaction (calling main ), improving startup time but not achieving ideal “full‑speed” time.

(***): Unlike native‑compiled apps (e.g., GraalVM), CRaC and ReadyNow retain original bytecode, allowing further optimization and dynamic class loading.

Conclusion

Both CRaC and ReadyNow aim to shorten Java startup optimization time, but they use fundamentally different approaches. In scenarios where code cannot be modified, rapid server deployment is needed, and performance or total cost reduction is desired, ReadyNow is the ideal choice for boosting Java performance.

Readers are encouraged to consult the documentation, visit the official website for more details on CRaC and ReadyNow, and follow the Azul blog for future in‑depth articles.