1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator"
content="HTML Tidy for Linux/x86 (vers 1st February 2002), see www.w3.org" />
<title>How Breakpoints Work</title>
</head>
<body bgcolor="#ffffff">
<h2>How Breakpoints Work</h2>
<h3>Class Diagram</h3>
<p>For an overview of the classes involved, see the
<code>breakpoints.dia</code> file. This is a diagram created with
GNU Dia, a GNOME Linux application.</p>
<h3>Breakpoint Groups</h3>
<p>Breakpoint groups are collections of breakpoints. They can be
modified as a whole, which is convenient for users setting lots of
breakpoints.</p>
<ul>
<li>Disabling a breakpoint group will mean that the breakpoints
in the group can not truly be enabled. Their state may be enabled
but they will remain effectively disabled so long as the parent
group is disabled.</li>
<li>There will be a "Default" breakpoint group into
which all new breakpoints are placed. This group will always be
enabled when a new session starts.</li>
<li>The breakpoint manager will hold the list of breakpoint
groups, inside which all of the breakpoints will reside.</li>
<li>Breakpoint groups can be inside other breakpoint groups.</li>
</ul>
<h3>Breakpoints</h3>
<p>Breakpoints are those objects that cause execution to halt in
the debuggee process. They can be set in any class at any line of
executable code.</p>
<ul>
<li>Breakpoints have several states: unresolved, disabled,
expired, skipping</li>
<li>The 'stop' command will still work, but creates only
a simple breakpoint. More complex options must be configured
through breakpoint dialog.</li>
<li>Breakpoints will support more than one conditional. For the
breakpoint to halt execution, all of the conditionals must be
satisfied.</li>
<li>Breakpoints will keep track of how many times they were
hit.</li>
<li>Breakpoints should probably have colors associated with their
states, so various UI components are consistent overall. Make a
method for getting the breakpoint's "color", so
other classes are easier to write.</li>
<li>Breakpoints will support more than one monitor. A monitor is
an action that will be performed whenever the breakpoint should
stop.</li>
<li>Breakpoints define a shouldResume() method that tells whether
or not the execution of the debuggee VM should remain halted.
This is called when a BreakpointEvent has occurred in the
debuggee VM. This method will first check if the breakpoint has
expired or not. Then it will check the set of conditionals to see
if the conditions are satisfied.</li>
<li>The breakpoint has a shouldResume() method that returns true
if the conditions are not satisfactory for the breakpoint to
cause the debuggee VM to stop executing.</li>
<li>The breakpoint defines a performStop() method should be
called when the breakpoint has been "hit" so that
monitors are executed.</li>
<li>Breakpoints need a reset() method to reset all the counts to
zero and return it to unresolved state. This will not affect the
enabled state.</li>
<li>When the session deactivates, the breakpoints are all
reset.</li>
<li>When the same session begins again, the breakpoints need to
prepare to resolve themselves.</li>
<li>Breakpoint manager needs to re-enable itself when the session
activates.</li>
</ul>
<h3>How to set a breakpoint</h3>
<ul>
<li>UI layer gets a breakpoint setting request, such as an
invocation of the 'set' command or the SetBreakAction.
This calls on the BreakpointManager to create the appropriate
breakpoint.</li>
<li>The breakpoint is created and inserted into the list of
breakpoints in the breakpoint manager's "default"
breakpoint group.</li>
<li>Breakpoint manager will attempt to resolve the breakpoint
immediately.</li>
<li>The breakpoint classes are responsible for dealing with the
mechanics of resolving themselves.</li>
</ul>
<h3>How breakpoints are resolved</h3>
<ul>
<li>BreakpointManager listens for class prepare events whenever
necessary. If there are no breakpoints, it will not listen. When
a new breakpoint is created during an active session, the manager
must start listening.</li>
<li>
Types of breakpoints and what they need to resolve.
<ul>
<li>watchpoint: Field, ReferenceType, optional class/thread
filters</li>
<li>breakpoint: Location, ReferenceType, optional thread
filter</li>
<li>exception: ReferenceType, optional class/thread
filters</li>
<li>class prepare/unload: none, optional class filter</li>
<li>method entry/exit: none, optional class/thread
filters</li>
<li>thread start/death: none, optional thread filter</li>
</ul>
</li>
<li>ResolvableBreakpoint is an abstract subclass of
DefaultBreakpoint, which resolves itself against a
ReferenceType.</li>
<li>When a new breakpoint is created, it will be asked to try to
resolve immediately. If it 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 manager to look up the
breakpoint that created the request.</li>
<li>The breakpoint manager listens for class prepare events. When
one occurs it will look up the "breakpoint" that
requested the event. If one exists, it will be asked to
resolve.</li>
</ul>
<h3>What happens when an event occurs</h3>
<ul>
<li>VMEventManager gets the event and sends it off to the event
listeners.</li>
<li>Each breakpoint class must listen for the events it is
interested in. This is easier than having a single class listen
for all types of events.</li>
<li>Breakpoint receives the event notification and compares the
value of the "breakpoint" property of the EventRequest
that generated this event. If it matches, the shouldResume()
method is called to determine whether to continue the debuggee VM
or not.</li>
<li>If the breakpoint should stop, the performStop() method
should be called so it will increment the stopped counter and run
any registered monitors.</li>
</ul>
<h3>How breakpoints are customized</h3>
<ul>
<li>Breakpoint dialog iterates breakpoint groups and shows a tree
of breakpoints in the dialog. For each breakpoint group, a group
node is created. For each breakpoint, a breakpoint (leaf) node is
created.</li>
<li>
Buttons on the side of the breakpoints dialog allow the user to
modify the breakpoints. The buttons will include:
<ul>
<li>"Properties..."</li>
<li>"Show Source"</li>
<li>"Disable"</li>
<li>"Enable"</li>
<li>"Remove"</li>
<li>"New Breakpoint..."</li>
<li>"New Group..."</li>
</ul>
</li>
<li>The create button will bring up the SetBreak action, for
now.</li>
<li>Someday the create button will need to have clones that
create other types of breakpoints (i.e. "create watch",
"create catch").</li>
<li>The tree uses custom node objects to keep a reference from
the tree node to the breakpoint group or breakpoint.</li>
<li>The tree nodes must have custom renderers to show the
breakpoint or group status (resolved, disabled, etc.).</li>
<li>Each breakpoint subclass must provide an accessor method,
getUIAdapter(), that returns an appropriate user interface
adapter (which implements the UIAdapter interface).</li>
<li>The UI adapter will have a JComponent widget that contains
the user interface widget(s). The UI adapter will have a commit()
method to save the widget values to the breakpoint, condition, or
monitor.</li>
<li>The breakpoint manager dialog builds a breakpoint editor
dialog and stuffs the breakpoint's UI into this editor
dialog, including any monitors and conditions for the
breakpoint.</li>
<li>After changes are accepted, the editor dialog calls the UI
adapters and tells them to save their values to their respective
objects (breakpoints, conditions, and monitors).</li>
</ul>
<h3>How Conditions work</h3>
<ul>
<li>Must be given Session instance to retrieve information in
order to evaluate the condition.</li>
<li>Returns true if the condition is satisfied.</li>
<li>EditorDialog shows a list of defined Conditions.</li>
<li>ConditionUI provides a String descriptor for the
condition.</li>
<li>EditorDialog provides "add condition" and
"remove condition" buttons.</li>
</ul>
<h3>How breakpoints are persisted</h3>
<ul>
<li>The breakpoint groups, breakpoints, conditions, and monitors
are all stored in nodes of type
<code>java.util.prefs.Preferences</code>, the class provided in
JDK 1.4 and later.</li>
<li>Serialization begins with the default breakpoint and
traverses down the tree until everything has been saved.</li>
<li>Breakpoint manager handles [de]serialization of the
breakpoints.</li>
</ul>
<h3>How breakpoints link up with source code</h3>
<ul>
<li>Have a "LocatableBreakpoint" interface that certain
breakpoint classes will implement.</li>
<li>A resolved locatable breakpoint will have a Location for the
breakpoint.</li>
<li>A resolved locatable breakpoint can determine if it belongs
to a certain source file or not (uses the locatable event
request's location).</li>
<li>An unresolved locatable breakpoint can make a guess as to
whether it belongs to a certain source file or not (uses the
class name pattern to match the filename).</li>
<li>How will unresolved method breakpoints know which line they
are set at?</li>
<li>If classname of locatable breakpoint is not wild-carded, can
use it to map to the source file.</li>
</ul>
</body>
</html>
|
