How can the JIT compiler make a Java microbenchmark report a near-zero time for work that genuinely runs, and how do you prevent it?

## The compiler's contract An optimizing compiler is allowed to transform your program in any way that does not change its **observable behavior** — the outputs, side effects, and exceptions a program is *defined* to produce. It is *not* obligated to actually run computations whose results no one observes. In a real program this is a feature. In a benchmark it's a trap, because the *only* thing you care about — how long the work takes — is **not** observable behavior the compiler must preserve. ## Pitfall 1: Dead-Code Elimination (DCE) **Dead code** is code whose results are never used. Consider: ```java for (int i = 0; i < N; i++) { Math.sqrt(i); // result thrown away } ``` The return value of `Math.sqrt` is discarded, and `Math.sqrt` has no side effects. The C2 JIT proves the loop body is observably useless and **deletes it entirely** — you end up timing an *empty* loop, then possibly deleting that too. The benchmark reports a near-zero time for an operation that, run for real, costs many nanoseconds. The lie is in the *direction that flatters you*: it says the code is infinitely fast. ## Pitfall 2: Constant Folding **Constant folding** evaluates expressions whose inputs are known at compile time. If you write: ```java int x = 42; for (int i = 0; i < N; i++) { result = expensiveHash(x); // x is always 42 } ``` The compiler can compute `expensiveHash(42)` *once* (or even at compile time) and reuse it, because the input never varies — this is **loop-invariant code motion** (hoisting work that doesn't depend on the loop variable out of the loop). Again: the per-iteration cost you wanted to measure evaporates. ## Why these are so dangerous Both optimizations are *correct* and *desirable* in production — that's the point. They only "lie" because the benchmark's intent (measure the cost of doing the work N times) isn't expressed in a way the compiler must respect. And they're invisible: the code looks like it's doing work, the benchmark runs, it prints a number. The number is just meaningless. ## The fixes **1. Make the result observable (defeat DCE).** Ensure each computed value is *used* in a way the compiler can't prove is useless: - Return it from the benchmark method (the harness consumes returned values). - Feed it to a **sink** the compiler can't see through. JMH provides `Blackhole.consume(value)`, which is engineered so the JIT cannot eliminate it but it also doesn't add meaningful overhead or dead-store-eliminate. - Accumulate into a field that is later read. **2. Make inputs non-constant (defeat constant folding / hoisting).** Read inputs from state the JIT must treat as runtime-variable — in JMH, `@State` object fields. Don't hardcode literals into the hot expression; the compiler treats fields loaded each iteration as unknown values, so it can't fold them. **3. Watch for accidental loop-invariance.** If the work genuinely doesn't depend on the loop index, the compiler will hoist it. Vary the input per iteration (or per invocation) so each iteration is real work. ## Why a harness exists Getting a sink that the JIT can't optimize through — *without* the sink itself dominating the measurement or being dead-store-eliminated — is genuinely hard; it took the JMH authors deep JIT knowledge to build `Blackhole`. Likewise, `@State` exists precisely so inputs aren't seen as constants. This is the central reason you use JMH instead of hand-rolled timing: it makes "the work actually happened and the compiler couldn't cheat" the default. ## A concrete tell If a benchmark reports that an obviously non-trivial operation takes a fraction of a nanosecond, or that two clearly different implementations have *identical* times, suspect DCE or constant folding — the compiler likely deleted the work.