RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v3]

[Serguei Spitsyn]

On Thu, 8 Feb 2024 07:05:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge
>>  - review: thread in notify waiter list can't be BLOCKED
>>  - 8324677: Specification clarification needed for JVM TI GetObjectMonitorUsage
>
> Based on Dan's analysis I would have to go back and redo the complete analysis for myself. :( I think the only way to make sense of this is to actually set up scenarios where we have different threads contending on entry, different threads waiting and different threads re-entering after being notified, and see what values actually get returned in each case.
> 
> I think the `pending_current_monitor` issue may be a distinct/different issue. I can easily imagine that this was overlooked when we introduced the "wait morphing" rather than have the notified/timed-out/interrupted waiters actually place themselves on the entry queue.

>From @dholmes-ora :
> If you don't check all the zero/non-zero permutations for the three counts of interest then you don't know that you are combining them the right way to give the two counts reported by the API.

Okay, thanks. I've added the suggested test cases to the `nsk/jvmti/GetObjectMonitorUsage/objmonusage003`.
One of the testcases is covered by the `nsk/jvmti/GetObjectMonitorUsage/objmonusage001`.

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

PR Comment: https://git.openjdk.org/jdk/pull/17680#issuecomment-1944052748