With a fixed thread stack size, why does the same recursive Java method reach a different call depth from run to run, and typically a much greater depth once the JIT has compiled it?

## Depth is a quotient, and both terms move A thread's stack is a fixed byte budget, set when the thread is created (`-Xss` / `-XX:ThreadStackSize`, or the `Thread` constructor's stack-size hint). The number of frames that fit is approximately: ``` depth ≈ (stack bytes − what is already used) / (average bytes per frame) ``` Candidates often assume the denominator is a constant per method. It is not, and the numerator is not fixed either. ## Why frame size differs: interpreter versus compiled code When a method runs in the **interpreter**, its frame is built to a generic template: a local variable array of `max_locals` slots, an operand stack area of `max_stack` slots (both numbers taken straight from the `Code` attribute), plus interpreter bookkeeping — a pointer to the method, the constant-pool cache reference, the saved caller state, monitor slots for a `synchronized` method. Two methods with wildly different `max_locals` therefore produce wildly different frames; depth depends on *which* methods are on the chain. Once a method becomes hot and C1 or C2 compiles it, the picture changes: - The abstract operand stack ceases to exist as storage; intermediate values live in machine registers. - Locals that fit in registers never touch memory; only spilled values need stack slots. - The frame follows the platform's native calling convention and carries only what the compiler decided it needed. The usual result is a substantially smaller frame — so the very same recursion goes deeper after warmup than it did during the first thousands of invocations. ## Inlining removes frames entirely The larger effect is **inlining**. When the compiler inlines a callee into a caller, the callee gets no frame at all; its locals are merged into the caller's frame (often into registers). A chain of five small delegating methods that cost five interpreted frames per level can, once compiled, cost one. For self-recursion the compiler will inline a bounded number of levels, further reducing frames-per-level. This is also why the achievable depth of a *mutually* recursive pair can change enormously once one of them becomes inlinable, and why a seemingly unrelated change — making a method larger, so it exceeds the inlining size threshold — can reduce the depth a program reaches. Note the JVM performs no general tail-call elimination: a self-call in tail position still consumes a frame in the specification model, and any saving comes from inlining or compiled-frame size, not from turning recursion into iteration. ## Why the numerator varies too - **Startup context.** The recursion does not begin at an empty stack. It starts below whatever frames already exist — a servlet container's dispatch chain, a test harness, a stream pipeline — and that prefix differs between contexts and versions. - **Mode changes mid-flight.** A method may start interpreted and be replaced by compiled code partway through a run; on-stack replacement can even switch a long-running loop's execution mode while its frame is live. Deoptimization goes the other way, rebuilding interpreter frames from a compiled frame — which *increases* stack usage at that moment. - **Placement and alignment.** The OS reserves the stack region and may randomize its address; alignment requirements, guard-page sizes and thread-library overhead shave a variable amount off the usable budget. - **Guard region.** HotSpot reserves guard pages at the stack's end and, on Java method entry, *bangs* the stack — touching an address one frame-size ahead — so that exhaustion is detected before the frame is built and can be reported and unwound cleanly. The reserved region is unavailable to frames, and its size is part of the budget arithmetic. ## What this means in practice 1. **Never encode a depth constant.** "We tested it to 12,000 levels" is a measurement of one build, one JDK, one warm-up state and one call context. Recursion over user-controlled input needs an explicit bound or an iterative formulation with an explicit worklist. 2. **Bigger `-Xss` costs native memory per thread.** The reservation is per thread and outside the heap, so raising it in a service with thousands of platform threads is a real memory decision, not a free knob. 3. **Expect non-reproducibility.** A depth-sensitive failure that appears in production and not in a short local run is often just the difference between interpreted and compiled frames, or a different framework prefix on the stack. 4. **Frame size is a per-method property you can inspect.** `max_locals` and `max_stack` from `javap -c -v` tell you the interpreted frame's shape; a method with a large number of locals is genuinely more expensive per level. ## Summary The stack budget is fixed; the cost per level is not. Interpreted frames are generic and larger, compiled frames are leaner, inlining can delete levels altogether, and the starting depth and usable region vary with context and platform. Any specific maximum depth is an observation about one execution, never a contract.