|Option Name and Value||Description||Default|
|enumeratevthreads=y|n||thread lists include vthreadsvirtual threads||n|
|notifyvthreads=y|n||send THREAD_START/END events for all vthreadsvirtual threads||y|
- enumeratevthreads control whether or not virtual threads are included in the list of threads returned by JDWP VirtualThread.GetAllThreads and ThreadGroupReference.Children commands. This flag can be turned on for compatibility purposes. This flag will eventually go away and the debug agent will operate as if it was set to 'n'.
- notifyvthreads controls whether or not THREAD_START and THREAD_END events are sent for vthreadsvirtual threads. The default is to send them. The purpose is to allow debugger writers to set to 'n' use notifyvthreads=n to see how the debugger works without getting these events. This is meant as a short term convenience flag rather than having to set the PlatformThreadsOnly filter as described above. In the long run Once support for notifyvthreads=n is gone, if debuggers don't want these eventswant THREAD_START and THREAD_END events for virtual threads, they will need to set the PlatformThreadsOnly filter. When using the PlatformThreadsOnly filter. Since this means no , the debugger can learn about virtual threads when events are delivered for them, such as a BreakpointEvent. Since no THREAD_END event will be sent for the virtual thread, the debugger will then need to figure out how to "forget" about virtual Threads that the virtual threads it is tracking when they have terminated. This could possibly be done with an ObjectReference.IsCollected commanda ThreadDeathRequest that filters on the virtual thread. This would need to be done for each virtual thread being tracked by the debugger. Please note that notifyvthreads=y will not override any PlatformThreadsOnly filter that is in place.
Issues with too many virtual threads hitting breakpoints