RFR: 8272788: Nonleaf ranked locks should not be safepoint_check_never

Coleen Phillimore coleenp at openjdk.java.net
Mon Aug 23 12:36:30 UTC 2021


On Fri, 20 Aug 2021 16:41:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> I moved nonleaf ranked locks to be leaf (or leaf+something).  Many of the leaf locks are safepoint_check_never.  Segregating this rank into safepoint checking and non-safepoint checking is left for a future RFE.
> Tested with tier1-3.  Tier 4-6 testing in progress.

src/hotspot/share/prims/jvmtiTagMap.cpp line 75:

> 73: JvmtiTagMap::JvmtiTagMap(JvmtiEnv* env) :
> 74:   _env(env),
> 75:   _lock(Mutex::leaf, "JvmtiTagMap_lock", Mutex::_allow_vm_block_flag,

David, note this lock.  Since it allows the VM to block, then making it non-leaf is meaningless, since allowing the VM to block means that once you take this lock, you may NOT take another lock that blocks for safepoint.

src/hotspot/share/runtime/mutexLocker.cpp line 289:

> 287:   def(JfieldIdCreation_lock        , PaddedMutex  , nonleaf+1,   true,  _safepoint_check_always); // jfieldID, Used in VM_Operation
> 288: 
> 289:   def(CompiledIC_lock              , PaddedMutex  , leaf+2,      false, _safepoint_check_never);      // locks VtableStubs_lock, InlineCacheBuffer_lock

In my testing, the CompiledIC_lock only takes other locks that never safepoint check, so this should be at the top of the hierarchy of locks that do that.  OR it can safepoint_check_always.  That might make sense, but I'd rather not change the safepoint checking properties with this change.

src/hotspot/share/runtime/mutexLocker.cpp line 318:

> 316:   def(JfrMsg_lock                  , PaddedMonitor, leaf,        true,  _safepoint_check_always);
> 317:   def(JfrBuffer_lock               , PaddedMutex  , leaf,        true,  _safepoint_check_never);
> 318:   def(JfrStream_lock               , PaddedMutex  , leaf+1,      false, _safepoint_check_never);

This lock is actually unused.

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

PR: https://git.openjdk.java.net/jdk/pull/5203


More information about the serviceability-dev mailing list