[crac] RFR: Introduce per-Priority Context with different policies

Anton Kozlov akozlov at openjdk.org
Thu May 18 15:59:15 UTC 2023


On Thu, 18 May 2023 11:48:12 GMT, Radim Vansa <duke at openjdk.org> wrote:

>> A follow-up work for #60:
>> 
>> * Each priority now has a dedicated context, so contextes may provide different policies. CALL_SITE now uses new CriticalUnorderedContext that runs beforeCheckpoint on concurrent registration, fixes [1]. Whether or not CALL_SITE needs to be registered to at all is an open question and out of scope of this PR.
>> * the Global Context reverted from BlockingOrderedContext to OrderedContext, as that may have a huge impact on users. Probably we'll want to expose blocking/criticalUnorderd context along the global one, or at some point expose an implementation. But this is also out of scope of the PR.
>> * hierachy of the Context implementations are cleaned up a bit [2]
>> 
>> The JDKContext is now just a holder of ClaimedFDs, I'll address this in a follow-up that depends on this Context follow-up.
>> 
>> [1] https://github.com/openjdk/crac/pull/60#issuecomment-1545588281
>> [2] https://github.com/openjdk/crac/pull/60#discussion_r1185510445
>
> src/java.base/share/classes/jdk/crac/impl/CriticalUnorderedContext.java line 54:
> 
>> 52:         synchronized (this) {
>> 53:             ExceptionHolder<CheckpointException> e = concurrentCheckpointException;
>> 54:             concurrentCheckpointException = new ExceptionHolder<>(CheckpointException::new);
> 
> Rather than replacing the instance, could we make `throwIfAny` reset its state before throwing? That way we won't get the same exception thrown twice by accident.

Exception holder is inteded to be a short-living object. Doing that is possible, but will also create a temptation to reuse-the object, that will complicate its lifecycle without a need.

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

PR Review Comment: https://git.openjdk.org/crac/pull/74#discussion_r1197996500


More information about the crac-dev mailing list