Why Java’s JIT Compiler Matters: How HotSpot Optimizes Your Code

JIT Compiler Overview

In HotSpot JVM, bytecode is first executed by the interpreter. When a method or a loop is executed frequently, the VM marks it as hot and compiles it to native code using a Just‑In‑Time (JIT) compiler. The JIT runs several optimization passes before emitting machine code.

Interpreter and JIT Coexistence

Most commercial JVMs contain both an interpreter and a JIT compiler. The interpreter provides fast start‑up and low memory usage; the JIT provides higher throughput for hot code. The VM switches dynamically: rare paths stay interpreted, hot paths are compiled.

HotSpot’s Two JIT Compilers

HotSpot ships with two compilers:

C1 (client compiler) – optimized for fast compilation, suitable for client‑side workloads.

C2 (server compiler) – performs more aggressive optimizations and produces higher‑quality code, used for server workloads.

The default compiler is chosen by the VM mode and can be forced with -client or -server. Mixed mode (interpreter + one compiler) is the default. Pure interpretation is enabled with -Xint; pure compilation (compile‑as‑soon‑as‑possible) with -Xcomp. The flag -XX:+PrintCompilation prints compilation events.

Hot Spot Detection

HotSpot decides whether code is hot by two mechanisms:

Sample‑based detection : a background thread periodically samples the top of each Java thread’s stack. Methods that appear frequently are considered hot.

Counter‑based detection : each method (and each back‑edge of a loop) has a counter that is incremented on entry. When the counter exceeds a threshold the method is queued for compilation.

Two counters are used:

Method‑call counter . Default thresholds are 1500 invocations in client mode and 10000 in server mode. The threshold can be changed with -XX:CompileThreshold. The counter decays over time (half‑life) during GC; the half‑life can be configured with -XX:CounterHalfLifeTime.

Back‑edge counter (used for on‑stack replacement, OSR) . Its effective threshold is derived from -XX:BackEdgeThreshold or indirectly from -XX:OnStackReplacePercentage. For example, in client mode the OSR threshold ≈ CompileThreshold × OnStackReplacePercentage / 100 (default 933 %). In server mode the formula also subtracts InterpreterProfilePercentage (default 33 %).

Performance Comparison of Execution Modes

The following micro‑benchmark loops ten million random numbers and measures elapsed time.

public class JitTest {
    private static final java.util.Random random = new java.util.Random();
    private static final int NUMS = 99_999_999;
    public static void main(String[] args) {
        long start = System.currentTimeMillis();
        int count = 0;
        for (int i = 0; i < NUMS; i++) {
            count += random.nextInt(10);
        }
        System.out.println("count: " + count + ", time cost: " + (System.currentTimeMillis() - start));
    }
}

Results on a typical x86‑64 machine:

Pure interpretation ( -Xint -XX:+PrintCompilation) – ~34 s, no compilation logs.

Pure compilation ( -Xcomp -XX:+PrintCompilation) – ~10.6 s, many compilation logs.

Mixed mode (default, -XX:+PrintCompilation) – <1 s, compilation logs appear for hot methods.

The ordering confirms that JIT dramatically speeds up hot code while the interpreter remains useful for cold paths.

Key JIT Optimizations

When generating native code HotSpot applies a large set of optimizations, including:

Common Sub‑Expression Elimination (CSE) – reuses previously computed expression results when operands have not changed.

Array Bounds Check Elimination – removes redundant bounds checks after data‑flow analysis proves safety.

Method Inlining – copies the callee’s bytecode into the caller, eliminating call overhead and exposing further optimization opportunities.

Escape Analysis – determines whether an object can be accessed outside the current method or thread. When an object does not escape, the following optimizations are possible:

Stack allocation of the object.

Lock elimination for objects that are never accessed by other threads.

Scalar replacement – the object is broken into its fields, allowing each field to be treated as a separate scalar variable.

Additional optimizations are listed in the OpenJDK performance tactics index: https://wiki.openjdk.java.net/display/hotspot/performancetacticindex

References

《深入理解Java虚拟机》

https://blog.csdn.net/riemann_/article/details/104104967

https://www.jianshu.com/p/fbced5b34eff