[Webkit-unassigned] [Bug 26276] Need a mechanism to determine stack extent

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 20 13:58:45 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=26276





--- Comment #24 from Gavin Barraclough <barraclough at apple.com>  2010-12-20 13:58:44 PST ---
Hey xan,

Hmmm, sure, I'm beginning to question my own suggestion here.  There is a problem with the vm map based approach, in that it will measure the stack depth used by the lexer/parser & byte compiler.  We don't want to include these, since they check stack usage themselves.

So maybe we should just measure the depth from vm entry  to vm entry (write a test case to call a host function, say, array sort, that can call back out to a JS function, and measure difference in stack depth between the two entries).

> My only question is what set of programs would we run to figure out what's a reasonable limit.

If we're going to take this approach, then you just need to write a test that will cause a nested entry into JS language code.  We should measure with & without the JIT, since we believe Interpreter::privateExecute to have a huge callframe.

It would be better to find a way to measure the deepest route through the VM, but I can't think of a good way to do so, without including the parser/bytecompiler stack depth.  If you have any bright ideas here, my suggestion would be run the fast/js LayoutTests & javascriptcore-tests – in order to find the longest route through the VM we need to try different routes through the VM, and this will give us good coverage.

But maybe we should just stick to the simpler suggestion.  Any empirical test will be better than what we currently have, which is a wild guess! :-)

cheers,
G.

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


More information about the webkit-unassigned mailing list