On Mon, 25 Sep 2023 10:19:19 GMT, Axel Boldt-Christmas <abold...@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
