RFR: JDK-8188058: SATB queue set should initialize and manage their own locks

[Kim Barrett]

> On Aug 8, 2018, at 9:51 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> 
> Currently there are 3 locks related to SATB queues, and they are
> declared and defined globally in mutexLocker.hpp|cpp. They are only
> initialized inside an if (UseG1GC) block. This is slightly problematic
> when another GC (e.g. Shenandoah) also needs to use SATB and their
> respective locks.
> In any case, it seems much cleaner to make those locks private in
> SATBQueueSet (or PtrQueueSet) and initialize them there and not expose
> it to the world to begin with.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8188058
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8188058/webrev.00/
> 
> It could probably be taken further and also do something similar to
> DirtyCardQueue, but it is *much* more hairy and probably better handled
> as separate refactoring task.
> 
> What do you think?
> Can I get reviews?
> 
> Thanks, Roman

I don't think this change should be made.

Mutexes and monitors are (mostly) declared and defined in one central
place (mutexLocker.[ch]pp) intentionally.  This provides a global view
of them and their relative lock ranks in one place.  And these locks
in particular have super-special ranking.  Squirrelling them away in
some GC-specific files would not be helpful for that.

They are presently only referred to by G1-specific code.  Solutions to
the conditional definition include adding Shenandoah to the
conditionalization, adding similar Shenandoah-specific mutexes for use
by Shenandoah (not my favorite, but mentioned for completeness), or
remove the conditionalization.

(I described this change to Coleen, and she had the same response.)