RFR: 8371502: serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java failing [v2]

[Leonid Mesnik]

On Wed, 10 Dec 2025 08:48:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> 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