The test creates and enables about 10 ThreadStartRequests. It does not expect there to be any threads created while these requests are active. It simply creates them to test out some ThreadStartRequest bookkeeping APIs. However, VirtualThreads introduces spurious creation of ForkJoinPool-1-worker threads. When the test eventually calls EventQueue.remove() to get the next event, it expects a BreakpointEvent. But now it sometimes gets a ThreadStartEvent. This was fixed in JDIBase.breakpointForCommunication() by filtering out ThreadStartRequests. However, that was done to fix other tests that create ThreadStartRequests, not this one. What is different about this test is that the ThreadStartRequests use SUSPEND_ALL rather then SUSPEND_NONE. So it is not enough to just skip the ThreadStartEvent. eventSet.resume() needs to be called to resume all the threads, including the one that the breakpoint is set on (which may or may not have triggered). The end result of this bug is that the thread the breakpoint happens on remains suspended, so the BreakpointEvent is never sent and the test times out. Calling eventSet.resume() seems to fix the issue.
Tested by running the test with virtual threads at least 1000 times (it was reproducing much more often than this). Ran all nsk/jdk tests about 200 times. Ran all svc tier2 and tier5 tests. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - fix jcheck whitespace error - Be sure to resume eventSet Changes: https://git.openjdk.org/jdk/pull/31746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=31746&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327967 Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/31746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/31746/head:pull/31746 PR: https://git.openjdk.org/jdk/pull/31746
