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