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

[Radim Vansa]

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've ran into this couple of times as well, when invoking lambda or using method reference after CLEANERS priority. The solution is either to remove those dynamically linked call sites, or initialize those call sites eagerly before.

It asks for a general solution, though, adding a priority level for cleaners used only for call sites (a special method would be required in the cleaners). I'll try to sketch that out.

One other idea I had, as I prefer exceptions over deadlocks, is to detect this. Since you don't want to add any methods to the API that would be generally usable by *any* context, it might be still useful to let the C/R code in Core set a static var/thread-local flag in `AbstractContextImpl` and this method would throw rather than block when it detects that it is the same thread. That breaks encapsulation a bit, though - we could have a resource that sets that flag, but it should run before the 'normal' resources, which leads me to the inversion of JDKContext and Global Context and `EARLY` priority I've suggested before.

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

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