37 /*

    38  *  The system supports 5 execution levels:

    39  *  * level 0 - interpreter

    40  *  * level 1 - C1 with full optimization (no profiling)

    41  *  * level 2 - C1 with invocation and backedge counters

    42  *  * level 3 - C1 with full profiling (level 2 + MDO)

    43  *  * level 4 - C2

    44  *

    45  * Levels 0, 2 and 3 periodically notify the runtime about the current value of the counters

    46  * (invocation counters and backedge counters). The frequency of these notifications is

    47  * different at each level. These notifications are used by the policy to decide what transition

    48  * to make.

    49  *

    50  * Execution starts at level 0 (interpreter), then the policy can decide either to compile the

    51  * method at level 3 or level 2. The decision is based on the following factors:

    52  *    1. The length of the C2 queue determines the next level. The observation is that level 2

    53  * is generally faster than level 3 by about 30%, therefore we would want to minimize the time

    54  * a method spends at level 3. We should only spend the time at level 3 that is necessary to get

    55  * adequate profiling. So, if the C2 queue is long enough it is more beneficial to go first to

    56  * level 2, because if we transitioned to level 3 we would be stuck there until our C2 compile

    57  * request makes its way through the long queue. When the load on C2 recedes we are going to

    58  * recompile at level 3 and start gathering profiling information.

    59  *    2. The length of C1 queue is used to dynamically adjust the thresholds, so as to introduce

    60  * additional filtering if the compiler is overloaded. The rationale is that by the time a

    61  * method gets compiled it can become unused, so it doesn't make sense to put too much onto the

    62  * queue.

    63  *

    64  * After profiling is completed at level 3 the transition is made to level 4. Again, the length

    65  * of the C2 queue is used as a feedback to adjust the thresholds.

    66  *

    67  * After the first C1 compile some basic information is determined about the code like the number

    68  * of the blocks and the number of the loops. Based on that it can be decided that a method

    69  * is trivial and compiling it with C1 will yield the same code. In this case the method is

    70  * compiled at level 1 instead of 4.

    71  *

    72  * We also support profiling at level 0. If C1 is slow enough to produce the level 3 version of

    73  * the code and the C2 queue is sufficiently small we can decide to start profiling in the

    74  * interpreter (and continue profiling in the compiled code once the level 3 version arrives).

    75  * If the profiling at level 0 is fully completed before level 3 version is produced, a level 2

    76  * version is compiled instead in order to run faster waiting for a level 4 version.

    77  *

    78  * Compile queues are implemented as priority queues - for each method in the queue we compute

    79  * the event rate (the number of invocation and backedge counter increments per unit of time).

    80  * When getting an element off the queue we pick the one with the largest rate. Maintaining the

    81  * rate also allows us to remove stale methods (the ones that got on the queue but stopped

    82  * being used shortly after that).

    83 */

    84 

    85 /* Command line options:

    86  * - Tier?InvokeNotifyFreqLog and Tier?BackedgeNotifyFreqLog control the frequency of method

    87  *   invocation and backedge notifications. Basically every n-th invocation or backedge a mutator thread

    88  *   makes a call into the runtime.

    89  *

    90  * - Tier?InvocationThreshold, Tier?CompileThreshold, Tier?BackEdgeThreshold, Tier?MinInvocationThreshold control

    91  *   compilation thresholds.

    92  *   Level 2 thresholds are not used and are provided for option-compatibility and potential future use.

    93  *   Other thresholds work as follows:

    94  *

    95  *   Transition from interpreter (level 0) to C1 with full profiling (level 3) happens when

    96  *   the following predicate is true (X is the level):

    97  *

    98  *   i > TierXInvocationThreshold * s || (i > TierXMinInvocationThreshold * s  && i + b > TierXCompileThreshold * s),

    99  *

   100  *   where $i$ is the number of method invocations, $b$ number of backedges and $s$ is the scaling

   101  *   coefficient that will be discussed further.

   102  *   The intuition is to equalize the time that is spend profiling each method.

   103  *   The same predicate is used to control the transition from level 3 to level 4 (C2). It should be

   104  *   noted though that the thresholds are relative. Moreover i and b for the 0->3 transition come

   105  *   from Method* and for 3->4 transition they come from MDO (since profiled invocations are

   106  *   counted separately). Finally, if a method does not contain anything worth profiling, a transition

   107  *   from level 3 to level 4 occurs without considering thresholds (e.g., with fewer invocations than

   108  *   what is specified by Tier4InvocationThreshold).

   109  *

   110  *   OSR transitions are controlled simply with b > TierXBackEdgeThreshold * s predicates.

   111  *

   112  * - Tier?LoadFeedback options are used to automatically scale the predicates described above depending

   113  *   on the compiler load. The scaling coefficients are computed as follows:

   114  *

   115  *   s = queue_size_X / (TierXLoadFeedback * compiler_count_X) + 1,

   116  *

   117  *   where queue_size_X is the current size of the compiler queue of level X, and compiler_count_X

   118  *   is the number of level X compiler threads.

   119  *

   120  *   Basically these parameters describe how many methods should be in the compile queue

   121  *   per compiler thread before the scaling coefficient increases by one.

   122  *

   123  *   This feedback provides the mechanism to automatically control the flow of compilation requests

   124  *   depending on the machine speed, mutator load and other external factors.

   125  *

   126  * - Tier3DelayOn and Tier3DelayOff parameters control another important feedback loop.

   127  *   Consider the following observation: a method compiled with full profiling (level 3)

   128  *   is about 30% slower than a method at level 2 (just invocation and backedge counters, no MDO).

   129  *   Normally, the following transitions will occur: 0->3->4. The problem arises when the C2 queue

   130  *   gets congested and the 3->4 transition is delayed. While the method is the C2 queue it continues

   131  *   executing at level 3 for much longer time than is required by the predicate and at suboptimal speed.

   132  *   The idea is to dynamically change the behavior of the system in such a way that if a substantial

   133  *   load on C2 is detected we would first do the 0->2 transition allowing a method to run faster.

   134  *   And then when the load decreases to allow 2->3 transitions.

   135  *

   136  *   Tier3Delay* parameters control this switching mechanism.

   137  *   Tier3DelayOn is the number of methods in the C2 queue per compiler thread after which the policy

   138  *   no longer does 0->3 transitions but does 0->2 transitions instead.

   139  *   Tier3DelayOff switches the original behavior back when the number of methods in the C2 queue

   140  *   per compiler thread falls below the specified amount.

   141  *   The hysteresis is necessary to avoid jitter.

   142  *

   143  * - TieredCompileTaskTimeout is the amount of time an idle method can spend in the compile queue.

   144  *   Basically, since we use the event rate d(i + b)/dt as a value of priority when selecting a method to

   145  *   compile from the compile queue, we also can detect stale methods for which the rate has been

   146  *   0 for some time in the same iteration. Stale methods can appear in the queue when an application

   147  *   abruptly changes its behavior.

   148  *

   149  * - TieredStopAtLevel, is used mostly for testing. It allows to bypass the policy logic and stick

   150  *   to a given level. For example it's useful to set TieredStopAtLevel = 1 in order to compile everything

   151  *   with pure c1.

   152  *

   153  * - Tier0ProfilingStartPercentage allows the interpreter to start profiling when the inequalities in the

   154  *   0->3 predicate are already exceeded by the given percentage but the level 3 version of the

   155  *   method is still not ready. We can even go directly from level 0 to 4 if c1 doesn't produce a compiled

   156  *   version in time. This reduces the overall transition to level 4 and decreases the startup time.

   157  *   Note that this behavior is also guarded by the Tier3Delay mechanism: when the c2 queue is too long

   158  *   these is not reason to start profiling prematurely.

   159  *

   160  * - TieredRateUpdateMinTime and TieredRateUpdateMaxTime are parameters of the rate computation.

   161  *   Basically, the rate is not computed more frequently than TieredRateUpdateMinTime and is considered

   162  *   to be zero if no events occurred in TieredRateUpdateMaxTime.

   163  */

   166   jlong _start_time;

   189   // Has a method been long around?

   190   // We don't remove old methods from the compile queue even if they have

   191   // very low activity (see select_task()).

   192   inline bool is_old(Method* method);

   193   // Was a given method inactive for a given number of milliseconds.

   194   // If it is, we would remove it from the queue (see select_task()).

   195   inline bool is_stale(jlong t, jlong timeout, Method* m);

   196   // Compute the weight of the method for the compilation scheduling

   197   inline double weight(Method* method);

   198   // Apply heuristics and return true if x should be compiled before y

   199   inline bool compare_methods(Method* x, Method* y);

   200   // Compute event rate for a given method. The rate is the number of event (invocations + backedges)

   201   // per millisecond.

   202   inline void update_rate(jlong t, Method* m);

   203   // Compute threshold scaling coefficient

   204   inline double threshold_scale(CompLevel level, int feedback_k);

   205   // If a method is old enough and is still in the interpreter we would want to

   206   // start profiling without waiting for the compiled method to arrive. This function

   207   // determines whether we should do that.

   208   inline bool should_create_mdo(Method* method, CompLevel cur_level);

   209   // Create MDO if necessary.

   210   void create_mdo(const methodHandle& mh, JavaThread* thread);

   211   // Is method profiled enough?

   212   bool is_method_profiled(Method* method);

   213 

   214   double _increase_threshold_at_ratio;

   215 

   216   bool maybe_switch_to_aot(const methodHandle& mh, CompLevel cur_level, CompLevel next_level, JavaThread* thread);

   217 

   247 

   248   void set_increase_threshold_at_ratio() { _increase_threshold_at_ratio = 100 / (100 - (double)IncreaseFirstTierCompileThresholdAt); }

   249   void set_start_time(jlong t) { _start_time = t;    }

   250   jlong start_time() const     { return _start_time; }

   251