src/share/vm/runtime/advancedThresholdPolicy.hpp

changeset 0
f90c822e73f8
child 6876
710a3c8b516e
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/src/share/vm/runtime/advancedThresholdPolicy.hpp	Wed Apr 27 01:25:04 2016 +0800
     1.3 @@ -0,0 +1,231 @@
     1.4 +/*
     1.5 + * Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved.
     1.6 + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
     1.7 + *
     1.8 + * This code is free software; you can redistribute it and/or modify it
     1.9 + * under the terms of the GNU General Public License version 2 only, as
    1.10 + * published by the Free Software Foundation.
    1.11 + *
    1.12 + * This code is distributed in the hope that it will be useful, but WITHOUT
    1.13 + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
    1.14 + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
    1.15 + * version 2 for more details (a copy is included in the LICENSE file that
    1.16 + * accompanied this code).
    1.17 + *
    1.18 + * You should have received a copy of the GNU General Public License version
    1.19 + * 2 along with this work; if not, write to the Free Software Foundation,
    1.20 + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
    1.21 + *
    1.22 + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
    1.23 + * or visit www.oracle.com if you need additional information or have any
    1.24 + * questions.
    1.25 + *
    1.26 + */
    1.27 +
    1.28 +#ifndef SHARE_VM_RUNTIME_ADVANCEDTHRESHOLDPOLICY_HPP
    1.29 +#define SHARE_VM_RUNTIME_ADVANCEDTHRESHOLDPOLICY_HPP
    1.30 +
    1.31 +#include "runtime/simpleThresholdPolicy.hpp"
    1.32 +
    1.33 +#ifdef TIERED
    1.34 +class CompileTask;
    1.35 +class CompileQueue;
    1.36 +
    1.37 +/*
    1.38 + *  The system supports 5 execution levels:
    1.39 + *  * level 0 - interpreter
    1.40 + *  * level 1 - C1 with full optimization (no profiling)
    1.41 + *  * level 2 - C1 with invocation and backedge counters
    1.42 + *  * level 3 - C1 with full profiling (level 2 + MDO)
    1.43 + *  * level 4 - C2
    1.44 + *
    1.45 + * Levels 0, 2 and 3 periodically notify the runtime about the current value of the counters
    1.46 + * (invocation counters and backedge counters). The frequency of these notifications is
    1.47 + * different at each level. These notifications are used by the policy to decide what transition
    1.48 + * to make.
    1.49 + *
    1.50 + * Execution starts at level 0 (interpreter), then the policy can decide either to compile the
    1.51 + * method at level 3 or level 2. The decision is based on the following factors:
    1.52 + *    1. The length of the C2 queue determines the next level. The observation is that level 2
    1.53 + * is generally faster than level 3 by about 30%, therefore we would want to minimize the time
    1.54 + * a method spends at level 3. We should only spend the time at level 3 that is necessary to get
    1.55 + * adequate profiling. So, if the C2 queue is long enough it is more beneficial to go first to
    1.56 + * level 2, because if we transitioned to level 3 we would be stuck there until our C2 compile
    1.57 + * request makes its way through the long queue. When the load on C2 recedes we are going to
    1.58 + * recompile at level 3 and start gathering profiling information.
    1.59 + *    2. The length of C1 queue is used to dynamically adjust the thresholds, so as to introduce
    1.60 + * additional filtering if the compiler is overloaded. The rationale is that by the time a
    1.61 + * method gets compiled it can become unused, so it doesn't make sense to put too much onto the
    1.62 + * queue.
    1.63 + *
    1.64 + * After profiling is completed at level 3 the transition is made to level 4. Again, the length
    1.65 + * of the C2 queue is used as a feedback to adjust the thresholds.
    1.66 + *
    1.67 + * After the first C1 compile some basic information is determined about the code like the number
    1.68 + * of the blocks and the number of the loops. Based on that it can be decided that a method
    1.69 + * is trivial and compiling it with C1 will yield the same code. In this case the method is
    1.70 + * compiled at level 1 instead of 4.
    1.71 + *
    1.72 + * We also support profiling at level 0. If C1 is slow enough to produce the level 3 version of
    1.73 + * the code and the C2 queue is sufficiently small we can decide to start profiling in the
    1.74 + * interpreter (and continue profiling in the compiled code once the level 3 version arrives).
    1.75 + * If the profiling at level 0 is fully completed before level 3 version is produced, a level 2
    1.76 + * version is compiled instead in order to run faster waiting for a level 4 version.
    1.77 + *
    1.78 + * Compile queues are implemented as priority queues - for each method in the queue we compute
    1.79 + * the event rate (the number of invocation and backedge counter increments per unit of time).
    1.80 + * When getting an element off the queue we pick the one with the largest rate. Maintaining the
    1.81 + * rate also allows us to remove stale methods (the ones that got on the queue but stopped
    1.82 + * being used shortly after that).
    1.83 +*/
    1.84 +
    1.85 +/* Command line options:
    1.86 + * - Tier?InvokeNotifyFreqLog and Tier?BackedgeNotifyFreqLog control the frequency of method
    1.87 + *   invocation and backedge notifications. Basically every n-th invocation or backedge a mutator thread
    1.88 + *   makes a call into the runtime.
    1.89 + *
    1.90 + * - Tier?CompileThreshold, Tier?BackEdgeThreshold, Tier?MinInvocationThreshold control
    1.91 + *   compilation thresholds.
    1.92 + *   Level 2 thresholds are not used and are provided for option-compatibility and potential future use.
    1.93 + *   Other thresholds work as follows:
    1.94 + *
    1.95 + *   Transition from interpreter (level 0) to C1 with full profiling (level 3) happens when
    1.96 + *   the following predicate is true (X is the level):
    1.97 + *
    1.98 + *   i > TierXInvocationThreshold * s || (i > TierXMinInvocationThreshold * s  && i + b > TierXCompileThreshold * s),
    1.99 + *
   1.100 + *   where $i$ is the number of method invocations, $b$ number of backedges and $s$ is the scaling
   1.101 + *   coefficient that will be discussed further.
   1.102 + *   The intuition is to equalize the time that is spend profiling each method.
   1.103 + *   The same predicate is used to control the transition from level 3 to level 4 (C2). It should be
   1.104 + *   noted though that the thresholds are relative. Moreover i and b for the 0->3 transition come
   1.105 + *   from Method* and for 3->4 transition they come from MDO (since profiled invocations are
   1.106 + *   counted separately).
   1.107 + *
   1.108 + *   OSR transitions are controlled simply with b > TierXBackEdgeThreshold * s predicates.
   1.109 + *
   1.110 + * - Tier?LoadFeedback options are used to automatically scale the predicates described above depending
   1.111 + *   on the compiler load. The scaling coefficients are computed as follows:
   1.112 + *
   1.113 + *   s = queue_size_X / (TierXLoadFeedback * compiler_count_X) + 1,
   1.114 + *
   1.115 + *   where queue_size_X is the current size of the compiler queue of level X, and compiler_count_X
   1.116 + *   is the number of level X compiler threads.
   1.117 + *
   1.118 + *   Basically these parameters describe how many methods should be in the compile queue
   1.119 + *   per compiler thread before the scaling coefficient increases by one.
   1.120 + *
   1.121 + *   This feedback provides the mechanism to automatically control the flow of compilation requests
   1.122 + *   depending on the machine speed, mutator load and other external factors.
   1.123 + *
   1.124 + * - Tier3DelayOn and Tier3DelayOff parameters control another important feedback loop.
   1.125 + *   Consider the following observation: a method compiled with full profiling (level 3)
   1.126 + *   is about 30% slower than a method at level 2 (just invocation and backedge counters, no MDO).
   1.127 + *   Normally, the following transitions will occur: 0->3->4. The problem arises when the C2 queue
   1.128 + *   gets congested and the 3->4 transition is delayed. While the method is the C2 queue it continues
   1.129 + *   executing at level 3 for much longer time than is required by the predicate and at suboptimal speed.
   1.130 + *   The idea is to dynamically change the behavior of the system in such a way that if a substantial
   1.131 + *   load on C2 is detected we would first do the 0->2 transition allowing a method to run faster.
   1.132 + *   And then when the load decreases to allow 2->3 transitions.
   1.133 + *
   1.134 + *   Tier3Delay* parameters control this switching mechanism.
   1.135 + *   Tier3DelayOn is the number of methods in the C2 queue per compiler thread after which the policy
   1.136 + *   no longer does 0->3 transitions but does 0->2 transitions instead.
   1.137 + *   Tier3DelayOff switches the original behavior back when the number of methods in the C2 queue
   1.138 + *   per compiler thread falls below the specified amount.
   1.139 + *   The hysteresis is necessary to avoid jitter.
   1.140 + *
   1.141 + * - TieredCompileTaskTimeout is the amount of time an idle method can spend in the compile queue.
   1.142 + *   Basically, since we use the event rate d(i + b)/dt as a value of priority when selecting a method to
   1.143 + *   compile from the compile queue, we also can detect stale methods for which the rate has been
   1.144 + *   0 for some time in the same iteration. Stale methods can appear in the queue when an application
   1.145 + *   abruptly changes its behavior.
   1.146 + *
   1.147 + * - TieredStopAtLevel, is used mostly for testing. It allows to bypass the policy logic and stick
   1.148 + *   to a given level. For example it's useful to set TieredStopAtLevel = 1 in order to compile everything
   1.149 + *   with pure c1.
   1.150 + *
   1.151 + * - Tier0ProfilingStartPercentage allows the interpreter to start profiling when the inequalities in the
   1.152 + *   0->3 predicate are already exceeded by the given percentage but the level 3 version of the
   1.153 + *   method is still not ready. We can even go directly from level 0 to 4 if c1 doesn't produce a compiled
   1.154 + *   version in time. This reduces the overall transition to level 4 and decreases the startup time.
   1.155 + *   Note that this behavior is also guarded by the Tier3Delay mechanism: when the c2 queue is too long
   1.156 + *   these is not reason to start profiling prematurely.
   1.157 + *
   1.158 + * - TieredRateUpdateMinTime and TieredRateUpdateMaxTime are parameters of the rate computation.
   1.159 + *   Basically, the rate is not computed more frequently than TieredRateUpdateMinTime and is considered
   1.160 + *   to be zero if no events occurred in TieredRateUpdateMaxTime.
   1.161 + */
   1.162 +
   1.163 +
   1.164 +class AdvancedThresholdPolicy : public SimpleThresholdPolicy {
   1.165 +  jlong _start_time;
   1.166 +
   1.167 +  // Call and loop predicates determine whether a transition to a higher compilation
   1.168 +  // level should be performed (pointers to predicate functions are passed to common().
   1.169 +  // Predicates also take compiler load into account.
   1.170 +  typedef bool (AdvancedThresholdPolicy::*Predicate)(int i, int b, CompLevel cur_level);
   1.171 +  bool call_predicate(int i, int b, CompLevel cur_level);
   1.172 +  bool loop_predicate(int i, int b, CompLevel cur_level);
   1.173 +  // Common transition function. Given a predicate determines if a method should transition to another level.
   1.174 +  CompLevel common(Predicate p, Method* method, CompLevel cur_level, bool disable_feedback = false);
   1.175 +  // Transition functions.
   1.176 +  // call_event determines if a method should be compiled at a different
   1.177 +  // level with a regular invocation entry.
   1.178 +  CompLevel call_event(Method* method, CompLevel cur_level);
   1.179 +  // loop_event checks if a method should be OSR compiled at a different
   1.180 +  // level.
   1.181 +  CompLevel loop_event(Method* method, CompLevel cur_level);
   1.182 +  // Has a method been long around?
   1.183 +  // We don't remove old methods from the compile queue even if they have
   1.184 +  // very low activity (see select_task()).
   1.185 +  inline bool is_old(Method* method);
   1.186 +  // Was a given method inactive for a given number of milliseconds.
   1.187 +  // If it is, we would remove it from the queue (see select_task()).
   1.188 +  inline bool is_stale(jlong t, jlong timeout, Method* m);
   1.189 +  // Compute the weight of the method for the compilation scheduling
   1.190 +  inline double weight(Method* method);
   1.191 +  // Apply heuristics and return true if x should be compiled before y
   1.192 +  inline bool compare_methods(Method* x, Method* y);
   1.193 +  // Compute event rate for a given method. The rate is the number of event (invocations + backedges)
   1.194 +  // per millisecond.
   1.195 +  inline void update_rate(jlong t, Method* m);
   1.196 +  // Compute threshold scaling coefficient
   1.197 +  inline double threshold_scale(CompLevel level, int feedback_k);
   1.198 +  // If a method is old enough and is still in the interpreter we would want to
   1.199 +  // start profiling without waiting for the compiled method to arrive. This function
   1.200 +  // determines whether we should do that.
   1.201 +  inline bool should_create_mdo(Method* method, CompLevel cur_level);
   1.202 +  // Create MDO if necessary.
   1.203 +  void create_mdo(methodHandle mh, JavaThread* thread);
   1.204 +  // Is method profiled enough?
   1.205 +  bool is_method_profiled(Method* method);
   1.206 +
   1.207 +  double _increase_threshold_at_ratio;
   1.208 +
   1.209 +protected:
   1.210 +  void print_specific(EventType type, methodHandle mh, methodHandle imh, int bci, CompLevel level);
   1.211 +
   1.212 +  void set_increase_threshold_at_ratio() { _increase_threshold_at_ratio = 100 / (100 - (double)IncreaseFirstTierCompileThresholdAt); }
   1.213 +  void set_start_time(jlong t) { _start_time = t;    }
   1.214 +  jlong start_time() const     { return _start_time; }
   1.215 +
   1.216 +  // Submit a given method for compilation (and update the rate).
   1.217 +  virtual void submit_compile(methodHandle mh, int bci, CompLevel level, JavaThread* thread);
   1.218 +  // event() from SimpleThresholdPolicy would call these.
   1.219 +  virtual void method_invocation_event(methodHandle method, methodHandle inlinee,
   1.220 +                                       CompLevel level, nmethod* nm, JavaThread* thread);
   1.221 +  virtual void method_back_branch_event(methodHandle method, methodHandle inlinee,
   1.222 +                                        int bci, CompLevel level, nmethod* nm, JavaThread* thread);
   1.223 +public:
   1.224 +  AdvancedThresholdPolicy() : _start_time(0) { }
   1.225 +  // Select task is called by CompileBroker. We should return a task or NULL.
   1.226 +  virtual CompileTask* select_task(CompileQueue* compile_queue);
   1.227 +  virtual void initialize();
   1.228 +  virtual bool should_not_inline(ciEnv* env, ciMethod* callee);
   1.229 +
   1.230 +};
   1.231 +
   1.232 +#endif // TIERED
   1.233 +
   1.234 +#endif // SHARE_VM_RUNTIME_ADVANCEDTHRESHOLDPOLICY_HPP

mercurial