RFR: 8272447: Remove 'native' ranked Mutex

Coleen Phillimore coleenp at openjdk.java.net
Thu Aug 19 14:27:27 UTC 2021

On Mon, 16 Aug 2021 01:31:28 GMT, David Holmes <dholmes 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.
> 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. ??

@tstuefe  can probably answer why he picked native.  I assume it was due to availability and that it was a test. I don't think we want tests to be out of the mutex ranking system and deadlock either.  'leaf' didn't deadlock as the other metaspace locks are no-safepoint locks and below 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?

Yes, thanks, it should be.


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

More information about the hotspot-runtime-dev mailing list