The JDI spec says the following regarding ObjectReference.invokeMethod():

https://docs.oracle.com/en/java/javase/17/docs/api/jdk.jdi/com/sun/jdi/ClassType.html

"By default, all threads in the target VM are resumed while the method is being invoked if they were previously suspended by an event or by VirtualMachine.suspend() or ThreadReference.suspend(). This is done to prevent the deadlocks that will occur if any of the threads own monitors that will be needed by the invoked method."

"The resumption of other threads during the invocation can be prevented by specifying the INVOKE_SINGLE_THREADED bit flag in the options argument; however, there is no protection against or recovery from the deadlocks described above, so this option should be used with great caution."

The first issue is the reference to deadlocks due to "monitors" needed during the invoke. There are other types of resources that the invoked method might need and can result in a deadlock if all threads are not resumed. We can't even know all the types due some of them potentially being native, but a common one would be j.u.concurrent locks. The spec language should be more generic to cover these types of resources.

Another change needed is that when invoking on a virtual thread, there are potentially different resource requirements that can result in a deadlock than you would have when invoking on a platform thread. This is because there are many java library implementation difference that are dependent on the type of thread. For example Thread.sleep() may result in a deadlock when using INVOKE_SINGLE_THREADED on a virtual thread, but it generally is not an issue with platform threads. These potential behavior differences between platform threads and virtual threads should be called out in the spec.

These spec clarifications are needed with the following JDI methods:

ClassType.invokeMethod()
ClassType.newInstance()
InterfaceType.invokeMethod()
ObjectReference.invokeMethod()

And the following JDWP commands:

ClassType.InvokeMethod
ClassType.NewInstance
InterfaceType.InvokeMethod
ObjectReference.InvokeMethod