Thanks for bringing this up. I agree that we should do something about this, and if only for testing purposes. I would tend to favor
g) Add a command line argument to set the stack quota to the lowest any of our platforms support. That way, you can be sure that your script really does run on all platforms. (Well, at least it won't over-recurse unexpectedly.) @terrence, you worked on bug 803182<https://bugzilla.mozilla.org/show_bug.cgi?id=803182>, maybe you can comment on what's best here? As an aside, I'm surprised the linux opt builds have half the stack sizes the debug ones do. On Thu, Jun 27, 2013 at 4:06 AM, Andrew Sutherland < asutherl...@asutherland.org> wrote: > For B2G's gaia repository we are currently using xpcshell[1] as our > command line JS runner. I was noticing some horrible inconsistencies in > terms of blowing the JS stack when we were trying to use the esprima JS > parser[2] that varied by the platform and build type. > > The nutshell is that the #defines at http://dxr.mozilla.org/** > mozilla-central/source/js/**xpconnect/src/XPCJSRuntime.**cpp#l2687<http://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#l2687>net > us the following JS stack limits. (These are the limits when the JS > engine starts throwing "InternalError: too much recursion" and are somewhat > separate from actual native stack limits.) > > linux (32 bit, non-debug): 512 KiB > windows (all builds): 900 KiB [3] > linux (32 bit, debug): 1 MiB > linux (64 bit, non-debug): 1 MiB > linux (64-bit, debug): 2 MiB > OS X (all): 7 MiB > > > For gaia's purposes, this inconsistency is not great. How should we > resolve this? > > a) Make xpcshell try and pick more consistent values itself > > b) Make xpcshell take a command line argument and call > JS_SetNativeStackQuota plus doing whatever it needs to back that up with an > appropriate platform stack (possibly by re-exec()ing). (Similar to node.js > supporting --stack_size which defaults to 984 for me right now.) > > c) Change xpconnect's hard-coded defaults > > d) Change xpconnect to use jsnativestack.cpp's ability to tell us what the > platform stack size actually is and/or nsThread's knowledge of the stack > size it was created with. So on linux we'd use whatever 'ulimit -s' is > telling us to do, etc. > > e) Don't use xpcshell for that! Are you crazy?! > > f) Other > > Thanks, > Andrew > > 1: Although in the future this might end up just being any xulrunner > "-app" capable build. > 2: Since the esprima JS parser produces a parse-tree that's supposed to > confirm to what SpiderMonkey's Reflect API produces, we do have a > work-around, but I expect this stack issue to come up again in the future. > 3: The windows limit could be higher by its current rationale; > https://bugzilla.mozilla.org/**show_bug.cgi?id=582910<https://bugzilla.mozilla.org/show_bug.cgi?id=582910>increased > the windows stack to 2 MiB from 1MiB. > ______________________________**_________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
