[Webkit-unassigned] [Bug 12216] Stack overflow crash in JavaScript garbage collector mark pass

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=12216





------- Comment #7 from cwzwarich at uwaterloo.ca  2007-07-14 19:28 PDT -------
In my previous comment, I proposed a fix for this bug and said that I didn't
see any other portable way of fixing it. Here is another method that is not as
portable, but won't require as many changes to existing code as the proposal in
my previous comment, and will probably be more efficient, as replacing stack
allocation with heap allocation gives a performance hit on modern x86
processors. It also lets you fall back to the existing code with #ifdef if some
of the non-portable things are not supported properly.

To avoid the stack overflow, one can implement "segmented stacks" using
setjmp() and longjmp(). Before beginning the marking process, malloc a new
region to be used as the stack. Construct the proper jmp_buf (this is
non-portable) that uses this new region as a stack and longjmp() to it. Now,
every time you are going to call another method, double check that you have
enough stack space left by whatever method you would like (calling the usual
functions to get the stack pointer, comparing pointers, or checking SP with
some inline assembly). If you don't, allocate a new region of memory to be used
as a stack, dump a setjmp() into the beginning of it, manufacture another
jmp_buf that uses this region as a stack, and then resume business as usual.
When the other method returns, free the new stack you allocated, and longjmp()
back to where you were. You don't even need to do this every method call, only
once whenever another method call from the current method call could possibly
overflow the stack. Of course, if you know the size of the usual stack, you
could avoid the initial allocation.

This does kill any chance of using C++ exceptions in the new stack, but it will
probably be a lot more efficient than using continuation-passing style. Beyond
a stack comparison and a branch that will likely be predicted properly, it only
kicks in when the stack overflows, whereas with CPS you always take a bit of a
hit in order to handle the unusual case.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.