RFR: 8273300: Check Mutex ranking during a safepoint [v2]

[Coleen Phillimore]

On Sun, 12 Sep 2021 22:33:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If I see a lock with a rank service-1, then should I infer that lock can be acquired while the service (or notification) lock is held? And that if lock A is service-1 and lock B is service-2, then B can be acquired while holding A?

Yes.  The Service_lock is held while all these other locks are taken.  The subtraction comes from the highest ranked lock with a name, in this case 'service'.

> src/hotspot/share/memory/universe.cpp line 125:
> 
>> 123: LatestMethodCache* Universe::_do_stack_walk_cache     = NULL;
>> 124: 
>> 125: bool Universe::_verify_in_progress                    = false;
> 
> This cleanup seems completely unrelated to your mutex change and is best left to a separate cleanup RFE.

I could do it in a trivial other RFE.

> src/hotspot/share/memory/universe.cpp line 1116:
> 
>> 1114:   }
>> 1115:   if (should_verify_subset(Verify_CodeCache)) {
>> 1116:     MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag);
> 
> Is this needed to allow the new rankings to work? And is this enabled by the _verify_in_progress change? If so I'd rather see all of that related stuff changed first in a separate RFE that can easily be independently backported.

Yes, this is needed.  This verification is done during a safepoint, so we don't need this lock.  The CodeCache_lock has a vary low ranking and takes out VtableStubs_lock which is a higher ranking.  With this change, we do not take out the CodeCache_lock, so it's needed for this change.  I see no reason whatsoever to backport it though.

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

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