On Tue, 7 May 2024 18:53:23 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:

>> This PR adds ranked monitor support to the debug agent. The debug agent has 
>> a large number of monitors, and it's really hard to know which order to grab 
>> them in, and for that matter which monitors might already be held at any 
>> given moment. By imposing a rank on each monitor, we can check to make sure 
>> they are always grabbed in the order of their rank. Having this in place 
>> when I was working on 
>> [JDK-8324868](https://bugs.openjdk.org/browse/JDK-8324868) would have made 
>> it much easier to detect a deadlock that was occuring, and the reason for 
>> it. That's what motivated me to do this work
>> 
>> There were 2 or 3 minor rank issues discovered as a result of these changes. 
>> I also learned a lot about some of the more ugly details of the locking 
>> support in the process.
>> 
>> Tested with the following on all supported platforms and with virtual 
>> threads:
>> 
>> com/sun/jdi
>> vmTestbase/nsk/jdi
>> vmTestbase/nsk/jdb
>> vmTestbase/nsk/jdwp 
>> 
>> Still need to run tier2 and tier5.
>> 
>> Details of the changes follow in the first comment.
>
> Chris Plummer has updated the pull request incrementally with two additional 
> commits since the last revision:
> 
>  - Fix jcheck extra whitespace.
>  - Fix comment typo.

What do you think about the terminology usage of "rank". In this PR the term 
"higher ranked" means that it must be entered first (before any monitor with a 
lower rank), but 0 is the highest rank, and bigger numbers mean a lower rank. 
Sometimes when we rank things (in general) we say #1 is the best, but sometimes 
we instead rank with a score, and the highest score is the best. I'm wondering 
if for this PR the rank ordering should be reversed, so a "higher rank" is 
actually a higher number.

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

PR Comment: https://git.openjdk.org/jdk/pull/19044#issuecomment-2099099957

Reply via email to