JDK-8262080 attempted to fix the issue of request001 failing due to unexpected THREAD_START events for threads unrelated to the test. However, the fix is not working, and fails consistently with loom, which creates a large number of carrier threads if the test is run in vthread wrapper mode.

The problem is when JDIBase.getEventSetForThreadStartDeath() is called. It is suppose to exit when a THREAD_START or THREAD_END event arrives for the named thread, and skip all other THREAD_START and THREAD_END events, so it should work when there are extra THREAD_START events for carrier threads. However, there are two bugs, one in the test and one in getEventSetForThreadStartDeath().

The bug in the test is that it adds a count filter of 1 to the ThreadStartRequest (and ThreadDeathRequest). This means that once the first spurious THREAD_START is received, all future THREAD_START event are filtered out. I'm not sure why the count filter was added in the first place (it was there before your fix). I think it can be removed, although to be extra safe probably the event request should also be disabled once the event is received.

The other bug has its origins in the test, but is really in getEventSetForThreadStartDeath(). The test sets up the ThreadStartRequest and ThreadDeathRequest with a suspend policy of SUSPEND_ALL. This means once the first spurious THREAD_START is received, all threads are suspended and never resume. A call to vm.resume() is needed after each of these spurious events. Otherwise the test just times out waiting for the next event.

After fixing these two issues I have the test passing, but I'm a little unsure if they are proper fixes. It looks like the only other test could end up with this same issue is nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001, although I haven't seen it fail. That's probably because it only uses getEventSetForThreadStartDeath() for the THREAD_END event, and we don't get any spurious THREAD_END events. So it is likely not going to be impacted by my changes.