[crac] RFR: Selectable Global Context implementation

Anton Kozlov akozlov at openjdk.org
Fri Jun 30 12:18:30 UTC 2023

On Fri, 30 Jun 2023 06:38:36 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This piece of code is reletated to this part of the description
>>> To make properties available, it was required to delay Reference resource registration. Otherwise, the GlobalContext implementation decision had to be done too early, in the Reference initialization during JDK bootstrapping, before Properties are available.
>> Without this code, the ReferenceResource was registered during Reference initialization. At that point, Properties were not initalized yet, so any attempt to call System.getProperty() threw NPE (regardless parameters).
>> I.e. if we have the default context implementation configuration via properties, we need to delay ReferenceResource registration.
> I understand moving the registration from Reference clinit, and if you'd rather keep the implementation here, let's keep it that way. I was referring to
>> it's checkpoint requirement as a procedure that no reference processing is in progress at some certain point
> - I am not sure what creates this requirement, and it is not 100% guaranteed the way it's implemented now.

The requirement is stated in the quoted part :) "no reference processing is in progress at some certain point" =(at REFERENCE_HANDLER priority).

It's required by the following CLEANERS (hard requirement, otherwise cleaner may miss something). And in general, reference processing should be quiescent -- to avoid checkpointing reference processing in the middle without a reason (soft requirement). I don't like how it's done at the moment. I've tried to make CLEANERS to ensure reference processing by its own, to be more straightforward. But in the absence of any CLEANER (e.g. the whole Cleaner package is not referenced and is not initialized), we won't satisfy the soft requirement, which still makes sense.


PR Review Comment: https://git.openjdk.org/crac/pull/87#discussion_r1247797235

More information about the crac-dev mailing list