Restoring With New Arguments

Table of Contents

Example: CRaC-ing the Java Compiler

Need help?

Schedule a consultation with an Azul performance expert.

In most cases, you do not need to provide arguments to the JVM when restoring because the restored execution will already be based on the arguments specified before checkpoint. For example:

 # Start a JVM to be checkpointed:
java -XX:CRaCCheckpointTo=crac-image MyMainClass arg1 arg2

# Restore from a checkpoint; the old arguments are "baked in"
# so we don't need to specify them again:
java -XX:CRaCRestoreFrom=crac-image

However, CRaC allows you to provide a new main class and a new set of arguments for it, in case you wish to alter the execution after restore:

 # Restore from a checkpoint with new arguments
java -XX:CRaCRestoreFrom=crac-image MyNewMainClass newArg1 newArg2

When you restore the application with the new main class and new arguments, after all CRaC resources have been successfully processed, the thread which initiated the checkpoint finds the static void main(String[]) method in MyNewMainClass and invokes it with the provided set of arguments (which can be empty) on top of its existing call stack. After this new main method completes, the thread will proceed with executing the code placed after the checkpoint call.

Note

Since you can’t extend the class path on restore, the new main class is required to be available on the class path defined before the checkpoint is created. It is also not possible to use the -jar app.jar syntax on restore to launch the main class from a JAR file. These limitations may be lifted in the future.

Note

When you create a checkpoint via jcmd, the single thread that executes all diagnostic commands will be the one executing the new main. As a result, new commands will be blocked from being executed until the new main completes. Thus, when using new arguments, it is recommended to either initiate the checkpoint on an application thread or start a new thread from the new main.

Example: CRaC-ing the Java Compiler

The Zulu CRaC distributions contain a demo of a CRaC-ed javac based on the restore arguments feature in <java-dir>/demo/crac/JavaCompilerCRaC. There, you can find an executable JAR and the source code to understand how this works.

This is how the CRaC-ed javac can be used:

Implement some Java test classes to be compiled, suppose they are MyClass1.java and MyClass2.java.
Warm-up the CRaC-ed javac by compiling MyClass1.java and checkpoint it:
```
 java -XX:CRaCCheckpointTo=javac-image \
  -jar <java-dir>/demo/crac/JavaCompilerCRaC/JavaCompilerCRaC.jar \
  MyClass1.java
```
At this point, the default main class of JavaCompilerCRaC.jar is invoked with MyClass1.java as an argument. The default main class invokes the standard javac to compile MyClass1.java and then initiates a checkpoint.
Restore and use the warmed-up CRaC-ed javac to compile MyClass2.java:
```
 java -XX:CRaCRestoreFrom=javac-image \
  Compile MyClass2.java
```
- At this point, we specify a class named Compile and contained in JavaCompilerCRaC.jar as the new main class and MyClass2.java as an argument for its main method.
- Compile invokes the standard javac, which was warmed up before checkpoint, to compile MyClass2.java and completes.
- The execution then returns to the default main class of JavaCompilerCRaC.jar which also completes and thus the restored JVM exits.