HotSpot decides which bytecode to compile using two per-method counters. Name them, explain why one is not enough, and describe what the runtime does when a counter crosses its threshold.

## The two counters HotSpot attaches profiling state to each method (in the method's metadata / MethodData structures). Two of those values drive compilation decisions: - **Invocation counter** - incremented in the interpreter's method entry sequence. It measures how often the method is *called*. - **Back-edge counter** - incremented on every *backward branch* in the bytecode. A `for`/`while`/`do` loop compiles to a conditional branch that jumps backwards to the loop head, so this counter effectively counts loop iterations, including iterations of loops nested inside the method. At lower optimization levels the same counters are also maintained by compiled code, so a method compiled cheaply can still be observed and promoted later. ## Why both are necessary Hotness is 'where the process spends its time', and there are two ways to accumulate time. Call-heavy code (a getter, a hash function, a parser step) accumulates it across many short invocations. Loop-heavy code accumulates it inside one invocation - the classic case being a `main` method with a single long-running loop, or a batch job that never returns until it is done. If the runtime counted only invocations, the loop-heavy shape would run interpreted forever, which was exactly the motivation for adding back-edge counting and OSR. ## What overflow actually does The counters are not compared against the threshold on every increment by expensive means; the interpreter uses cheap checks (in modern tiered mode, notification points chosen so the check happens periodically, controlled by flags such as `-XX:Tier0InvokeNotifyFreqLog` and `-XX:Tier0BackedgeNotifyFreqLog`). When a check indicates the threshold is crossed, control enters the runtime, which consults the compilation policy and typically **enqueues a compile task**: - Invocation-counter overflow requests a **standard compilation**: an nmethod entered at the method's normal entry point, used by future calls. - Back-edge-counter overflow requests an **OSR compilation** keyed to `(method, bytecode index of the loop back-edge)`: an nmethod entered in the middle of the method, so the already-running invocation can be transferred into it. Compilation happens on background compiler threads. The requesting thread does not wait; it continues in the interpreter (or in the currently running code) until the compiled version is installed. This keeps a compilation storm from turning into an application stall, at the cost of the application running unoptimized a little longer. ## Thresholds are a rate signal, not a lifetime total A naive reading of a flag like `-XX:CompileThreshold=10000` is 'the 10,000th call triggers compilation'. Two things complicate that. First, HotSpot historically **decayed** counters at safepoints, so counts that accumulate very slowly can be aged away and never reach the threshold - the threshold then effectively measures *frequency*, not lifetime total. Second, the modern tiered policy does not use a single raw threshold at all: it combines invocation and back-edge counts with the observed invocation *rate* and the current length of the compile queue, so a method under heavy load is promoted sooner than one dribbling along. The practical consequence is real: a lightly exercised service can stay interpreted far longer than a naive count would predict, and warm-up depends on load, not just on elapsed time. ## Observing it Compilation events are visible with `-XX:+PrintCompilation`, which prints one line per installed nmethod; OSR compilations are distinguished in that output (an `%` marker and the bytecode index at which the loop was entered). This is the usual way to confirm that the hot method you care about actually got compiled, and whether it arrived by the normal path or by OSR.