[crac] RFR: Selectable Global Context implementation

Radim Vansa rvansa at openjdk.org
Thu Jun 29 06:58:27 UTC 2023

On Wed, 28 Jun 2023 12:33:32 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/crac/Core.java line 77:
>>> 75:     private static final Context<Resource> globalContext = GlobalContext.createGlobalContextImpl();
>>> 76: 
>>> 77:     private static class ReferenceHandlerResource implements JDKResource {
>> I wouldn't pollute the `Core` class with domain-specific code; if the 'reliability' of registration is of concern I think it's fine to expose the static `ensureRegistered`/`register` method.
>> Or, at least refactor this into its own file.
> I considered register() interface. The waitForReferenceProcessing is an internal JDK interface. The reference processing itself does not require the special managment on checkpoint, but it's checkpoint requirement as a procedure that no reference processing is in progress at some certain point.
> The class is a boilerplate code to call two methods, it is not shared and unlikely will, so a separate file is not justified.

If it's a requirement (and not an optimization), how come it's not prevented from running? (the blocking was there for a time before you reverted that, wasn't it?)

>> src/java.base/share/classes/jdk/crac/impl/GlobalContext.java line 8:
>>> 6: 
>>> 7: public class GlobalContext {
>>> 8:     private static final String GLOBAL_CONTEXT_IMPL_PROP = "jdk.crac.globalContext.impl";
>> As mentioned in off-GH conversation, I don't think this option would be ever used, and if you are going to change the default I'd rather drop it to keep the code simple.
> Since there is no way to employ BlockingContext other than as the global context implementation, I prefer to make it selectable.

OK, so in the future you intend to just change the default and provide non-blocking implementation as the workaround for cases where the registration is not synchronized properly? In that case it makes sense...


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

More information about the crac-dev mailing list