RFR: 8371380: [LOOM] The debug agent should avoid enabling VIRTUAL_THREAD_START/END events when possible

[Chris Plummer]

On Tue, 25 Nov 2025 19:13:44 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Actually it appears that JDWP THREAD_START can have a filter but JVMTI THREAD_START does not allow you to set the thread to enable the events on. That means when JDWP THREAD_START events are requested and a thread filter is provided, JVMTI THREAD_START needs to be enabled for all threads. That's actually how it is working now. I tried adding the assert and it was triggered. So that means passing "thread" instead of NULL would sometimes end up passing an actual thread to JVMTI and it would produce a [JVMTI_ERROR_ILLEGAL_ARGUMENT in that case.
>
> There  is a bug in the call to eventHandlerRestricted_iterator() at line 1436. For VIRTUAL_THREAD_START I should be explicitly passing in NULL for the thread. Otherwise it will consider the thread when deciding if other event handlers are a match to this one, and I don't think we want that. It could lead to disabling VIRTUAL_THREAD_START events when we shouldn't. Seems we don't have any tests for this but I modified an existing test and got a failure. The test creates a ThreadStartRequest with a thread filter and expects that to trigger a ThreadStartEvent for the filter thread. If I create a second ThreadStartRequest with a filter on a different thread, enable it, and then disable it, that ends up disabling all VIRTUAL_THREAD_START events, and the expected event never arrives. Passing NULL fixes the problem.

Ok, the last problem I pointed out is fixed now. The fix was done in matchHasNoPlatformThreadsOnlyFilter(). I was going to pass NULL for "thread" when ei == EI_THREAD_START, but this turned out not to be enough and changes were also needed in matchHasNoPlatformThreadsOnlyFilter(). Once those changes were in place there was no longer a need to pass NULL for "thread".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28485#discussion_r2561360150