RFR: 8272447: Remove 'native' ranked Mutex [v3]

David Holmes dholmes at openjdk.java.net
Mon Aug 23 05:01:32 UTC 2021

On Thu, 19 Aug 2021 14:17:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I stand corrected - thanks @kimbarrett  - but my question remains valid. If this was considered outside the ranking system then it was presumably because a suitable rank could not be determined, so what rules are now being used to determine this new rank?
> It was outside the ranking system because no appropriate ranking was found for it at the time and 'native' was available.  There's no evidence that this lock should be outside the ranking system.  The ranking system is to help provide deadlock detection and this lock isn't that special.  It is a low ranked lock however because it's taken with the tty lock held, so that's how it got tty-2.  If it takes a higher ranked lock (not found by testing), then it'll deadlock and we want to know that.

The SharedDecoder lock is used during crash reporting and so could potentially be taken whilst any other lock is held. While we special case the use of the Decoder in the initial error reporting thread, by not taking the lock due to the deadlock potential, it will still be taken by threads that encounter a secondary error. That is what makes this lock "special".


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

More information about the hotspot-runtime-dev mailing list