jikesrvm.github.io/UserGuide/ProfilingApplicationsWithJikesRVM.html at master · JikesRVM/jikesrvm.github.io · GitHub

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
---
layout: default
---
<?xml version="1.0" encoding="utf8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!--http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd-->
<html xmlns="http://www.w3.org/1999/xhtml"
>
<head><title>8 Proﬁling Applications with Jikes RVM</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf8" />
<meta name="generator" content="TeX4ht (https://tug.org/tex4ht/)" />
<meta name="originator" content="TeX4ht (https://tug.org/tex4ht/)" />
<!-- xhtml,charset=utf8,2,html -->
<meta name="src" content="index.tex" />
<link rel="stylesheet" type="text/css" href="index.css" />
</head><body
>
<!--l. 2--><div class="crosslinks"><p class="noindent"></p></div>
<h2 class="chapterHead"><span class="titlemark">Chapter 8</span><br /><a
 id="x10-990008"></a>Proﬁling Applications with Jikes RVM</h2>
<!--l. 5--><p class="noindent" >The Jikes RVM adaptive system can also be used as a tool for gathering proﬁle data
to ﬁnd application/VM hotspots. In particular, the same low-overhead time-based
sampling mechanism that is used to drive recompilation decisions can also be used
to produce an aggregate proﬁle of the execution of an application. Here’s
how.
     </p><ol  class="enumerate1" >
     <li
  class="enumerate" id="x10-99002x1">Build an adaptive conﬁguration of Jikes RVM. For the most accurate
     proﬁle, use the production conﬁguration.
     </li>
     <li
  class="enumerate" id="x10-99004x2">Run  the  application  normally,  but  with  the  additional  command  line
     argument <span class="obeylines-h"><span class="verb"><span
class="cmtt-10">-X:aos:gather_profile_data=true</span></span></span>
     </li>
     <li
  class="enumerate" id="x10-99006x3">When the application terminates, data on which methods and call graph
     edges were sampled during execution will be printed to stdout (you may
     want to redirect execution to a ﬁle for analysis).</li></ol>
<!--l. 13--><p class="noindent" >The sampled methods represent compiled versions of methods, so as methods are
recompiled and old versions are replaced some of the methods sampled earlier in the
run may be OBSOLETE by the time the proﬁle data is printed at the end of the
run.
</p><!--l. 15--><p class="noindent" >In addition to the sampling-based mechanisms, the baseline compiler can inject code
to gather branch probabilites on all executed conditional branches. This proﬁling is
enabled by default in adaptive conﬁgurations of Jikes RVM and can be enabled via
the command line in non-adaptive conﬁgurations (<span class="obeylines-h"><span class="verb"><span
class="cmtt-10">-X:base:edge_counters=true</span></span></span>).
In an adaptive conﬁguration, use <br
class="newline" /><span class="obeylines-h"><span class="verb"><span
class="cmtt-10">-X:aos:final_report_level=2</span></span></span> to cause the edge counter data to be dumped to a
ﬁle. In non-adaptive conﬁgurations, enabling edge counters implies that
the ﬁle should be generated (<span class="obeylines-h"><span class="verb"><span
class="cmtt-10">-X:base:edge_counters=true</span></span></span> is suﬃcient).
The default name of the ﬁle is EdgeCounters, which can be changed with
<br
class="newline" /><span class="obeylines-h"><span class="verb"><span
class="cmtt-10">-X:base:edge_counter_file=&#x003C;file_name&#x003E;</span></span></span>. Note that the proﬁling is only injected
in baseline compiled code, so in a normal adaptive conﬁguration, the gathered
probabilities only represent a subset of program execution (branches in opt-compiled
code are not proﬁled). Note that unless the bootimage is (a) baseline compiled and
(b) edge counters were enabled at bootimage writing time, edge counter data will not
be gathered for bootimage code.
</p>
<h3 class="sectionHead"><span class="titlemark">8.1   </span> <a
 id="x10-1000008.1"></a>Instrumented Event Counters</h3>
<!--l. 19--><p class="noindent" >This section describes how the Jikes RVM optimizing compiler can be used to insert
counters in the optimized code to count the frequency of speciﬁc events.
Infrastructure for counting events is in place that hides many of the implementation
details of the counters, so that (hopefully) adding new code to count events should be
easy. All of the instrumentation phases described below require an adaptive boot
image (any one should work). The code regarding instrumentation lives in the


