What loop optimizations does the JVM's JIT compiler perform automatically — loop unrolling, range-check (bounds-check) elimination — and why does that mean you usually shouldn't hand-unroll loops in Java?

## Background: how Java code actually executes Java source compiles to **bytecode**, a portable instruction set the **JVM** runs. The JVM first **interprets** bytecode (reads and executes it one instruction at a time — flexible but slow). The JVM watches which methods and loops run a lot ('**hot**' code) and hands them to the **JIT** (**Just-In-Time**) **compiler**, which translates them into native machine code for your actual CPU. HotSpot has two JIT compilers, **C1** (fast to compile, light optimization) and **C2** (slower to compile, aggressive optimization); **Graal** is an alternative. This 'compile only what's hot, using runtime information' approach is why a warmed-up Java loop can rival C. ## Loop unrolling A naive loop pays overhead every iteration: test the condition, increment the counter, jump back. **Loop unrolling** rewrites the loop so the body runs several times per iteration, e.g. conceptually: ```text for (i=0; i<n; i++) body(i); // unrolled by 4: for (i=0; i+3<n; i+=4) { body(i); body(i+1); body(i+2); body(i+3); } // + a small cleanup loop for the leftover elements ``` Why it helps: (1) **fewer test/increment/jump instructions per element** (less loop overhead); (2) **more instruction-level parallelism** — independent copies of the body can execute on the CPU's multiple execution units at once; (3) it **enables vectorization (SIMD)** — the JIT can fold the unrolled scalar operations into single instructions that process 4/8/16 elements at a time. The JIT chooses an unroll factor suited to the CPU and the loop, and emits the cleanup ('post') loop for the remainder. ## Range-check (bounds-check) elimination The Java Language Specification requires that **every array access is bounds-checked**: `a[i]` must throw `ArrayIndexOutOfBoundsException` if `i < 0 || i >= a.length`. Done literally, that's a comparison on **every** access — pure overhead in a tight loop. The JIT performs **range-check elimination (RCE)** (a.k.a. bounds-check elimination): when it can **prove** the index stays in range for the whole loop — e.g. a counted loop `for (int i = 0; i < a.length; i++)` clearly keeps `i` within `[0, a.length)` — it **removes the per-iteration check** (often by checking once before the loop, or by splitting off the safe range). The Java *semantics* are preserved (an out-of-range access still throws), but the *cost* is gone in the hot path. This is a big reason idiomatic counted loops over `array.length` are fast: that exact shape is the one the JIT can most easily prove safe. ## Why you usually should NOT hand-unroll in Java 1. **The JIT already does it**, tuned to the runtime CPU and profile — better than a fixed factor you bake in. 2. **Manual unrolling can defeat the JIT.** The optimizer pattern-matches canonical loop shapes; a hand-unrolled, cluttered loop may no longer match, so the JIT **stops** unrolling/vectorizing it — you end up slower. 3. **It hurts readability and correctness.** Manual unrolling adds index arithmetic and a remainder loop — easy to get off-by-one bugs. 4. **The right factor is hardware-specific** and changes across CPUs/JVM versions; a hardcoded one ages badly. 5. **It's premature.** Per Knuth, optimize after measuring. Most loops aren't the bottleneck. ## What to do instead - Write a **simple counted loop**, ideally `for (int i = 0; i < array.length; i++)` (or an enhanced-for) — the shape the JIT recognizes for RCE and unrolling. - Keep the body **simple and side-effect-light** so the JIT can analyze it. - **Warm up** before benchmarking (the first runs are interpreted/compiling); use JMH so you measure compiled, steady-state code, not interpreter time. - Hand-tune (or reach for the Vector API) **only after a profiler** proves a specific loop dominates. ## Key terms recap - **Bytecode / JVM / interpreter:** portable instructions, the runtime, and the slow one-at-a-time executor. - **JIT (C1/C2/Graal):** compiles hot code to native using runtime profiles. - **Loop unrolling:** running the body multiple times per iteration to cut overhead and enable SIMD. - **Vectorization / SIMD:** one instruction processing many elements at once. - **Range-check / bounds-check elimination (RCE):** proving an index is safe so the per-access bounds check can be dropped while semantics stay intact. - **Warm-up:** running long enough that the JIT has compiled the hot path before you measure.