RFR: 8272447: Remove 'native' ranked Mutex

David Holmes dholmes at openjdk.java.net
Mon Aug 16 01:37:29 UTC 2021


On Fri, 13 Aug 2021 21:13:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> See JBS issue for more details.  The locks that were native ranking should have a real mutex ranking and participate in the deadlock detection mechanism.  The MonitoringSupport_lock is taken out after the Notification_lock, which is aliased to the Service_lock if -XX:-UseNotificationThread.  Service_lock is ranked tty-2 which is the same as access rank, so I made a new service rank for these two locks to share.  As a future change we should verify that rank+-number doesn't overlap with a different rank.
> Tested with tier1-6 in mach5.

Hi Coleen,

Sorry but other than the change to the MonitoringSupport_lock that you explained, I don't understand the basis for changing the other "native" mutexes. ??

David

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

> 336:   def(ThreadsSMRDelete_lock        , PaddedMonitor, special,     true,  _safepoint_check_never);
> 337:   def(ThreadIdTableCreate_lock     , PaddedMutex  , leaf,        false, _safepoint_check_always);
> 338:   def(SharedDecoder_lock           , PaddedMutex  , tty-1,       true,  _safepoint_check_never);

Sorry I don't understand how this you moved this ranking from being ultra-high to being one of the lowest. What are you actually saying about this lock? What rules are you applying to determine what the rank should be?

test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp line 52:

> 50: 
> 51:   void do_test(Metaspace::MetadataType mdType) {
> 52:     _lock = new Mutex(Monitor::leaf, "gtest-IsMetaspaceObjTest-lock", false, Monitor::_safepoint_check_never);

Again I'm not at all clear on the basis for changing from the low ranked native to a much higher ranked leaf. ??

test/hotspot/gtest/runtime/test_mutex.cpp line 132:

> 130: 
> 131: TEST_VM_ASSERT_MSG(MutexRank, mutex_lock_access_leaf,
> 132:                    ".* Attempting to acquire lock mutex_rank_leaf/.. out of order with lock mutex_rank_access/1 "

I assume the .. should be .* to be a wildcard match?

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

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


More information about the hotspot-runtime-dev mailing list