Why do many runtimes decline tail-call elimination despite the free stack win?

## Elimination is not a transparent optimization Most optimizations are invisible: they change speed or memory, not what the program can observe. **Tail-call elimination** is different in both directions: - It removes activation records that diagnostic tooling reads. - It makes some programs terminate that would otherwise fail — an unbounded tail-recursive loop is a *correct* program only if elimination happens. Anything with observable consequences has to be specified rather than quietly implemented, and once specified it constrains the implementation forever. That is the frame in which "why don't they just do it" gets answered. ## Four reasons runtimes decline it 1. **Reason one: diagnostics.** Activation records are what a stack trace, a debugger's call view, and a sampling profiler's attribution are made of. Eliminate them and a deep tail-recursive computation reports a single frame, with the entire chain of callers that led to a failure gone. Step-out in a debugger loses the destination it would return to. Profilers that build a caller tree lose the caller. For runtimes whose selling point is diagnosability of long-lived server processes, that is a real, daily cost paid to save a stack that most programs never exhaust — because most of those programs are written with loops anyway. 2. **Reason two: models that inspect the caller chain.** Some runtimes make security or context decisions by walking the chain of callers — permission checks that ask "who is above me", ambient context propagation, sandboxing boundaries, tracing that attributes work to a request by walking frames. Elimination deletes exactly the evidence those mechanisms consult, so supporting it means redesigning them, not just adding a codegen pass. 3. **Reason three: general tail calls cost more than self tail calls.** Turning direct self-recursion into a jump is a local transformation an optimizer can do without any specification change. A *general* tail call — to another function, across a module boundary, through a function value or a dynamically dispatched target — needs a calling convention that lets the callee reuse the caller's frame even though the argument layouts differ, plus interop rules for foreign frames, plus a story for unwinding. Implementations frequently take the cheap half and decline the expensive half, which is why "my self-recursion is fine but my mutual recursion overflows" is a real report rather than a bug. 4. **Reason four: a promise must hold everywhere.** Guaranteeing elimination means guaranteeing it in unoptimized builds, under a debugger, in an interpreter tier before any compilation happens, and for every construct the spec names. That forecloses implementation strategies — a straightforward interpreter that maps source calls to host calls, for instance. Implementers who want that freedom decline the guarantee and offer, at most, **best-effort elimination**, which is deliberately weaker: it can disappear when an inlining decision changes. ## The traditions that pay the price cheerfully Where recursion *is* the looping construct, elimination is not optional and the diagnostic cost is accepted as the price of the model; some such systems mitigate it by retaining a bounded ring of recent frames for error reporting. The same trade, resolved oppositely, by designers who each had a defensible ranking of stack safety against debuggability: - The Scheme standard and Lua both mandate **proper tail calls**, - while the JVM and CPython decline them. ## What this means for you as an engineer Stop reading the absence of elimination as an oversight or as laziness on the implementer's part. It is a **design position** with named beneficiaries — the people reading a production stack trace at 3 a.m. — and it is stable. The practical consequence is that stack safety for unbounded input is *your* problem to solve, by bounding depth or using iteration, on any target that has not promised otherwise. The interviewer asking this question is usually checking whether you can reason about a runtime's tradeoffs at all, or whether you assume every un-applied optimization is an unfixed bug. ## A caution on the "free win" framing Even where elimination is performed, it is not universally free: it can perturb inlining decisions, and it changes what a profiler attributes work to, which shows up as a debugging tax long after the stack win was banked. "Free" is the wrong word for anything that alters observable behaviour.