On Tue, 13 Feb 2024 07:06:05 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> review: fixed issues in get_object_monitor_usage; extended test coverage >> in objmonusage003 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003.java > line 33: > >> 31: final static int NUMBER_OF_ENTERER_THREADS = 4; >> 32: final static int NUMBER_OF_WAITER_THREADS = 4; >> 33: final static int NUMBER_OF_THREADS = NUMBER_OF_ENTERER_THREADS + >> NUMBER_OF_WAITER_THREADS; > > This testing is not sufficient. We have three states of interest: > - entering the monitor directly > - waiting in the monitor via Object.wait > - re-rentering the monitor after being notified (or timed-out or interrupted) > - we need to check all of these conditions in permutations covering zero and > non-zero for each one, and then see that we get the correct counts back from > JVM TI. Thank you for the comment, David. Now the test checks: - the threads waiting to enter the monitor are returned correctly with all permutations of threads waiting to be notified and threads waiting to re-enter the monitor Initially, there are 4 threads waiting to be notified and zero threads waiting to re-enter the monitor. They are notified one by with the subsequent checks, so all the pairs are checked `<re-enter,wait-for-notif>`: `<0,4>, <1,3>, <2,2>, <3,1>, <4,0>` I'm not sure why do you think all permutations covering zero and non-zero for each one are needed. At least, it looks like an overkill to me. But if you still think it is really important then I can add cases with zero threads waiting to enter the monitor with the same permutations of threads waiting to be notified and threads re-entering the monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1487402314
