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

[Chris Plummer]

On Tue, 25 Nov 2025 17:33:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> THREAD_START can't have a thread filter. THREAD_END can. "thread" == requestThread(node) == the thread filter if there is one, so when disabling THREAD_START it could be an actual thread or it could just be NULL. For THREAD_START "thread" should always be NULL, so I suppose I could have just asserted that and used "thread" as the argument instead of "NULL".
>
> 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.

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

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