emscripten

emscripten copied to clipboard

The withStackSave helper is a convenient way to avoid having the remember to write stackRestore at the end of a JS library function.

However, this construct has some cost. Firstly it create an inner closure object, and secondly it relies on try/finally control flow to restore the stack pointer.

At the time when I originally wrong withStackSave I was under the impression that restore in the stack, even in the exceptional case, was important. However, my new/current understanding is that the shadow stack pointer doesn't need to be restored during unwinding until an exception is caught. i.e. its up the outer try/catch to return the stack pointer.

The other useful think about withStackSave is that for function with multiple exit points one doesn't need to repeat the stackRestore statement for each one. Perhaps for such functions we can keep this helper around, but I suspect that are few functions that have enough exit points to justify this helper.

Currently we have 41 uses of withStackSave in the codebase.

It looks like about 1/2 of them are trivially replaceable with a pair of stackSave/stackRestore calls.