On 06/28/2013 06:52 PM, Benjamin Smedberg wrote:
The JS stack limit should be basically the native stack limit minus a
little bit of headroom (maybe 512 bytes?). Whether we implement that
dynamically or just use ifdefs to hardcode the "correct" values seems
like just an implementation question.
Unless I misunderstand the questions and you're saying that the
"inconsistency" in *native* stack size is part of the problem, in
which case I think we need to understand why any production code would
be getting particular close to any of the native thread size stack
limits.
I conflated 2 issues a little.
1) Primary concern: JS that runs fine in some xpcshell builds dies on
other xpcshell builds based on platform and build type. The same JS
runs totally fine in node.js on all platforms, but use of node.js is
forbidden by the module owner in this case. Greater consistency in
failures is desired, or at least not dying because we are being
artificially stingy with JS stack size. This could be accomplished by
changing stack sizes or making it possible to adjust the stack
used/supported by xpcshell.
The problem in this case was due to the 1 MiB JS stack limit on linux
(with 8 MiB native stacks) killing an out-of-date esprima JS parser
which was a very literal recursive descent parser with separate
functions for each of the operator precedence hierarchy and which
bounced all calls through a wrapper that used apply(). See
https://gist.github.com/asutherland/5871825 for the stack. Newer
esprima builds have improved stack behaviour by consolidating binary
expression parsing into a single function that uses a while loop.
Besides upgrading, stack usage for our specific use case has also been
improved by using SpiderMonkey's parsing API instead in cases where
esprima's extended feature set is not required. (Comments, I think.)
I don't believe this problem is completely rare however, given the
existence of bugs like
https://bugzilla.mozilla.org/show_bug.cgi?id=762618 for one of the
add-on manager's unit tests.
2) Since xpcshell is just relying on the default XPConnect behaviour,
there's the question of whether what XPConnect is doing is really what
we want it to do. I agree that it seems like the JS stack limit should
be consistent with the actual stack size limit, especially given that
there still exist numerous code paths in Firefox that can spin a nested
event loop and effectively rob the JS stack of arbitrarily capped
available stack space.
In this case, since the hard-coded values for Windows are out-of-date by
a factor of two, the linux ones seem arbitrary and unrelated to default
"ulimit -s" values (or actual values), it does seem like the #define
solution might not be perfect.
It seems like going with the dynamic option would address #1 and works
for #2. If our linux/OS X scripts want to to ensure that xpcshell can
run obscenely recursive code, they can set the ulimit before running
xpcshell and all will be well. (Windows remains a problem but with a 2
meg stack for 32-bit builds, there's a lot of head-room.)
I'll file a bug on this and try to provide a patch unless I hear
otherwise. (I am very happy for someone else to do all the work!)
Andrew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
