Microsoft SDK for Java

Controlling Execution

Monitoring execution of a Java process is possible through the IRemoteThread and IRemoteStackFrame interfaces. These interfaces provide access to the Java method call stacks of the threads executing in the Java process being debugged. Each stack frame represents a method's state of execution. Consequently, execution state information cannot be cached by the debugger across execution of the process being debugged. See the Execution Control Debugger Interfaces reference for details.

The execution monitoring interfaces consist primarily of the IRemoteThreadGroup, IRemoteThread, and IRemoteStackFrame interfaces and a collection of enumeration interfaces.

The IRemoteThreadGroup and IRemoteThreadGroupEx interfaces implement a set of methods that get the name of a thread group and enumerate the other thread groups and threads in a thread group.

Execution of a Java process is controlled through methods implemented by the IRemoteThread and IRemoteThreadEx interfaces. Methods on these interfaces allow a debugger to suspend or resume execution of a thread, step within a method, step into, over, or out of a call to a method, and get the current stack frame on a thread. Other methods return the name of the thread and the thread group containing this thread.

For notification, many of these methods generate a StepEvent or CanStopEvent call to the debugger on its IRemoteProcessCallbackEx2 interface. If StepEvent or any other debugger event notification callback method returns S_FALSE, Java execution of the process being debugged resumes. If StepEvent or any other debugger event notification callback method returns S_OK, Java execution of the process being debugged remains suspended until Go or some other execution stepping method is called.

The IRemoteThread execution stepping methods all return immediately. While a thread is executing in any stepping mode, the Microsoft VM calls stepping event notification methods on the debugger's IRemoteProcessCallbackEx2 interface to notify the debugger of the thread's changing execution state. A stepping frame is the current stack frame of a thread when one of the thread's stepping methods is called.

The following three tables describe the execution notification events dispatched to the debugger in the three different stepping modes.

Step over mode invoked by Step or RangeStep

Thread execution event IRemoteProcessCallbackEx2 event notification
Execution about to occur outside stepping range in stepping frame. StepEvent.
Stepping frame calls method. None.
Stepping frame returns to caller. MSJDBG_SEND_CAN_STOP_EVENT_ON_STEP_OUT set: CanStopEvent.

MSJDBG_SEND_CAN_STOP_EVENT_ON_STEP_OUT clear: StepEvent.


Step in mode invoked by StepIn or RangeStepIn

Thread execution event IRemoteProcessCallbackEx2 event notification
Execution about to occur outside stepping range in stepping frame. StepEvent.
Stepping frame calls method. CanStopEvent.
Stepping frame returns to caller. MSJDBG_SEND_CAN_STOP_EVENT_ON_STEP_OUT set: CanStopEvent.

MSJDBG_SEND_CAN_STOP_EVENT_ON_STEP_OUT clear: StepEvent.


Step out mode invoked by StepOut

Thread execution event IRemoteProcessCallbackEx2 event notification
Execution about to occur outside stepping range in stepping frame. Not applicable (no stepping range).
Stepping frame calls method. None.
Stepping frame returns to caller. MSJDBG_SEND_CAN_STOP_EVENT_ON_STEP_OUT set: CanStopEvent.

MSJDBG_SEND_CAN_STOP_EVENT_ON_STEP_OUT clear: StepEvent.


Call stacks are accessed through methods implemented by the IRemoteThread, IRemoteThreadEx, and IRemoteStackFrame interfaces. The current stack frame can be returned by calling GetCurrentFrame. An enumerator (IEnumRemoteStackFrames) for a thread's entire call stack can be obtained by calling GetStackFrames.

GetKind returns the execution model of the associated stack frame as one of the values from the FRAMEKIND enumeration.

The IMethodLocation interface represents a location within a method where code can execute. The IMethodLocation interface allows a debugger to set a code breakpoint at interpreted bytecode locations within a source line. This differs from the static information interface method IRemoteMethodField::SetBreakpoint, which always sets a code breakpoint at the first JIT-compiled opcode for the containing source line. The debugger can obtain an enumerator (IEnumCodeBreakpoints) for all IMethodLocation code breakpoints set in a method by calling IRemoteMethodFieldEx::GetCodeBreakpoints.

In some cases, the Microsoft VM may use multiple execution models for a single method (both interpreted and JIT-compiled, for example) executing in different stack frames. Using the IMethodLocation interface for setting code breakpoints yields consistent behavior across these execution models.

© 1999 Microsoft Corporation. All rights reserved. Terms of use.