On Thu, 8 Jan 2026 04:41:59 GMT, Leonid Mesnik <[email protected]> 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
