With %ebx now a general purpose register on the JM+TI branch, we still use %esp and %ebp to store the VMFrame and JSStackFrame. %ebp is used all the time, whenever we need to access a field of the JSStackFrame or for spill code. %esp is only used when we need to make stub calls. It would be better to just reload jaegerCompartment->activeFrame (an absolute address) into esp before calling, which would free up esp for use as a seventh general purpose register on x86.

How can you use %esp as a general purpose register? Surely it always needs to be valid stack memory so that signal handlers can run.

Ah, that may bury this idea; this bug is pretty experimental and I was just going to try it and see if things explode. What are signal handlers used for within Firefox? Posting crash dialogs? libevent? Should it be possible for a signal handler to be triggered while in JIT code, execute and then return back into JS? Even if this bug doesn't pan out, right now I think the plan for IonMonkey is to put JS frames on the C stack with everything homed by %esp (freeing up %ebp as a general purpose register). Would be good to know whether we need to worry about signal handlers corrupting the JS stack.

We trap signals for crashdumps and also to release the profile lock. (Not sure if the latter is still necessary.) Those uses don't require us to return to JS but I think they'd still be broken if %esp was invalid. There may be other uses. However, it is possible on Linux at least to arrange for signals to be delivered on an alternate stack: http://www.gnu.org/s/hello/manual/libc/Flags-for-Sigaction.html#Flags-for-Sigaction So maybe this could work, on some or all platforms. Still sounds very scary though. I like the idea of freeing up %ebp better, although it would be very nice in some ways if JS used %ebp as the base of a frame pointer chain so that tools like XPerf could see through JS stacks. Maybe as an option...

JM was removed, Ion regalloc can use all registers except esp.