RFR: 8273917: Remove 'leaf' ranking for Mutex [v3]

[David Holmes]

On Tue, 5 Oct 2021 14:35:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes 'leaf' ranking.  The previous change for JDK-8273915 divided the 'leaf' ranked locks that didn't safepoint check into the rank 'nosafepoint', so all the 'leaf' ranking locks left were safepoint_check_always.
>> 
>> The rank 'nonleaf' (to be renamed 'safepoint' in the next change) is the *top* mutex rank.
>> 
>> The transformation in this change is as follows:
>>    nonleaf+n   => nonleaf   - Generally these 'nonleaf' mutex were top level locks)
>>    leaf => nonleaf                - Many of these locks were top level locks
>>    leaf => nonleaf-2             - Assuming that they were 'leaf' and 2 levels less than some existing nonleaf lock
>>    leaf-n => nonleaf-n
>> 
>> The new mutex rankings reflect their rankings based on my logging, except for a couple shenandoah locks which I didn't observe, so I made them nonleaf-2.
>> 
>> This change also introduces a relative mutex ranking macro, so that a Mutex/Monitor can be defined in terms of a mutex that it holds while trying to acquire it.  So these relative mutex are moved to the end of the init function in mutexLocker.cpp.
>> 
>> This has been tested with tier1-8, and retesting tier1-3 locally in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust some nonleaf-2 ranks.

Hi Coleen,

A minor comment below but otherwise this all seems okay.

Thanks,
David

src/hotspot/share/runtime/mutex.cpp line 300:

> 298: 
> 299:   assert(_rank >= 0, "Bad lock rank: %s", name);
> 300:   assert(_rank <= nonleaf, "Bad lock rank: %s", name);

Can we just combine these into a single range check? And really the assert message should include the bad rank value. And probably this basic range check should be first.

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

Marked as reviewed by dholmes (Reviewer).

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