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