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