Interface InterfaceType

The method invocation will occur in the specified thread. Method invocation can occur only if the specified thread has been suspended by an event which occurred in that thread. Method invocation is not supported when the target VM has been suspended through VirtualMachine.suspend() or when the specified thread is suspended through ThreadReference.suspend().

The specified method is invoked with the arguments in the specified argument list. The method invocation is synchronous; this method does not return until the invoked method returns in the target VM. If the invoked method throws an exception, this method will throw an InvocationException which contains a mirror to the exception object thrown.

Object arguments must be assignment compatible with the argument type (This implies that the argument type must be loaded through the enclosing class' class loader). Primitive arguments must be either assignment compatible with the argument type or must be convertible to the argument type without loss of information. If the method being called accepts a variable number of arguments, then the last argument type is an array of some component type. The argument in the matching position can be omitted, or can be null, an array of the same component type, or an argument of the component type followed by any number of other arguments of the same type. If the argument is omitted, then a 0 length array of the component type is passed. The component type can be a primitive type. Autoboxing is not supported. See Section 5.2 of The Java Language Specification for more information on assignment compatibility.

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. Note, however, that this implicit resume acts exactly like ThreadReference.resume(), so if the thread's suspend count is greater than 1, it will remain in a suspended state during the invocation and thus a deadlock could still occur. By default, when the invocation completes, all threads in the target VM are suspended, regardless their state before the invocation. It is possible that breakpoints or other events might occur during the invocation. This can cause deadlocks as described above. It can also cause a deadlock if invokeMethod is called from the client's event handler thread. In this case, this thread will be waiting for the invokeMethod to complete and won't read the EventSet that comes in for the new event. If this new EventSet is SUSPEND_ALL, then a deadlock will occur because no one will resume the EventSet. To avoid this, all EventRequests should be disabled before doing the invokeMethod, or the invokeMethod should not be done from the client's event handler thread.

The resumption of other threads during the invocation can be prevented by specifying the ClassType.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. Only the specified thread will be resumed (as described for all threads above). Upon completion of a single threaded invoke, the invoking thread will be suspended once again. Note that any threads started during the single threaded invocation will not be suspended when the invocation completes.

If the target VM is disconnected during the invoke (for example, through VirtualMachine.dispose()) the method invocation continues.