1. Enumerate all threads

   • JDI VirtualThreads.allThreads() do not enumerate virtual threads

   • JDWP VirtualMachine/AllThreads command

2. Thread groups

   • Virtual threads are not active members of a thread group

   • JDI ThreadGroupReference::threads does not include virtual threads

   • JDWP ThreadGroupReference/Children command

3. Thread start/end events

   • New JDI ThreadStartRequest/ThreadEndRequest removeVirtualThreadFilter method to virtual events for virtual threads, filter is opt-out

   • New JDWP EventRequest/Set VirtualThreadsExclude filter to filter thread start/end events for virtual threads, filter is opt-in

4. Test if a thread is a virtual thread

   • New JDI ThreadReference::isVirtual

   • New JDWP ThreadReference/IsVirtual

5. Features not implements for virtual threads:

   • JDI ThreadReference::stop / JDWP ThreadReference/Stop

   • JDI ThreadReference::interrupt / JDWP ThreadReference/Interrupt

   • Force early return, set locals, .... what else?

Debuggers and tools using the Java Debug Interface API observe the following differences:

1. com.sun.jdi.VirtualMachine::allThreads enumerates platform threads only, the list does not include mirrors for virtual threads.
2. Virtual threads are not live threads in a thread group so ThreadGroupReference::threads only lists platform threads.
3. ThreadStartRequest/ThreadDeathRequest request notifications of thread start/termination of platform threads by default. Tools have to opt-in to get start/death events for virtual threads (by invoking the removeVirtualThreadFilter method on the event request.

As a temporary measure to support existing IDEs/debugger releases, the JDWP agent tracks virtual threads so that VirtualMachine::allThreads and ThreadGroupReference::threads will enumerate virtual threads. This is not a scalable solution and highly unsuited to environments where a debugger is attached to a running VM.