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

[Dan Heidinga]

On Sat, 5 Mar 2022 09:17:26 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:
> 
>  - Better error handling in hotspot
>  - Call the main of provided class

src/java.base/share/classes/jdk/crac/Core.java line 172:

> 170:                     newMain.invoke(null,
> 171:                         (Object)Arrays.copyOfRange(args, 1, args.length));
> 172:                 } catch (Throwable e) {

Is `Throwable` the right thing to catch here?  I think Error-subclasses, like OutOfMemoryError or VerifyError, should propagate past here without being added to the suppressed set of the `restoreException`.

src/java.base/share/classes/jdk/crac/Core.java line 216:

> 214:                 try {
> 215:                     checkpointInProgress = true;
> 216:                     checkpointRestore1(Reflection.getCallerClass());

The caller Class is being passed in to get access to a Classloader object to load the new main class.  This means that if the `Core::checkpointRestore` caller is loaded by for example, application specific classloader, it may not have access to the core classpath.

Would it be a cleaner model if we require that the new main class must be a sibling of the original main class and therefore on the classpath/modulepath?  We could avoid using `getCallerClass` and directly pass the `ClassLoader::getSystemClassLoader` in that case.

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

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