P5
A DESCRIPTION OF THE REQUEST :
I believe there is a need to clarify the semantics of JDI/JDWP breakpoint events to define precisely when a breakpoint event is guaranteed to be raised with respect to the monitored program execution.
The current wording of the API specification reads "The breakpoint event is generated before the code at its location is executed", which leads to a subtle ambiguity in multi-threaded executions: is the breakpoint event raised immediately after execution of the code preceding the breakpoint location, or immediately prior to the execution of the code at the breakpoint location?
Ideally, it might even be preferable to enhance the API with "pre-step" and "post-step" breakpoint events. I will refrain from filing this as a separate RFE pending further discussion.
JUSTIFICATION :
Knowing when the breakpoint event occurs with respect to the actual execution of the code may have implications for analysis of program behavior, and optimizations in utilization of the JDI by debuggers.
As an example, watchpoint events are very costly. They observably introduce an order of magnitude overhead in the debuggee, even if no watchpoints are being matched. If the semantics of the breakpoint are such that it is raised immediately following the execution of the instruction preceding the breakpoint location, debuggers that are interested in field events at specific bytecode locations can use much more efficient breakpoint events to capture field related events, by setting a breakpoint immediately after the field related instruction. Other examples exist.
There may also be correctness implications for certain types of analyses. If it is possible for code in other threads to execute after handling of a breakpoint event, but before the execution of the code at the location in the triggering thread (which is permitted by the current semantics), it may affect the correctness of perceived ordering of events, or impact the effects actions taken by debuggers.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Clarification of the semantics of when breakpoint events are actually raised relative to the execution of the code at the specified location within the debuggee VM.
ACTUAL -
It is currently not possible to determine the exact semantics in a multi-threaded context.
CUSTOMER SUBMITTED WORKAROUND :
Make a guess.
I believe there is a need to clarify the semantics of JDI/JDWP breakpoint events to define precisely when a breakpoint event is guaranteed to be raised with respect to the monitored program execution.
The current wording of the API specification reads "The breakpoint event is generated before the code at its location is executed", which leads to a subtle ambiguity in multi-threaded executions: is the breakpoint event raised immediately after execution of the code preceding the breakpoint location, or immediately prior to the execution of the code at the breakpoint location?
Ideally, it might even be preferable to enhance the API with "pre-step" and "post-step" breakpoint events. I will refrain from filing this as a separate RFE pending further discussion.
JUSTIFICATION :
Knowing when the breakpoint event occurs with respect to the actual execution of the code may have implications for analysis of program behavior, and optimizations in utilization of the JDI by debuggers.
As an example, watchpoint events are very costly. They observably introduce an order of magnitude overhead in the debuggee, even if no watchpoints are being matched. If the semantics of the breakpoint are such that it is raised immediately following the execution of the instruction preceding the breakpoint location, debuggers that are interested in field events at specific bytecode locations can use much more efficient breakpoint events to capture field related events, by setting a breakpoint immediately after the field related instruction. Other examples exist.
There may also be correctness implications for certain types of analyses. If it is possible for code in other threads to execute after handling of a breakpoint event, but before the execution of the code at the location in the triggering thread (which is permitted by the current semantics), it may affect the correctness of perceived ordering of events, or impact the effects actions taken by debuggers.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Clarification of the semantics of when breakpoint events are actually raised relative to the execution of the code at the specified location within the debuggee VM.
ACTUAL -
It is currently not possible to determine the exact semantics in a multi-threaded context.
CUSTOMER SUBMITTED WORKAROUND :
Make a guess.