Many years ago I (think? It’s a long time ago now) wrote the code the migrated JSC’s early bytecode engine to an explicit stack for similar reasons: setting up the interpreter stack frame was super slow and used a bunch of the C stack space, allowed more graceful handling of stack exhaustion, etc<p>As the bytecode interpreter got tigger, and eventually moved to a JIT the trade offs start to change quite dramatically: burning a register to reference the explicit stack, managing two call stacks, etc start to eat most of the gains. Once you eventually leave C behind for the interpreter loop the problems of large interpreter stack frames ceases to exist.<p>Eventually you end up back at regular calls and stack recursion again.