RFR: 8316417: ObjectMonitorIterator does not return the most recent monitor and is incorrect if no monitors exists [v6]
David Holmes
dholmes at openjdk.org
Tue Sep 26 05:04:22 UTC 2023
On Mon, 25 Sep 2023 10:19:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java line 1:
>>
>>> 1: /*
>>
>> This test still barely actually tests the iterator code.
>
> Agreed. Did not want to spend time learning the SA, but maybe I should. So I can write a proper test.
> It does however seem very hard to write a proper test. Also not sure how to make it non-flaky, maybe start a lingering App, let it reach steady state, get the monitor list from some other API (maybe there is a jcmd, or we have to use the whitebox API from the actual process and print it somewhere, and hope the state of which monitors exists does not change), then attach the SA and run and compare the lists.
>
> It seems hard to me to ensure that the SA agent prints all monitors in the `_in_use_list` with a test.
>
> Or you would have to maintain a list of monitors for each locking mode and the lingering app.
Right. You would have to write the test as a state machine, very carefully orchestrating when monitors become in-use and when they cease to be in-use, and then attaching (the detaching) the SA when it reached each state and then checking the expected conditions for that state. Certainly a very non-trivial thing to try and do.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15782#discussion_r1336626565
More information about the serviceability-dev
mailing list