org.jikesrvm.aos package.
</p><!--l. 21--><p class="noindent" >To instrument all dynamically compiled code, use the following command line arguments
to force all dynamically compiled methods to be compiled by the optimizing
compiler: <span
class="cmtt-10">-X:aos:enable</span><span
class="cmtt-10">_recompilation=false -X:aos:initial</span><span
class="cmtt-10">_compiler=opt</span>
</p><!--l. 23--><p class="noindent" >
</p>
<h4 class="subsectionHead"><span class="titlemark">8.1.1   </span> <a
 id="x10-1010008.1.1"></a>Existing Instrumentation Phases</h4>
<!--l. 25--><p class="noindent" >There are several existing instrumentation phases that can be enabled by giving the
adaptive optimization system command line arguments. These counters
are not synchronized (as discussed later), so they should not be considered
precise.
</p>
     <ul class="itemize1">
     <li class="itemize"><span
class="cmbx-10">Method Invocation Counters </span>Inserts a counter in each opt compiled
     method  prologue.  Prints  counters  to  stderr  at  end.  Enabled  by  the
     command line argument <span class="obeylines-h"><span class="verb"><span
class="cmtt-10">-X:aos:insert_method_counters_opt=true</span></span></span>
     </li>
     <li class="itemize"><span
class="cmbx-10">Yieldpoint Counters </span>Inserts a counter after each yieldpoint instruction.
     Maintains  a  separate  counter  for  backedge  and  prologue  yieldpoints.
     Enabled by <span class="obeylines-h"><span class="verb"><span
class="cmtt-10">-X:aos:insert_yieldpoint_counters=true</span></span></span>
     </li>
     <li class="itemize"><span
class="cmbx-10">Instruction Counters </span>Inserts a counters on each instruction. A separate
     count is maintained for each opcode, and results are dumped to stderr at end of
     run. The results look something like: <!--l. 31-->
     <div class="lstlisting" id="listing-69"><span class="label"><a
 id="x10-101001r1"></a></span><span
class="cmtt-10">Printing</span><span
class="cmtt-10"> </span><span
class="cmtt-10">Instruction</span><span
class="cmtt-10"> </span><span
class="cmtt-10">Counters</span><span
class="cmtt-10">:</span><span
class="cmtt-10"> </span><br /><span class="label"><a
 id="x10-101002r2"></a></span><span
class="cmtt-10">------------------------------</span><span
class="cmtt-10"> </span><br /><span class="label"><a
 id="x10-101003r3"></a></span><span
class="cmtt-10">109.0</span><span
class="cmtt-10"> </span><span
class="cmtt-10">call</span><span
class="cmtt-10"> </span><br /><span class="label"><a
 id="x10-101004r4"></a></span><span
class="cmtt-10">0.0</span><span
class="cmtt-10"> </span><span
class="cmtt-10">int_ifcmp</span><span
class="cmtt-10"> </span><br /><span class="label"><a
 id="x10-101005r5"></a></span><span
class="cmtt-10">30415.0</span><span
class="cmtt-10"> </span><span
class="cmtt-10">getfield</span><span
class="cmtt-10"> </span><br /><span class="label"><a
 id="x10-101006r6"></a></span><span
class="cmtt-10">20039.0</span><span
class="cmtt-10"> </span><span
class="cmtt-10">getstatic</span><span
class="cmtt-10"> </span><br /><span class="label"><a
 id="x10-101007r7"></a></span><span
class="cmtt-10">63.0</span><span
class="cmtt-10"> </span><span
class="cmtt-10">putfield</span><span
class="cmtt-10"> </span><br /><span class="label"><a
 id="x10-101008r8"></a></span><span
class="cmtt-10">20013.0</span><span
class="cmtt-10"> </span><span
class="cmtt-10">putstatic</span><span
class="cmtt-10"> </span><br /><span class="label"><a
 id="x10-101009r9"></a></span><span
class="cmtt-10">Total</span><span
class="cmtt-10">:</span><span
class="cmtt-10"> </span><span
class="cmtt-10">302933</span>

     </div>
     <!--l. 42--><p class="noindent" >This is useful for debugging or assessing the eﬀectiveness of an optimization
     because you can see a dynamic execution count, rather than relying on
     timing.
     </p><!--l. 44--><p class="noindent" >NOTE: Currently the counters are inserted at the end of HIR, so the counts
     <span
class="cmti-10">will </span>capture the eﬀect of HIR optimizations, and will not capture optimization
     that occurs in LIR or later.
     </p></li>
     <li class="itemize"><span
class="cmbx-10">Debugging Counters </span>This ﬂag does not produce observable behavior by
     itself, but is designed to allow debugging counters to be inserted easily in
     opt-compiler to help debugging of opt-compiler transformations. If you would like
     to know the dynamic frequency of a particular event, simply turn on this ﬂag,
     and you can easily count dynamic frequencies of events by calling the method
     <span
