Warmth, i.e. that the JVM has already done the work it performs on each launch of the app (loading common classes, compiling hot methods…). Without this the checkpoint is not valuable.
Automatic Checkpoint
Table of Contents
WARN: This feature is available only in the Subscriber Availability (SA) builds of Zulu since July 2026. This is in early access and may change in future releases without following the usual deprecation path.
When you enable auto-checkpoint, the JVM periodically inspects its own state and automatically triggers a checkpoint once the state becomes warm and idle.
To enable auto-checkpoint, use CRaCCheckpointTo in combination with jdk.crac.autoCheckpoint:
java -XX:CRaCCheckpointTo=cr -Djdk.crac.autoCheckpoint -jar app.jar
Auto-checkpoint plays especially well with Transparent Restore or Startup because the JVM handles both checkpoint and restore automatically.
Auto-Checkpoint Process Details
In auto-checkpoint mode, the JVM periodically inspects its own state and triggers a checkpoint when it is warm and idle. The auto-checkpoint policy in use defines — among other things — what "warm and idle" means, how frequently the inspections occur and what to do when checkpoint/restore succeeds or fails. The JVM logs the process via the jdk.crac.autoCheckpoint Java logger and its sub-loggers.
By default, when the checkpoint succeeds, the JVM restores immediately. You can override this setting with:
-XX:CRaCEngineOptions=keep_running=false
Auto-Checkpoint Policy
WARN: We plan to significantly expand the ability to customize auto-checkpoint behavior. Expect the functionality and format to change in future releases.
The auto-checkpoint policy controls some parts of auto-checkpoint behavior. When you do not specify another policy, the JVM uses the default one from:
$JAVA_HOME/lib/crac/auto-checkpoint-default.properties
You can check this file for the details of the default behavior. The metrics and thresholds in the default policy can vary between JDK releases.
It’s possible that the default policy doesn’t fit your particular application well enough. For example, when you want to trigger the checkpoint sooner. In such case, use the default policy as a reference for writing a custom one, and provide it with:
-Djdk.crac.autoCheckpoint.policy=path/to/custom-policy.properties
Metrics of JVM Readiness
The main reason to create a custom policy is to change the definition of which JVM state counts as ready for checkpoint.
The policy defines the state in terms of metrics. For example:
| Objective expressed in general terms | Objective expressed via metrics |
|---|---|
The speed with which "amount of loaded classes" and "amount of methods enqueued for compilation" metrics change (i.e. their delta per some period) is below a certain low threshold. |
|
Idleness, i.e. that nothing actively interacts with the JVM. Such interactions may interfere with the checkpoint attempt. |
The speed with which "CPU time consumed by the JVM process" metric changes is also below a certain low threshold. |
|
Note
|
Between the moment auto-checkpoint’s facilities read the state and the moment the CRaC engine saves the state to a checkpoint image, the JVM continues working. For example, CRaC resource callbacks run in-between. This means that the state that ends up in the image may somewhat differ from what the policy defines. |
The metrics available are the same as in checkpoint image auto-selection and can vary between JDK releases and JVM options used. Currently, to see the set of the metrics you need to make a checkpoint and inspect the image in an engine-dependent way:
-
For Warp, see Inspecting and Recording Metrics.
-
For CRIU-based and simulated engines, read the
scorefile inside the image directory, it contains lines in the form ofmetric=value.
We plan to introduce more ways to retrieve the available metrics in future releases.