RFR: 8273915: Create 'nosafepoint' rank [v2]

[Coleen Phillimore]

On Mon, 20 Sep 2021 18:15:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove 'safepoint' rank, now unused.
>
> src/hotspot/share/runtime/mutex.hpp line 53:
> 
>> 51:        special        = tty            +   3,
>> 52:        oopstorage     = special        +   3,
>> 53:        nosafepoint    = oopstorage     +   6,
> 
> Maybe add a comment below `nosafepoint` like:
> 
> 
> // A thread is not allowed to safepoint while holding a mutex whose
> // rank is nosafepoint or lower.
> 
> 
> Also, how about renaming the generic name `lock_types` to something specific like `standard_lock_ranks`?
> 
> 
> BTW, should we (in separate RFE) add a new enum `_safepoint_check_default`, so that this parameter can be omitted depending on the rank value (unless in places where you need to override it)?
> 
> For one thing, I never understood which _safepoint_check_xxx I should have used when adding a new lock. I just randomly changed it until the JVM stops crashing.

The comment is good, but I added it to above the enum because otherwise it messes up my nice alignment.

How about changing lock_types to Rank, since the later plan is to make this an enum class that only allows subtraction operations?

I think in a future RFE we should remove this safepoint_check_always or never parameter and just use the ranks, since after the next change there won't be any overrides.

For the most part, new locks that JavaThreads or runtime JRT entries use, should be safepoint_check_always so that the safepoint protocol is respected.  More locks are safepoint_check_never since these locks are shared with GC or compiler threads and many times used during a safepoint.

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

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