On Thu, 8 Jan 2026 04:20: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 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
