On Wed, 10 Dec 2025 08:48:07 GMT, Serguei Spitsyn <[email protected]> wrote:
>> This fixes the test which is unreliable and fails intermittently from time >> to time. >> The test was failing in the method `checkReentrantLock()` when comparing the >> expected state with result from `vt.getState()`. The issue is that the call >> to `ThreadListStackTracesTest.reentrantLock.lock()` in a >> `ReentrantLockTestTask` can reach waiting state on some class loading but >> not on the ReentrantLock. Please see the first comment for test sources >> details. >> The fix is to add a big enough sleep before call to the checkStates(). >> >> Testing: >> - submitted about thousands of mach5 runs of the >> `ThreadListStackTracesTest` test runs before and after the fix >> - TBD: submit mach5 tiers 1-3 to be completely safe > > Serguei Spitsyn has updated the pull request incrementally with one > additional commit since the last revision: > > minor correction for sleep Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 100: > 98: TestTask task = new ReentrantLockTestTask(); > 99: Thread vt = Thread.ofVirtual().name(name).start(task); > 100: TestTask.sleep(50); // allow potentially needed class loading to > complete The just sleep might be unreliable. Would it makes sense to wait until `lock.hasQueuedThreads()` becomes true? If 'hasQueuedThreads' doesn't work then makes to pre-load classes used by lock before running test. ------------- PR Review: https://git.openjdk.org/jdk/pull/28734#pullrequestreview-3565186542 PR Review Comment: https://git.openjdk.org/jdk/pull/28734#discussion_r2608755950
