RFR: 8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing

[Serguei Spitsyn]

On Thu, 8 Jan 2026 04:20:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The test is still failing after the fix of [JDK-8371502](https://bugs.openjdk.org/browse/JDK-8371502). I suspect the issue is in the `ReentrantLock` implementation but suggest to make one more update of this test to make it more clear.
>> The test update includes the following changes:
>>  - update method `ensureReadyAndWaiting()`:
>>     - add `sleep(50)` at start of method
>>     - replace call to `rlock.hasQueuedThreads()` with call to `rlock.hasQueuedThread(vt)`
>>  - update method `checkStates()` to make it more stable and tracing output more clear
>>  
>>  Testing:
>>   - TBD: mach5 tiers 1-3
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java line 48:
> 
>> 46: 
>> 47:     public void ensureReadyAndWaiting(Thread vt, Thread.State expState, ReentrantLock rlock) {
>> 48:         sleep(50); // reliability: wait for a potential ReentrantLock class loading to complete
> 
> It is not clear how ReentrantLock might be not loaded already.  Can you please explain what do you mean?

There can be more than one class. E.g., some can be involved on contention.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29102#discussion_r2674765502