In CRuby, what does the tailcall_optimization compile option of RubyVM::InstructionSequence do, how is it enabled, and why is it off by default?

## What a tail call is A call is in **tail position** when its result is returned directly, with nothing left for the caller to do afterwards: ```ruby def sum_to(n, acc = 0) return acc if n.zero? sum_to(n - 1, acc + n) # tail call end ``` Normally each call pushes a new frame, so `sum_to(1_000_000)` exhausts the VM stack and raises `SystemStackError`. **Tail-call optimisation** compiles such a call to reuse the current frame, keeping the stack depth constant. ## CRuby's option CRuby's bytecode compiler has an option named **`tailcall_optimization`**. Its default in `vm_opts.h` is `0`, so it is **off**. The documented ways to turn it on are: 1. **Globally for later compilation:** `RubyVM::InstructionSequence.compile_option = { tailcall_optimization: true }`. Options not named in the Hash keep their current values. 2. **For one compilation:** pass the option to `RubyVM::InstructionSequence.compile`, `.compile_file` or `.new`, then `eval` the result. `RubyVM::InstructionSequence.compile_option` with no argument returns the current defaults as a Hash, which is a quick way to check the setting. ## How the compiler applies it With the option on, the compiler looks for a method call immediately followed by the method's return and marks that call as a tail call. At run time the VM then **pops the caller's frame before setting up the callee's**, so the depth stays the same. Two details follow from the implementation: - The call must be the **last instruction before returning**; a branch that returns the call's result, such as `return f(x) if cond`, also qualifies. - A call that passes a **literal block** is not marked by the compiler. ## It only affects code compiled later The option changes how **new** instruction sequences are compiled. Code that was already compiled keeps its frames: - The main script is compiled before its first line runs, so setting the option at the top of that script does **not** optimise methods defined further down the same file. - Files loaded with `require` or `load` **after** the setting, and strings passed to `eval` afterwards, are compiled with it. That is why examples wrap the recursive method in an `eval` or put it in a separately required file. ## Where it does not apply The compiler skips tail-call optimisation in several places: - Top-level, `eval` and main instruction sequences themselves, because popping their frame would unwind too far. - **`rescue` and `ensure`** bodies, which need their frame to hold the current exception, and calls inside a region **protected by `rescue`**, whose frame must survive to handle an error. - Any call that is not in tail position, such as `n * fact(n - 1)`, where the multiplication still runs after the call returns. ## Why it stays off | Concern | Effect | |---|---| | Backtraces | Replaced frames disappear, so an error deep in a tail-recursive chain shows fewer callers | | Portability | It lives under `RubyVM`, which is specific to CRuby, so other implementations need not honour it | | Scope | It is process-wide when set globally, affecting every gem loaded afterwards | | Idiom | Ruby code conventionally loops with `each`, `while` or an explicit Array stack instead of relying on tail recursion | Older blog recipes set `trace_instruction: false` beside it; Ruby 4.0's compiler does not read that key, so it has no effect there. ## When to use it In application code, almost never. In a drawing app whose undo history is replayed recursively, the robust fix is an iterative loop over an explicit Array, which works on every Ruby and keeps full backtraces. The option is worth knowing for interviews, for porting functional-style code, and for understanding why tail recursion in Ruby is not free by default.