[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