[crac] RFR: Prevent concurrent cleanup by cleaner thread and checkpoint notifications
Anton Kozlov
akozlov at openjdk.org
Wed May 24 13:29:25 UTC 2023
On Tue, 16 May 2023 11:52:54 GMT, Radim Vansa <duke at openjdk.org> wrote:
> We block the cleaner thread to prevent race conditions between this thread and checkpointing thread invoking clean().
> When the cleanup starts in cleaner thread the checkpoint will skip it, but without waiting for the cleanup to finish (which might be critical for the checkpoint, e.g. closing FDs).
> The limitation is that code performing C/R must not wait on any task completed by the cleaner.
src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 151:
> 149: while (blockForCheckpoint) {
> 150: wait();
> 151: }
Once we've got here, is it possible to ensure Cleaners has been called, and drop separate registration of Cleaners?
A concurrent cleaner registration is not a problem, as that depends on GC which is not predictable. I.e. if that happens, a slight race may also cause the cleaner to run after restore.
src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 180:
> 178: // critical for the checkpoint, e.g. closing FDs).
> 179: // The limitation is that code performing C/R must not wait on any task
> 180: // completed by the cleaner.
Could you elaborate why there is this limitation?
src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 182:
> 180: // completed by the cleaner.
> 181: blockForCheckpoint = true;
> 182: thread.interrupt();
Why it has to be interrupt and not notify(), for example?
-------------
PR Review Comment: https://git.openjdk.org/crac/pull/73#discussion_r1204137253
PR Review Comment: https://git.openjdk.org/crac/pull/73#discussion_r1204117380
PR Review Comment: https://git.openjdk.org/crac/pull/73#discussion_r1204118532
More information about the crac-dev
mailing list