On Thu, 12 Mar 2026 06:23:05 GMT, Serguei Spitsyn <[email protected]> wrote:
>> Please review the following small test fix. Test `SuspendResume3.java` can
>> deadlock due to `worker2` being suspended at the wrong place. This can
>> happen because `arriveAndAwaitAdvance()` may trigger additional class
>> loading/initialization, during which the thread can also appear as `BLOCKED`
>> and thus be suspended later on. If the main thread tries to access those
>> same classes before resuming `worker2` then the test will deadlock. I added
>> the specific scenario involving class `ForkJoinPool` to JBS including the
>> relevant stack traces.
>>
>> The fix is to use the management API to check `worker2` is blocked on the
>> specific monitor.
>>
>> The issue was observed by running local tests. I was able to reproduce it
>> locally and verified the issue is now fixed.
>>
>> Thanks,
>> Patricio
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume3/SuspendResume3.java
> line 163:
>
>> 161: while (true) {
>> 162: ThreadInfo threadInfo =
>> ManagementFactory.getThreadMXBean().getThreadInfo(thread.threadId());
>> 163: assertTrue(threadInfo != null, "getThreadInfo() failed");
>
> Nit: If `threadInfo` is expected to be `non-null` then the lines 162-163 can
> be placed before the loop.
The `ThreadInfo` is a snapshot of the thread's current state so we have to
re-sample each time through the loop.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30199#discussion_r2922594852
