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

[Anton Kozlov]

On Wed, 16 Mar 2022 13:09:36 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> 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 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.

Thanks. This makes sense, the proposed behavior is indeed more clear. It will cut out some cases (e.g. running the app from .java file directly, its class loader won't be the System Class Loader). But also will make some cases easier to reason about (e.g. running checkpoint from jcmd -- the caller's class loader is the bootstrap, we may require user to place the class there, but this does not look good). Although with the existing behavior it's possible to implement the proposed one, and vice versa looks impossible, I still would stick to the one that is more clear.

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

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