author | mgerdin |
Thu, 23 Feb 2012 14:58:35 +0100 | |
changeset 12095 | cc3d6f08a4c4 |
parent 11572 | 84afef481892 |
child 13728 | 882756847a04 |
permissions | -rw-r--r-- |
8667 | 1 |
/* |
9625 | 2 |
* Copyright (c) 2010, 2011, Oracle and/or its affiliates. All rights reserved. |
3 |
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. |
|
4 |
* |
|
5 |
* This code is free software; you can redistribute it and/or modify it |
|
6 |
* under the terms of the GNU General Public License version 2 only, as |
|
7 |
* published by the Free Software Foundation. |
|
8 |
* |
|
9 |
* This code is distributed in the hope that it will be useful, but WITHOUT |
|
10 |
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or |
|
11 |
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License |
|
12 |
* version 2 for more details (a copy is included in the LICENSE file that |
|
13 |
* accompanied this code). |
|
14 |
* |
|
15 |
* You should have received a copy of the GNU General Public License version |
|
16 |
* 2 along with this work; if not, write to the Free Software Foundation, |
|
17 |
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. |
|
18 |
* |
|
19 |
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA |
|
20 |
* or visit www.oracle.com if you need additional information or have any |
|
21 |
* questions. |
|
22 |
* |
|
23 |
*/ |
|
8667 | 24 |
|
25 |
#ifndef SHARE_VM_RUNTIME_ADVANCEDTHRESHOLDPOLICY_HPP |
|
26 |
#define SHARE_VM_RUNTIME_ADVANCEDTHRESHOLDPOLICY_HPP |
|
27 |
||
28 |
#include "runtime/simpleThresholdPolicy.hpp" |
|
29 |
||
30 |
#ifdef TIERED |
|
31 |
class CompileTask; |
|
32 |
class CompileQueue; |
|
33 |
||
34 |
/* |
|
35 |
* The system supports 5 execution levels: |
|
36 |
* * level 0 - interpreter |
|
37 |
* * level 1 - C1 with full optimization (no profiling) |
|
38 |
* * level 2 - C1 with invocation and backedge counters |
|
39 |
* * level 3 - C1 with full profiling (level 2 + MDO) |
|
40 |
* * level 4 - C2 |
|
41 |
* |
|
42 |
* Levels 0, 2 and 3 periodically notify the runtime about the current value of the counters |
|
43 |
* (invocation counters and backedge counters). The frequency of these notifications is |
|
44 |
* different at each level. These notifications are used by the policy to decide what transition |
|
45 |
* to make. |
|
46 |
* |
|
47 |
* Execution starts at level 0 (interpreter), then the policy can decide either to compile the |
|
48 |
* method at level 3 or level 2. The decision is based on the following factors: |
|
49 |
* 1. The length of the C2 queue determines the next level. The observation is that level 2 |
|
50 |
* is generally faster than level 3 by about 30%, therefore we would want to minimize the time |
|
51 |
* a method spends at level 3. We should only spend the time at level 3 that is necessary to get |
|
52 |
* adequate profiling. So, if the C2 queue is long enough it is more beneficial to go first to |
|
53 |
* level 2, because if we transitioned to level 3 we would be stuck there until our C2 compile |
|
54 |
* request makes its way through the long queue. When the load on C2 recedes we are going to |
|
55 |
* recompile at level 3 and start gathering profiling information. |
|
56 |
* 2. The length of C1 queue is used to dynamically adjust the thresholds, so as to introduce |
|
57 |
* additional filtering if the compiler is overloaded. The rationale is that by the time a |
|
58 |
* method gets compiled it can become unused, so it doesn't make sense to put too much onto the |
|
59 |
* queue. |
|
60 |
* |
|
61 |
* After profiling is completed at level 3 the transition is made to level 4. Again, the length |
|
62 |
* of the C2 queue is used as a feedback to adjust the thresholds. |
|
63 |
* |
|
64 |
* After the first C1 compile some basic information is determined about the code like the number |
|
65 |
* of the blocks and the number of the loops. Based on that it can be decided that a method |
|
66 |
* is trivial and compiling it with C1 will yield the same code. In this case the method is |
|
67 |
* compiled at level 1 instead of 4. |
|
68 |
* |
|
69 |
* We also support profiling at level 0. If C1 is slow enough to produce the level 3 version of |
|
70 |
* the code and the C2 queue is sufficiently small we can decide to start profiling in the |
|
71 |
* interpreter (and continue profiling in the compiled code once the level 3 version arrives). |
|
72 |
* If the profiling at level 0 is fully completed before level 3 version is produced, a level 2 |
|
73 |
* version is compiled instead in order to run faster waiting for a level 4 version. |
|
74 |
* |
|
75 |
* Compile queues are implemented as priority queues - for each method in the queue we compute |
|
76 |
* the event rate (the number of invocation and backedge counter increments per unit of time). |
|
77 |
* When getting an element off the queue we pick the one with the largest rate. Maintaining the |
|
78 |
* rate also allows us to remove stale methods (the ones that got on the queue but stopped |
|
79 |
* being used shortly after that). |
|
80 |
*/ |
|
81 |
||
82 |
/* Command line options: |
|
83 |
* - Tier?InvokeNotifyFreqLog and Tier?BackedgeNotifyFreqLog control the frequency of method |
|
84 |
* invocation and backedge notifications. Basically every n-th invocation or backedge a mutator thread |
|
85 |
* makes a call into the runtime. |
|
86 |
* |
|
87 |
* - Tier?CompileThreshold, Tier?BackEdgeThreshold, Tier?MinInvocationThreshold control |
|
88 |
* compilation thresholds. |
|
89 |
* Level 2 thresholds are not used and are provided for option-compatibility and potential future use. |
|
90 |
* Other thresholds work as follows: |
|
91 |
* |
|
92 |
* Transition from interpreter (level 0) to C1 with full profiling (level 3) happens when |
|
93 |
* the following predicate is true (X is the level): |
|
94 |
* |
|
95 |
* i > TierXInvocationThreshold * s || (i > TierXMinInvocationThreshold * s && i + b > TierXCompileThreshold * s), |
|
96 |
* |
|
97 |
* where $i$ is the number of method invocations, $b$ number of backedges and $s$ is the scaling |
|
98 |
* coefficient that will be discussed further. |
|
99 |
* The intuition is to equalize the time that is spend profiling each method. |
|
100 |
* The same predicate is used to control the transition from level 3 to level 4 (C2). It should be |
|
101 |
* noted though that the thresholds are relative. Moreover i and b for the 0->3 transition come |
|
102 |
* from methodOop and for 3->4 transition they come from MDO (since profiled invocations are |
|
103 |
* counted separately). |
|
104 |
* |
|
105 |
* OSR transitions are controlled simply with b > TierXBackEdgeThreshold * s predicates. |
|
106 |
* |
|
107 |
* - Tier?LoadFeedback options are used to automatically scale the predicates described above depending |
|
108 |
* on the compiler load. The scaling coefficients are computed as follows: |
|
109 |
* |
|
110 |
* s = queue_size_X / (TierXLoadFeedback * compiler_count_X) + 1, |
|
111 |
* |
|
112 |
* where queue_size_X is the current size of the compiler queue of level X, and compiler_count_X |
|
113 |
* is the number of level X compiler threads. |
|
114 |
* |
|
115 |
* Basically these parameters describe how many methods should be in the compile queue |
|
116 |
* per compiler thread before the scaling coefficient increases by one. |
|
117 |
* |
|
118 |
* This feedback provides the mechanism to automatically control the flow of compilation requests |
|
119 |
* depending on the machine speed, mutator load and other external factors. |
|
120 |
* |
|
121 |
* - Tier3DelayOn and Tier3DelayOff parameters control another important feedback loop. |
|
122 |
* Consider the following observation: a method compiled with full profiling (level 3) |
|
123 |
* is about 30% slower than a method at level 2 (just invocation and backedge counters, no MDO). |
|
124 |
* Normally, the following transitions will occur: 0->3->4. The problem arises when the C2 queue |
|
125 |
* gets congested and the 3->4 transition is delayed. While the method is the C2 queue it continues |
|
126 |
* executing at level 3 for much longer time than is required by the predicate and at suboptimal speed. |
|
127 |
* The idea is to dynamically change the behavior of the system in such a way that if a substantial |
|
128 |
* load on C2 is detected we would first do the 0->2 transition allowing a method to run faster. |
|
129 |
* And then when the load decreases to allow 2->3 transitions. |
|
130 |
* |
|
131 |
* Tier3Delay* parameters control this switching mechanism. |
|
132 |
* Tier3DelayOn is the number of methods in the C2 queue per compiler thread after which the policy |
|
133 |
* no longer does 0->3 transitions but does 0->2 transitions instead. |
|
134 |
* Tier3DelayOff switches the original behavior back when the number of methods in the C2 queue |
|
135 |
* per compiler thread falls below the specified amount. |
|
136 |
* The hysteresis is necessary to avoid jitter. |
|
137 |
* |
|
138 |
* - TieredCompileTaskTimeout is the amount of time an idle method can spend in the compile queue. |
|
139 |
* Basically, since we use the event rate d(i + b)/dt as a value of priority when selecting a method to |
|
140 |
* compile from the compile queue, we also can detect stale methods for which the rate has been |
|
141 |
* 0 for some time in the same iteration. Stale methods can appear in the queue when an application |
|
142 |
* abruptly changes its behavior. |
|
143 |
* |
|
144 |
* - TieredStopAtLevel, is used mostly for testing. It allows to bypass the policy logic and stick |
|
145 |
* to a given level. For example it's useful to set TieredStopAtLevel = 1 in order to compile everything |
|
146 |
* with pure c1. |
|
147 |
* |
|
148 |
* - Tier0ProfilingStartPercentage allows the interpreter to start profiling when the inequalities in the |
|
149 |
* 0->3 predicate are already exceeded by the given percentage but the level 3 version of the |
|
150 |
* method is still not ready. We can even go directly from level 0 to 4 if c1 doesn't produce a compiled |
|
151 |
* version in time. This reduces the overall transition to level 4 and decreases the startup time. |
|
152 |
* Note that this behavior is also guarded by the Tier3Delay mechanism: when the c2 queue is too long |
|
153 |
* these is not reason to start profiling prematurely. |
|
154 |
* |
|
155 |
* - TieredRateUpdateMinTime and TieredRateUpdateMaxTime are parameters of the rate computation. |
|
156 |
* Basically, the rate is not computed more frequently than TieredRateUpdateMinTime and is considered |
|
157 |
* to be zero if no events occurred in TieredRateUpdateMaxTime. |
|
158 |
*/ |
|
159 |
||
160 |
||
161 |
class AdvancedThresholdPolicy : public SimpleThresholdPolicy { |
|
162 |
jlong _start_time; |
|
163 |
||
164 |
// Call and loop predicates determine whether a transition to a higher compilation |
|
165 |
// level should be performed (pointers to predicate functions are passed to common(). |
|
166 |
// Predicates also take compiler load into account. |
|
167 |
typedef bool (AdvancedThresholdPolicy::*Predicate)(int i, int b, CompLevel cur_level); |
|
168 |
bool call_predicate(int i, int b, CompLevel cur_level); |
|
169 |
bool loop_predicate(int i, int b, CompLevel cur_level); |
|
170 |
// Common transition function. Given a predicate determines if a method should transition to another level. |
|
10250
0794cd144834
7066339: Tiered: policy should make consistent decisions about osr levels
iveresov
parents:
10014
diff
changeset
|
171 |
CompLevel common(Predicate p, methodOop method, CompLevel cur_level, bool disable_feedback = false); |
8667 | 172 |
// Transition functions. |
173 |
// call_event determines if a method should be compiled at a different |
|
174 |
// level with a regular invocation entry. |
|
175 |
CompLevel call_event(methodOop method, CompLevel cur_level); |
|
176 |
// loop_event checks if a method should be OSR compiled at a different |
|
177 |
// level. |
|
178 |
CompLevel loop_event(methodOop method, CompLevel cur_level); |
|
179 |
// Has a method been long around? |
|
180 |
// We don't remove old methods from the compile queue even if they have |
|
181 |
// very low activity (see select_task()). |
|
182 |
inline bool is_old(methodOop method); |
|
183 |
// Was a given method inactive for a given number of milliseconds. |
|
184 |
// If it is, we would remove it from the queue (see select_task()). |
|
185 |
inline bool is_stale(jlong t, jlong timeout, methodOop m); |
|
186 |
// Compute the weight of the method for the compilation scheduling |
|
187 |
inline double weight(methodOop method); |
|
188 |
// Apply heuristics and return true if x should be compiled before y |
|
189 |
inline bool compare_methods(methodOop x, methodOop y); |
|
190 |
// Compute event rate for a given method. The rate is the number of event (invocations + backedges) |
|
191 |
// per millisecond. |
|
192 |
inline void update_rate(jlong t, methodOop m); |
|
193 |
// Compute threshold scaling coefficient |
|
194 |
inline double threshold_scale(CompLevel level, int feedback_k); |
|
195 |
// If a method is old enough and is still in the interpreter we would want to |
|
196 |
// start profiling without waiting for the compiled method to arrive. This function |
|
197 |
// determines whether we should do that. |
|
198 |
inline bool should_create_mdo(methodOop method, CompLevel cur_level); |
|
199 |
// Create MDO if necessary. |
|
11572
84afef481892
7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS
iveresov
parents:
10250
diff
changeset
|
200 |
void create_mdo(methodHandle mh, JavaThread* thread); |
8667 | 201 |
// Is method profiled enough? |
202 |
bool is_method_profiled(methodOop method); |
|
203 |
||
204 |
protected: |
|
205 |
void print_specific(EventType type, methodHandle mh, methodHandle imh, int bci, CompLevel level); |
|
206 |
||
207 |
void set_start_time(jlong t) { _start_time = t; } |
|
208 |
jlong start_time() const { return _start_time; } |
|
209 |
||
210 |
// Submit a given method for compilation (and update the rate). |
|
11572
84afef481892
7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS
iveresov
parents:
10250
diff
changeset
|
211 |
virtual void submit_compile(methodHandle mh, int bci, CompLevel level, JavaThread* thread); |
8667 | 212 |
// event() from SimpleThresholdPolicy would call these. |
213 |
virtual void method_invocation_event(methodHandle method, methodHandle inlinee, |
|
11572
84afef481892
7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS
iveresov
parents:
10250
diff
changeset
|
214 |
CompLevel level, nmethod* nm, JavaThread* thread); |
8667 | 215 |
virtual void method_back_branch_event(methodHandle method, methodHandle inlinee, |
11572
84afef481892
7131259: compile_method and CompilationPolicy::event shouldn't be declared TRAPS
iveresov
parents:
10250
diff
changeset
|
216 |
int bci, CompLevel level, nmethod* nm, JavaThread* thread); |
8667 | 217 |
public: |
218 |
AdvancedThresholdPolicy() : _start_time(0) { } |
|
219 |
// Select task is called by CompileBroker. We should return a task or NULL. |
|
220 |
virtual CompileTask* select_task(CompileQueue* compile_queue); |
|
221 |
virtual void initialize(); |
|
10014
a5c2141ee857
7057120: Tiered: Allow C1 to inline methods with loops
iveresov
parents:
9625
diff
changeset
|
222 |
virtual bool should_not_inline(ciEnv* env, ciMethod* callee); |
a5c2141ee857
7057120: Tiered: Allow C1 to inline methods with loops
iveresov
parents:
9625
diff
changeset
|
223 |
|
8667 | 224 |
}; |
225 |
||
226 |
#endif // TIERED |
|
227 |
||
228 |
#endif // SHARE_VM_RUNTIME_ADVANCEDTHRESHOLDPOLICY_HPP |