Using CRaC

Why the scheme looks like this

CRaC deployment scheme reflects the need to collect data required for Java application initialization and warm-up.

An image has to come from a JVM that has already done the work worth keeping — loaded its classes and compiled its hot paths. That cannot happen at build time, so the application is run and exercised first, and the image it produces becomes part of what ships.

The three stages

1. a Java application (or container) is deployed in the canary environment
   • the app processes canary requests that triggers class loading and JIT compilation
2. the running application is checkpointed by some mean
   • this creates the image of the JVM and application; the image is considered as a part of a new deployment bundle
3. the Java application with the image are deployed in the production environment
   • the restored Java process uses loaded classes from and JIT code from the immediately

Read more

• Runtimes with CRaC CRaC has to be built into the Java runtime. The upstream builds, the vendor builds, and the criu permissions they need.
• Implementing the API Using org.crac to release and reacquire the resources a checkpoint cannot carry.
• Checkpoint and restore Taking a checkpoint of a running JVM and restoring from the image.