JDK-8282441 is mainly about having the debug agent free up ThreadNodes for running virtual threads so it doesn't accumulate too many. It was thought that this was largely the cause of the performance issues with the test included with JDK-8282441, but it turns out that is not the case. The issues is really the handling of the flood of VIRTUAL_THREAD_START/END events that are generated, and the upkeep this requires in JVMTI, which needs to create a jvmtiThreadState for each thread. JDK-8282441 will be used to free up ThreadNodes as originally planned. This CR will address the VIRTUAL_THREAD_START/END issue.

If the debug agent includevirtualtrheads option is not set to 'y' (it is 'n' by default), then it is possible for the debug agent to start up without enabling VIRTUAL_THREAD_START/END events (currently it always enables them). However, they need to be enabled if the debugger creates any ThreadStartRequests or ThreadDeathRequests and do not include the PlatformThreadsOnly filter. Given that by default jdb and mainstream debuggers all seem to add this filter, this is unlikely to be an issue.

There is also one edge cases that debuggers may run into (jdb does). If the debugger learns about a virtual thread (like when a breakpoint is hit), it may want to track it in some sort of list. It will then need a ThreadDeathRequest to be notified when that thread can be removed from the list. If ThreadDeathRequests are enabled globally (for all threads), that would introduce performance issues. However, the debugger can instead filter the ThreadDeathRequest on just that one particular thread, so this shouldn't introduce the performance issue you would see if ThreadDeathRequests were enabled globally.