[crac] RFR: Fix ordering of invocation on Resources [v5]

[Anton Kozlov]

On Thu, 4 May 2023 13:20:45 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> * keeps the original handling of exceptions: afterRestore is called even if beforeCheckpoint throws
>> * allows to register a resource in a context that did not start beforeCheckpoint invocations yet
>> * registering resource in previous/running context fails the checkpoint but does not trigger exception immediately
>>    * instead this will be one of the recorded exceptions and the resource has a chance to fire next time
>> * allowed registration of resources can be invoked from other thread without deadlock; illegal registration can deadlock, though
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix javadoc build

This change gets too complex with refactoring, API changes, documentation, and fixes. Let's simplify this. Regarding fix, I'd like the minimal change without refactorings, API changes, doc changes. I believe ACI changes are not necessary for that. 
The test is nice.

src/java.base/share/classes/javax/crac/Core.java line 53:

> 51:      *     reference to the resource - otherwise the garbage collector
> 52:      *     is free to trash the resource and notifications on this resource
> 53:      *     will not be invoked.

Instead, highlight the rationale behind weak registration: it does not change live-cycle the object, so any object may register with the Context without additional implications rather than notification. But if the object is not strongly-reachable, it can be collected before the notification.

src/java.base/share/classes/javax/crac/package-info.java line 87:

> 85:  *   <li>When an exception is thrown during notificaion, it is caught by the {@code Context} and is suppressed by a {@code CheckpointException} or {@code RestoreException}, depends on the throwing method.
> 86:  *   </li>
> 87:  *   <li>When the {@code Resource} is a {@code Context} and it throws {@code CheckpointException} or {@code RestoreException}, exceptions suppressed by the original exception are suppressed by another {@code CheckpointException} or {@code RestoreException}, depends on the throwing method.

This sepcification for child context was lost

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

PR Review: https://git.openjdk.org/crac/pull/60#pullrequestreview-1413175828
PR Review Comment: https://git.openjdk.org/crac/pull/60#discussion_r1185072093
PR Review Comment: https://git.openjdk.org/crac/pull/60#discussion_r1185063640