RFR: 8273917: Remove 'leaf' ranking for Mutex

[Coleen Phillimore]

On Sun, 3 Oct 2021 21:08:51 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.

src/hotspot/share/oops/methodData.cpp line 1210:

> 1208:   : _method(method()),
> 1209:     // Holds Compile_lock
> 1210:     _extra_data_lock(Mutex::nonleaf-2, "MDOExtraData_lock", Mutex::_safepoint_check_always),

MDO lock (nonleaf-2) is taken when the Compile_lock is held (nonleaf-1) which is taken while the MethodCompileQueue_lock (nonleaf) is held.

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

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