In SpiderMonkey the interpreter exposes the stack pointer register sp to the outside world through JSFrameRegs.sp allocated on the native stack. It allows for the GC to scan only the currently present elements on the stack. It also allows the error reporter to locate the value that triggered the error and use that information for decompilation. Due to this exposure the compiler cannot keep the value of sp in a register all the time. In particular, the compiler at least has to synchronize the current sp with JSFrameRegs.sp before and after any function call as the compiler does not know that JSFrameRegs.sp cannot change during the call. This causes extra load/store for the sp hurting the performance. This expose can be eliminated if a script would contain a map that allows to find the maximum stack depth for a particular bytecode. Then the GC and the error reporter can use the map to find out about the stack based on the current value of pc without the need to access the live sp. The drawback of this schema is that the bytecodes that push values to the stack have to make sure that all pushing happen before any call that can trigger the GC or cause an error. This is necessary since the GC would know only about the maximum possible stack size. But a static analysis can help to enforce this.

What about pc? Updating PC in memory after every instruction is actually fairly expensive, too. See https://bugzilla.mozilla.org/show_bug.cgi?id=442379

(In reply to comment #1) > What about pc? Updating PC in memory after every instruction is actually fairly > expensive, too. Well, the GC and error reporter have to know where the interpreter is. But this means that the pc has to be updated only before functions calls that can trigger the GC or that can fail. That is, there is no need to update the pc for call-less and error-less bytecodes. But then a static analysis is a must. We do not want to repeat the missing SAVE_SP_AND_PC disasters! Regarding that SAVE_SP_AND_PC macro. Until the bug 421274 was fixed SpiderMonkey relied on explicit synchronization of pc and sp into JSStackFrame. But it turned out that on i386 and x86-64 that hurt the performance besides being a maintenance nightmare. There were numerous GC hazards due to the missing maro call. Part of the reason why SAVE_SP_AND_PC was expensive was due to using JSStackFrame, not the native stack, for the synchronization like in fp->sp= sp, fp->pc = pc. That required an extra load of fp. If instead SAVE_SP_AND_PC would use JSFrameRegs, that sync would be presumably faster. Still, if the need to sync sp would be eliminated completely and SAVE_PC would be enforced through a static analysis, that would allow to max the performance without introducing new hazards.