You inherit a JMH benchmark reporting 0.3 ns/op for a non-trivial computation. How do you systematically audit whether the JIT optimized the work away?

## Why 0.3 ns/op is suspicious On modern hardware a single nanosecond is a few cycles. Sub-nanosecond per-op times are plausible only for the very cheapest operations (a trivial add). For anything non-trivial — a hash, a `Math` call, an allocation, a map lookup — a sub-nanosecond result almost always means the **JIT** (the JVM's runtime optimizing compiler) deleted or precomputed the work. Treat the number as guilty until proven innocent. ## The three traps to rule out **1. Constant folding (inputs).** If the inputs are compile-time constants — literals, or `static final` / final-with-constant fields — the JIT computes the expression once at compile time and the benchmark returns a precomputed value. *Fix/verify:* inputs must be read from **mutable instance fields of a `@State` object** so the value is a heap load the compiler cannot prove constant. **2. Dead-code elimination (outputs).** A result that is never observed is dead code and gets deleted. *Fix/verify:* every result must be **returned** (JMH consumes the return) or passed to **`Blackhole.consume()`**. Discarded locals, fields written but never read, or only-the-last-iteration-kept loops all leak work to DCE. **3. Loop effects.** A manual loop can be unrolled, have invariant work hoisted out, or — if iterations are identical — folded to one. *Fix/verify:* prefer no manual loop (JMH repeats for you); if a loop is needed, vary data from a `@State` array, consume each result, and use `@OperationsPerInvocation` to normalize. ## A systematic audit procedure 1. **Read the code against the three traps.** Where do inputs come from? Are they constant? Where do outputs go? Are they consumed? Is there a loop, and does it vary data and consume each result? 2. **Baseline comparison.** Add or run an empty/`return constant` benchmark. If the suspect benchmark matches that baseline, the real work was eliminated. 3. **Read JMH's warnings.** JMH prints heuristic warnings like 'the benchmark may have been optimized away' or about constant inputs — heed them. 4. **Sanity-check magnitude.** Estimate the expected cost from first principles (cache misses, allocations, syscalls). If the measured number is orders of magnitude smaller, suspect elimination. 5. **Inspect the generated assembly (the definitive check).** Run with `-prof perfasm` (Linux) or `-XX:+PrintAssembly` / the JMH `-prof dtraceasm`/`perfasm` profilers to see the compiled native code. If the instructions implementing the computation are absent, the JIT removed them; if present and hot, the measurement is real. 6. **Re-validate after fixes.** Apply the @State-input and consume-output corrections, re-run, and confirm the score moves to a physically plausible magnitude and that the assembly now contains the work. ## Why code review alone is not enough The JIT's behavior depends on inlining decisions, JVM version, and whether compiler blackholes are available, so a benchmark that *looks* correct can still be partly optimized in a specific environment. The assembly/profiler check is the ground truth: it tells you what actually executed, independent of your assumptions. A principal-level engineer treats benchmark numbers as claims that must be falsified, not facts. ## Governance angle Beyond the single benchmark, the takeaway is process: require @State inputs, consumed outputs, plausibility checks against a baseline, and occasional assembly verification as standard practice, so the whole team's performance numbers are trustworthy and decisions (which is faster, did this change help) rest on real measurements.