src/share/vm/runtime/advancedThresholdPolicy.hpp

Tue, 26 Apr 2011 14:04:43 -0400

author
coleenp
date
Tue, 26 Apr 2011 14:04:43 -0400
changeset 2804
01147d8aac1d
parent 2630
5d8f5a6dced7
child 2890
97b64f73103b
permissions
-rw-r--r--

7009923: JSR 292: VM crash in JavaThread::last_frame
Summary: Handle stack overflow before the first frame is called, by printing out the called method and not walking the stack.
Reviewed-by: dholmes, phh, dsamersoff

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

mercurial