Profiling & Benchmarking

Dead-code elimination is when the JVM deletes code whose result is never used. In a benchmark, if you compute something but never use the value, the JIT may delete the work, so the benchmark times nothing and reports an impossibly fast result.

@Warmup runs the code to get the JVM up to speed and throws those numbers away. @Measurement runs it again and keeps those numbers. You set how many rounds (iterations) and how long each round lasts (time).

The JVM starts running code interpreted and only compiles hot code to fast machine code after it runs many times. If you measure the first runs, you measure slow startup, not the real speed. Warmup runs the code first so the fast version is in place before timing.

A sampling profiler peeks at what the program is doing every so often and adds up where it spends most time. An instrumentation profiler adds extra code to every method to count and time every single call exactly, which is more accurate but much slower.

At launch, add the JVM flag -XX:StartFlightRecording with options like duration and filename. On a running process, use the jcmd tool: 'jcmd <pid> JFR.start', then 'JFR.dump' to write a .jfr file and 'JFR.stop' to end it.

Return the value when your benchmark produces a single result. Use a Blackhole when you produce more than one result, or a result inside a loop, calling bh.consume() on each so none of them gets deleted by the JIT.

The JVM speeds up code as it runs by compiling it. Warmup runs the code a while first so it is already fast, so you measure the fast version, not the slow startup.

If the result of your code is never used, the JIT can delete the whole computation as dead code. If inputs are constants, it can compute the answer at compile time. Either way the loop disappears and you measure nothing. Fix it by consuming the result (e.g. return it / feed it to a sink) and using non-constant inputs.

Hand-rolled timing usually lies: it forgets warmup, lets the JIT delete or constant-fold the work, gets perturbed by GC pauses, and uses timers wrong. JMH is built to handle all of that for you — warmup, preventing dead-code elimination, forking JVMs, and reporting proper statistics — so the numbers actually mean something.

Start with a low-overhead sampling profiler (like async-profiler or JFR) under realistic load to see where time actually goes, because it barely slows the app. Only switch to an instrumentation profiler if you need exact call counts or to trace one specific path, knowing it's slower and can distort results.

Constant folding is when the JIT precomputes an expression whose inputs are compile-time constants, so the benchmark never actually runs the work. Putting inputs in a non-final @State field that the JIT can't treat as constant forces the real computation to happen every time.

JFR is a profiling and event-recording tool built into the JVM. It records what your application does (allocations, GC, locks, exceptions, method samples) with very low overhead—around 1% or less—so you can safely leave it on in production.

You open the .jfr file in JDK Mission Control (JMC), a desktop app that shows automated analysis and views like CPU usage, allocations, GC, locks, and exceptions. You can also read .jfr files from the command line with 'jfr print' or programmatically with the jdk.jfr.consumer API, and define your own custom events for app-specific telemetry.

A Mode tells JMH how to express the result. Throughput counts operations per unit of time (higher is better); AverageTime is time per operation (lower is better); SampleTime samples individual call times to build a distribution including percentiles; SingleShotTime measures one run with no warmup, for cold-start cost. @OutputTimeUnit picks the unit (ms, us, ns) the score is printed in.

Add the JMH core library plus its annotation processor as dependencies. Write a method annotated with @Benchmark. At build time the annotation processor generates harness code and a runnable Main. Then you run the benchmarks by executing that generated jar (or via a Runner in code), and JMH does warmup, measurement, and forking automatically.

Sampling only does work once per timer tick (e.g. every 10 ms), no matter how busy the code is, so its cost is fixed. Instrumentation does extra work on every single method call, so the more calls there are, the more it costs.

A continuous recording runs all the time with low-overhead settings and a bounded ring buffer, so you can dump the recent history when something goes wrong. A profiling recording is a short, time-boxed session with richer events and slightly higher cost, used for a focused investigation.

JFR records typed 'events' for things like object allocation, garbage collection, lock contention, thrown exceptions, file/socket I/O, and periodic method (CPU) samples. Events go into per-thread buffers and CPU profiling uses sampling, so the overhead stays around 1%.

JMH runs each benchmark in a brand-new JVM process (a fork). This is because the JVM remembers and adapts based on what it ran before, so running two benchmarks in the same JVM lets the first one's optimization decisions affect the second's results. A fresh JVM per trial keeps each benchmark's measurement honest and independent.

A @State class holds the data your benchmark uses. Its scope says who shares one instance: Benchmark = all threads share one, Thread = each thread gets its own, Group = one per group of cooperating threads. @Setup methods prepare state before the benchmark and @TearDown cleans up after; each can run at Trial, Iteration, or Invocation level depending on how often you need it.

A loop inside a benchmark can be unrolled or partly optimized by the JIT, and repeated identical work can be folded so only one iteration really runs. Prefer letting JMH do the repetition, and if you must loop, consume each iteration's result and vary the inputs.

Each fork is a fresh JVM. JMH runs your benchmark in several separate JVMs and averages the results, because one JVM can get 'lucky' or 'unlucky' in how it compiles your code. Multiple forks smooth that out.

The score is the average result (e.g. nanoseconds per operation or ops per second). The ± number is the margin of error — how much the score could wobble. If two benchmarks' score-plus-or-minus ranges overlap, you can't claim one is faster.

Garbage collection can pause your code in the middle of timing, adding spikes that aren't part of the operation you're measuring. The JVM also pauses all threads at 'safepoints' for housekeeping. If you report only an average, these pauses get hidden or smeared; you should look at the distribution and control allocation.

Older JVM samplers can only grab a thread's stack when the thread reaches a 'safepoint' — a safe pause spot. The JIT removes safepoints from tight loops, so the sampler records the wrong place and blames safepoint-friendly methods. async-profiler avoids this by capturing the stack instantly via OS signals, no safepoint needed.

A sub-nanosecond result for real work is a red flag. Check that inputs come from non-final @State fields (not constants), that every output is returned or Blackhole-consumed, and that any loop varies its data. Then re-run, ideally inspecting the generated assembly to confirm the work runs.

If your benchmark's result isn't used, the JIT can delete it (dead-code elimination) or precompute it (constant folding) — so you'd measure nothing. JMH fixes this: return values, consume them with Blackhole, and keep inputs in @State so they aren't treated as constants.

If your benchmark sends the next request only after the previous one finishes, then when one request stalls, you simply don't send the requests that should have arrived during the stall. You record one slow sample instead of many. So your worst-case (tail) latency looks far better than what real users would see.

Adding probes to every method can stop the JIT from optimizing (especially inlining) small methods, so the profiled program runs differently from production and points you at the wrong 'hot' code. To avoid being misled, prefer low-overhead sampling, scope any instrumentation narrowly, and always validate findings against a sampled, optimized run.