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