class="cmtt-10">AOSDatabase.debuggingCounterData.getCounterInstructionForEvent(String</span>
     <span
class="cmtt-10">eventName)</span>. This method returns an Instruction that can be inserted into the
     code. The instruction will increment a counter associated with the String


     name ”eventName”, and the counter will be printed at the end of
     execution.</li></ul>
<!--l. 48--><p class="noindent" >For an example, see <span class="obeylines-h"><span class="verb"><span
class="cmtt-10">Inliner.java</span></span></span>. Look for the code guarded by the ﬂag
<span class="obeylines-h"><span class="verb"><span
class="cmtt-10">COUNT_FAILED_METHOD_GUARDS</span></span></span>. Enabled by <span
class="cmtt-10">-X:aos:insert</span><span
class="cmtt-10">_debugging</span><span
class="cmtt-10">_counters=true</span>
</p><!--l. 52--><p class="noindent" >
</p>
<h4 class="subsectionHead"><span class="titlemark">8.1.2   </span> <a
 id="x10-1020008.1.2"></a>Writing new instrumentation phases</h4>
<!--l. 54--><p class="noindent" >This section describes the event counting infrastructure. It is not a step-by-step
for writing new phases, but instead is a description of the main ideas of
the counter infrastructure. This description, in combination with the above
examples, should be enough to allow new users to write new instrumentation
phases.
</p><!--l. 56--><p class="noindent" ><span
class="cmbx-10">Counter Managers: </span>Counters are created and inserted into the code using the
<span
class="cmtt-10">InstrumentedEventCounterManager </span>interface. The purpose of the counter
manager interface is to abstract away the implementation details of the
counters, making instrumentation phases simpler and allowing the counter
implementation to be changed easily (new counter managers can be used without
changing any of the instrumentation phases). Currently there exists only one
counter manager, <span
class="cmtt-10">CounterArrayManager</span>, which implements unsynchronized
counters. When instrumentation options are turned on in the adaptive system,
<span class="obeylines-h"><span class="verb"><span
class="cmtt-10">Instrumentation.boot()</span></span></span> creates an instance of a <span
class="cmtt-10">CounterArrayManager</span>.
</p><!--l. 58--><p class="noindent" ><span
class="cmbx-10">Managed Data: </span>The class <span class="obeylines-h"><span class="verb"><span
class="cmtt-10">ManagedCounterData</span></span></span> is used to keep track of counter
data that is managed using a counter manager. This purpose of the data
object is to maintain the mapping between the counters themselves (which
are indexed by number) and the events that they represent. For example,
<span class="obeylines-h"><span class="verb"><span
class="cmtt-10">StringEventCounterData</span></span></span> is used record the fact that counter #1 maps to the event
named ”FooBar”. Depending on what you are counting, there may be one
data object for the whole program (such as <span class="obeylines-h"><span class="verb"><span
class="cmtt-10">YieldpointCounterData</span></span></span> and
<span class="obeylines-h"><span class="verb"><span
class="cmtt-10">MethodInvocationCounterData</span></span></span>), or one per method. There is also a generic data
object called <span class="obeylines-h"><span class="verb"><span
class="cmtt-10">StringEventCounterData</span></span></span> that allows events to be give string names
(see Debugging Counters above).
</p><!--l. 61--><p class="noindent" ><span
class="cmbx-10">Instrumentation Phases: </span>The instrumentation itself is inserted by a compiler
phase. (see <span
class="cmtt-10">InsertInstructionCounters.java</span>, <span
class="cmtt-10">InsertYieldpointCounters.java</span>,
<span
class="cmtt-10">InsertMethodInvocationCounter.java</span>). The instrumentation phase inserts high
level ”count event” instructions (which are obtained by asking the counter manager)
into the code. It also updates the instrumented counter to remember which counters
correspond to which events.
</p><!--l. 63--><p class="noindent" ><span
class="cmbx-10">Lower Instrumentation Phase: </span>This phase converts the high level ”count event”
instruction into the actual counter code by using the counter manager. It currently
occurs at the end of LIR, so instrumentation can not be inserted using this
mechanism after LIR. This phase does not need to be modiﬁed if you add a
new phase, except that the <span class="obeylines-h"><span class="verb"><span
class="cmtt-10">shouldPerform()</span></span></span> method needs to have your
instrumentation listed, so this phase is run when your instrumentation is turned
on.


</p>
<!--l. 2--><div class="crosslinks"><p class="noindent"></p></div>
<!--l. 2--><p class="noindent" ><a
 id="tailProfilingApplicationsWithJikesRVM.html"></a></p>
</body></html>