Provides one of the most important features of any debugger, the
breakpoints. Breakpoints are defined by the user and tell the
debuggee where and when to suspend execution of the debuggee.
The BreakpointManager
implementations are accessed
via the BreakpointProvider
static class. To provide
custom implementations of BreakpointManager
, you must
install your implementation as a "service". See the
NetBeans OpenAPIs documentation under "Services &
Lookup" to learn how this is done.
Similarly, instances of BreakpointFactory
are
acquired via the BreakpointProvider
static class. To
provide custom implementations of BreakpointFactory
, you
must install your implementation as a "service".
How Breakpoints Work
Breakpoint Groups
Breakpoint groups are collections of breakpoints, as well as other
breakpoint groups. They can be modified as a whole, which allows
enabling and disabling an entire set of breakpoints at once.
- Disabling a breakpoint group means that the breakpoints in the
group will effectively be disabled. Their state may be enabled but
they will remain disabled so long as the parent group is
disabled.
- A breakpoint group called "Default" is the root of
the breakpoint group tree. Initially all new breakpoints are placed
in this group. This group is always enabled when a new session
starts.
Breakpoints
Breakpoints are those objects that cause execution to suspend in
the debuggee. There are various types of breakpoints, from method and
line breakpoints, to class, variable, and thread breakpoints.
- Breakpoints have several states: resolved, disabled, expired,
and skipping
- Breakpoints support optional conditions. For the breakpoint to
suspend execution, its conditions must be satisfied.
- Breakpoints keep track of how many times they were hit.
- Breakpoints support optional monitors. A monitor is an action
that is performed whenever the breakpoint causes execution to
suspend.
- Breakpoints will suspend execution when they have resolved, are
not being skipped, have not yet expired, and all of their
conditions are satisfied.
- When the session disconnects, all of the breakpoints are reset
such that they are all unresolved and their hit counts are set to
zero. When this happens their skipping and expired state may
change.
How a breakpoint is set
- The client will construct a breakpoint using an instance of the
BreakpointFactory. It provides numerous methods for creating
breakpoints of different types.
- The client must then invoke the "add" operation on
the BreakpointManager so that the breakpoint can be maintained by
the manager from that point onward.
- The BreakpointManager inserts the new breakpoint into the list
of breakpoints, adding it to the default breakpoint group.
- If the breakpoint needs to be resolved, the BreakpointManager
will try to resolve it immediately. If that fails, it will try to
resolve it against each new class that loads during execution of
the debuggee.
- The BreakpointManager will hook the breakpoint into the system,
ensuring it is registered with the appropriate services.
How breakpoints are resolved
- Each breakpoint implementation listens for the appropriate JDI
events from the JDI event dispatcher.
- ResolvableBreakpoint is an abstract subclass of
AbstractBreakpoint, which resolves itself against a
ReferenceType.
- When a new breakpoint is created, the BreakpointManager will
ask the breakpoint to resolve itself immediately. If the breakpoint
is unsuccessful, an appropriate event request is created. The event
request will contain a property called "breakpoint" that
refers to the breakpoint that created it. This is used by the
breakpoint to respond to a particular JDI event, when it
occurs.
What happens when an event occurs
- The Dispatcher gets the JDI event and passes it on to the
interested event listeners.
- Each breakpoint class must listen for the events it is
interested in.
- The breakpoint receives the event and compares the value of the
"breakpoint" property of the event request that generated
this event. If it matches, the breakpoint has been
"hit".
- If the breakpoint should suspend execution, the stopped counter
will be incremented and its monitors will be run.
How breakpoints are persisted
- The breakpoint groups, breakpoints, conditions, and monitors
are all serialized to a file located in the user directory.
- Serialization begins with the default breakpoint group and
traverses down the tree until everything has been saved.
- The BreakpointManager handles de/serialization of the
breakpoints at the appropriate times.