Reference on CRaC

Best practices

Mon, 01 Jan 0001 00:00:00 +0000

Best practices for implementing CRaC support in your application/library

This guide assumes you are already familiar with the concepts and Resource API; please check out the step-by-step guide for those.

Implementing Resource as inner class

In order to encapsulate the functionality, the Resource interface is sometimes not implemented directly by the component but we rather create an (anonymous) inner class. However it is not sufficient to pass this resource to the Context.register() method; Global Context tracks resources using weak references. As there is no unregister method on the Context, had a strong reference been used this would prevent the component from being garbage-collected when the application releases it. Therefore the class implementing Resource should be stored inside the component (in a field) to prevent garbage-collection:

Checkpoint engines

Mon, 01 Jan 0001 00:00:00 +0000

CRaC’s API is deliberately mechanism-agnostic: it tells your application that a checkpoint is happening without saying how. The mechanism that actually takes the image is a separate choice, made with -XX:CRaCEngine=.

Debugging failures

Mon, 01 Jan 0001 00:00:00 +0000

Debugging checkpoint and restore failures

This guide will help you identify common problems when the checkpoint operation does not work.

Failures in native C/R

When the checkpoint operation fails in the native part, there is usually little information in the stack trace of the exception:

CPU features

Mon, 01 Jan 0001 00:00:00 +0000

CPU features differ from host to host as newer CPUs offer support for newer instructions, and some optional features may be removed over time. JVM (Java Virtual Machine) depends on CPU features (such as AVX512, SSE3 etc.) of each computer it is running on. The more CPU features JVM can use the better performance it can provide. JVM normally uses all the CPU features it can find on the CPU where it has started.

File descriptor policies

Mon, 01 Jan 0001 00:00:00 +0000

CRaC requires that the application closes all open files, network connections etc. - on Linux these are represented as file descriptors. However, it might be difficult to alter the application to properly coordinate with the checkpoint, e.g. due to a code in a library you cannot modify. In those cases CRaC offers a limited handling via configuration. Note that this applies only to file descriptors opened through JDK API; anything opened through native code cannot be handled this way.