[crac] RFR: Provide arguments for restore [v5]

[Anton Kozlov]

On Thu, 17 Mar 2022 19:20:50 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> This change adds an ability to receive a new set of command-line arguments in the restored Java instance. The supplied demo code shows a faster replacement for `javac`.
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use System class loader
>  - Make catch() preceise

I'm looking at the new arguments as the way to specify an additional service action on restore. In the javac example, the action is the main reason to restore the instance, after which the original program completes. But in general, it's a way to influence the program behavior on restore, after it has been executed for a while before the checkpoint. After the action is completed, the execution returns back to the original program. The purpose is to allow more flexible images that can be purposed better to the current environment, like in general command line arguments allow more flexible program.

> * the current implementation is forcing user to create two classes with the main() method

It's not necessary two (initializing and restoring) main methods, there could be more. With the old approach, users would be forced to dispatch execution themselves. I had some not pretty array juggling code, and it will be repeated over and over in every program that attempts to use this feature. 

The new arguments are optional. And JDK may provide predefined services. Such as a store for arguments for later consuming, to get back to the old approach. 

> * consequently the command line to run the application also differs depending on whether the user is running for the first time to take checkpoint, or restoring from the checkpoint

It may be a good feature. Restore brings us into the middle of execution, not to the start of the original program. I think the opposite looks confusing, if the same class name means different things if used for checkpoint (start the main from the class) or to restore (continue from some point of the main of the specified class).

> * the stack trace of the main thread after restore has remnant frames from the "before checkpoint" state, which at the least would be confusing to the user

Some documentation indeed would be useful. I'm thinking about a comment for checkpointRestore(): "implementation may accept an additional action and arguments to be run after restore, after which they will be used to locate a class which `main` method will be called with provided arguments". There should be less surprise then.

> I guess the concern with that approach is that the first argument is to be ignored as mentioned [here](https://github.com/openjdk/crac/pull/16#issuecomment-1059730025). 

It's better to avoid the first argument then. I just did not want to modify the launcher code too much.

With the new approach, the first argument of restore means something very similar to the first argument of the normal start.

> A user would prefer to use same class name every time to start the application and therefore the JVM can safely ignore the first argument. If the user specifies a different class name during restore, then the JVM should interpret it as a different application and the current checkpoint should not be used for restoring it. In this case, the JVM would bail out with an exception.

For java -jar, would it be required to match -jar or with the name of the main class?

I see this may be appealing, but then two commands in @DanHeidinga 's Option 2 are too similar to each other, and the second one means something very different. 


$ java -XX:CRaCRestoreFrom=./cr Foo arg1 arg2 arg3


On the opposite, treating Foo as the class name allows us to implement a fallback if CRaCRestoreFrom fails. `Foo` then may proceed as usual, or it may detect the VM was not restored and fail gracefully.

-XX:+CRaCIgnoreRestoreIfUnavailable was designed for the fallback, but unfortunately, I broke it in #3.

-------------

PR: https://git.openjdk.java.net/crac/pull/16