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

[Anton Kozlov]

On Wed, 10 May 2023 12:49:03 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:
> 
>   Revert removing the logging configuration

Yes, I did. But in general, these limitations do not look very pleasant for programming. I think we are trying to find a perfect policy for context when there are too many sets of requirements:
- We want some resource to be certainly called, if beforeCheckpoint does a critical clean-up (e.g. wiping security keys), not doing that is a bug. But these don't care about ordering with other resources. In this case, running notification right on registartion looks like an option (as you've proposed in some of the threads), or collecting such late registrations and run all of them, before 
- Some of the resources that do care about ordering does not necessarily care about being certailny called, like those which do optimization clean up like clearing extra cache which does affect correctness.

I'm leaning toward introduction of a few JDKContext variants that will provide different guarantees for being registered resources. Global context still to accomodate them.

GlobalContext:
- PriorityContext
  - ...
- Cleanup // everything that needs clean up, immediate runs of the notification
- ...User Resources...

The scheme actually is not something specific to JDK, user code may have something similar or different, depending on the needs.

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

PR Comment: https://git.openjdk.org/crac/pull/60#issuecomment-1545853147