Inside HotSpot, the C2 JIT compiler is allowed to move, merge and delete field accesses in Java code. Name the C2 optimizations that actually remove or relocate memory operations, explain what the Java Memory Model lets C2 assume about a plain (non-volatile) shared field between two synchronization actions, and explain why the same source code can behave differently once tiered compilation promotes it from the interpreter to C1 and then to C2.

## What the JMM lets C2 assume The Java Memory Model's central promise is conditional: a program whose executions contain **no data races** behaves as if all its actions were interleaved in one sequentially consistent order. A data race is two accesses to the same non-volatile field, at least one a write, not ordered by happens-before. HotSpot's C2 compiler is written to exploit exactly that promise — it optimizes *as if* the program is data-race-free, because a program that isn't gets no strong guarantee anyway. Concretely: C2 does not consult happens-before at each individual field access. Instead, **synchronization actions anchor memory**. A monitorenter/monitorexit, a volatile or `VarHandle` acquire/release/opaque access, a `Thread.start()` or `join()` — these appear in C2's ideal graph as nodes that pin the memory state, and loads and stores cannot be freely moved across them. Everything *between* two such anchors is a synchronization-free region, and inside it C2 treats a plain shared field exactly like a local variable: read it once, keep it in a register, delete reads it can prove redundant, delete or move stores. The absence of synchronization is read as a promise from the programmer that nobody else is touching those fields. ## The optimizations that move or delete memory operations **Loop-invariant load hoisting / register promotion.** If a field read inside a loop cannot be changed by anything the loop does, C2 hoists it above the loop and keeps the value in a register. `while (!stop) { work(); }` becomes, in effect, `if (!stop) while (true) work();` — the canonical never-terminating spin on a plain `boolean`. **Redundant-load elimination and store-to-load forwarding.** Two reads of the same field with no intervening anchor collapse into one; a read that follows a write to the same field reuses the written value instead of reloading it. Either way, a write performed by another thread in between is simply never observed. **Dead-store elimination and store sinking.** A store overwritten later with no intervening synchronization is deleted. A store repeated in a loop can be sunk past the loop, so instead of a value another thread could watch changing, one write lands at the very end. **Inlining.** By itself inlining moves nothing, but it is the enabler: an accessor's field read only becomes loop-invariant *after* the accessor is inlined into the loop. C2 inlines using class-hierarchy analysis and the profile collected at tier 3, so whether a call site is monomorphic — which depends on what the application happened to execute earlier — decides whether the rest of these optimizations fire at all. **Escape analysis and scalar replacement.** If C2 proves an object does not escape its allocating method (or thread), the allocation is removed and its fields become plain SSA values living in registers. This is the sharpest case for the memory model: a scalar-replaced object has **no memory operations at all**, so there is nothing for a barrier to order and nothing another thread could observe even in principle. Related transformations on the same analysis are **lock elision** (`-XX:+EliminateLocks`) for locks on non-escaping objects and **lock coarsening**, which merges adjacent synchronized blocks on the same monitor — legal because it only widens a critical section. ## Why tiered compilation changes what you observe HotSpot executes the same bytecode at several tiers. **Tier 0**, the interpreter, performs every `getfield` and `putfield` as a genuine memory access in program order — none of the above happens, so a racy program looks perfectly correct. **Tiers 1–3** are C1: fast compilation, limited optimization, and at tier 3 additional profiling instrumentation. **Tier 4** is C2, where the full optimization set above applies. So the observable interleavings of a racy program are a function of how hot the code is. A method promoted after thousands of invocations starts behaving differently mid-run. Long-running loops matter even more: **on-stack replacement (OSR)** compiles a loop *while it is executing* and swaps the running frame over, which is precisely why a spin loop runs correctly for a second or two and then hangs forever. The reverse also happens — an **uncommon trap** deoptimizes back to the interpreter, the field is reloaded from memory, and the bug appears to fix itself. This is why racy code passes tests. Short unit tests never reach tier 4; a JMH benchmark with proper warm-up, or production after a few minutes, does. It also explains the folklore fixes: adding a `println`, a `synchronized` block, or an unrelated volatile read introduces an anchor or an unanalyzable call, defeating the hoisting. Nothing was made correct — the optimization was merely suppressed, and the next inlining decision can bring it back. ## How to say it in an interview Lead with the licence (DRF assumption, plain fields are locals between anchors), name three or four concrete C2 transformations including scalar replacement's "no memory operation exists" point, then explain tiering and OSR as the reason correctness is a function of warm-up. Close with the operational consequence: you cannot test your way to memory-model correctness at tier 0.