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

[Serguei Spitsyn]

On Thu, 8 Jan 2026 04:41: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 134:
> 
>> 132:                           expState, state, jvmtiExpState, singleState, multiState);
>> 133: 
>> 134:         if (state != expState) {
> 
> Assuming that there is no way to find if thread is completely locked, might be it makes a sense to just make a few attempts of checking status?
> The test might sleep between attempts until got expected results. Even get them 3 times in a row.
> So test fails only if we can't get to expected results during some reasonable time. So test would be more stable. 
> The only sleep between single check might be not enough in the case if VM/host is too busy.

I did not want to go this way. My current goal is to make it clear the instability source is not on JVMTI side.
Also, I think even 3 time checking approach will give some failures.

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

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