On Wed, 11 Mar 2026 15:05:15 GMT, Patricio Chilano Mateo
<[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
Nice fix in general. I've posted one nit though.
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. Then the check `lockInfo != null` at line 165 can be
removed. if `threadInfo` can be `null` then the assert is too strong.
-------------
PR Review: https://git.openjdk.org/jdk/pull/30199#pullrequestreview-3934231540
PR Review Comment: https://git.openjdk.org/jdk/pull/30199#discussion_r2922545709
