RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]

[Kim Barrett]

On Wed, 18 Dec 2024 04:37:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The direct use of CML is functionally correct but requires leaking knowledge to all the use-sites that should not need to know about the actual condition for locking. This really needs to be encapsulated which means we need to be able to subclass CML.

I agree that directly using ConditionalMutexLocker isn't pleasant here, and
one actually does want a dedicated locker for this use-case.  However, that
doesn't mean we need to subclass CML.

> @kbarrett what is needed to make `ConditionalMutexLocker` subclassable?

You don't change ConditionalMutexLocker at all.  Just change how it's used:

class NmtVirtualMemoryLocker : StackObj {
  ConditionalMutexLocker _locker;

public:
  NmtVirtualMemoryLocker()
    : _locker(NmtVirtualMemory_lock, _done_bootstrap, Mutex::_no_safepoint_check_flag)
  {}
};

MutexLocker can be has-a used similarly for convenience lockers that don't
need the conditionalization.

Note that making MutexLockerImpl noncopyable (as it should be, but that ought
to be addressed separately) would render this noncopyable too (as it should
be).

Note that I was previously wrong when I suggested it might be messy to has-a
use CML; I misremembered and thought these locker things had more operations
than they actually do.

And not that it really matters, but deriving from StackObj with a CML member
doesn't affect the size of this class, because of EBO.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2552160345