RFR: 8272447: Remove 'native' ranked Mutex

[Kim Barrett]

On Mon, 16 Aug 2021 01:24:18 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.
>
> src/hotspot/share/runtime/mutexLocker.cpp line 338:
> 
>> 336:   def(ThreadsSMRDelete_lock        , PaddedMonitor, special,     true,  _safepoint_check_never);
>> 337:   def(ThreadIdTableCreate_lock     , PaddedMutex  , leaf,        false, _safepoint_check_always);
>> 338:   def(SharedDecoder_lock           , PaddedMutex  , tty-1,       true,  _safepoint_check_never);
> 
> Sorry I don't understand how this you moved this ranking from being ultra-high to being one of the lowest. What are you actually saying about this lock? What rules are you applying to determine what the rank should be?

[not a review, just replying to @dholmes-ora] Mutex::native isn't an "ultra-high" rank, it is outside the ranking system.  Rank checks are not applied for Mutex::native.  See the occurrences of Mutex::native in mutex.cpp.

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

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