[crac] RFR: Provide arguments for restore [v5]
Dan Heidinga
heidinga at openjdk.java.net
Fri Mar 18 14:12:00 UTC 2022
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
src/java.base/share/classes/jdk/crac/Core.java line 177:
> 175: InvocationTargetException |
> 176: NoSuchMethodException |
> 177: IllegalAccessException e) {
Thanks for adapting this to be more specific on what it catches.
I don't think it's quite right yet though as the current code will allow exceptions thrown by the `newMain` method (and its callees) to propagate past the checkpoint spot and makes the caller of the checkpoint code need to handle them.
At the time `Core.checkpointRestore();` is called, we may have stack that looks llike:
TOS
Core.checkpointRestore();
Foo.bar();
Foo.foobar();
SomeOtherClass.method();
OriginalClass.main();
And when we restore, we load an execute a new `main()` method as though it was called where `Core.checkpointRestore();` was previously on the stack resulting in:
TOS
newMain.main();
Core.checkpointRestore();
Foo.bar();
Foo.foobar();
SomeOtherClass.method();
OriginalClass.main();
So exceptions thrown by code called from `newMain` should not propagate past `Core.checkpointRestore();` without being wrapped in a `RestoreException`. `Error`-subclasses should propagate.
I think the code should be refactored to something like:
} catch(Exception t) {
assert checkpointException == null :
"should not have new arguments";
if (restoreException == null) {
restoreException = new RestoreException();
}
restoreException.addSuppressed(e);
}
as that correctly catches all Exceptions but lets the Errors propagate past
-------------
PR: https://git.openjdk.java.net/crac/pull/16
More information about the crac-dev
mailing list