Bug 22531 – Stack overflow on PowerPC on fast/workers/use-machine-stack.html

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

Apparently, non-CTI interpreter uses a lot of stack for native calls, exhausting the whole 512K stack.

[Alexey Proskuryakov]

Also, I'm building with gcc 4.0.1 on Tiger - maybe gcc 4.2 learned to reuse stack space used by scoped variables? There's lots of src and dst variables in privateExecute().

[Alexey Proskuryakov]

"A lot" means ~7K per recursive call on this test. 

[Alexey Proskuryakov]

<rdar://problem/6406045>

[Alexey Proskuryakov]

This is not specific to worker threads - the same crash would happen for a thread created via JavaScriptCore API (even worse, in that case we don't control stack size of the thread).

[Alexey Proskuryakov]

Disabled the test in r38862.

[Darin Adler]

7KB per native call? Are you serious? That seems absurd.

[Alexey Proskuryakov]

I measured 7K on a debug build - release may be slightly better, but not much better:
 JSC::Interpreter::privateExecute(JSC::Interpreter::ExecutionFlag, JSC::RegisterFile*, JSC::ExecState*, JSC::JSValuePtr*
):
 +00000 000cf090 7C0802A6             mflr              r0
 +00004 000cf094 DBE1FFF8             stfd              f31,0xfff8(SP)
 +00008 000cf098 2F850001             cmpwi             cr7,r5,0x1
 +0000c 000cf09c BDA1FFAC             stmw              r13,0xffac(SP)
 +00010 000cf0a0 429F0005             bcl               20,31,$+4
 +00014 000cf0a4 90010008             stw               r0,0x8(SP)
 +00018 000cf0a8 9421ECC0             stwu              SP,0xecc0(SP)

0xecc0 is -4928, so privateExecute alone takes about 5K, and there are other methods involved in each call.

[Geoffrey Garen]

Created attachment 28779 [details]
patch

[Cameron Zwarich (cpst)]

Comment on attachment 28779 [details]
patch

r=me

[Oliver Hunt]

Comment on attachment 28779 [details]
patch

r=me, though i'd like you to compare degree of reentry between ffx and us..

[Geoffrey Garen]

Committed revision 41852.

I'm not sure how important it is for JavaScript to work well on threads where the client has artificially shrunk the stack size from the default. If that turns out to be an important use case, I guess we'll want an API for specifying how much stack JS gets to use, or a mechanism for asking the OS what the stack boundary is.

[Geoffrey Garen]

> r=me, though i'd like you to compare degree of reentry between ffx and us..

Firefox allows 400-500 -- far more than both our old 128 and our new 64.

If we discover that this is a compatibility problem, we should be able to reduce the stack used by Interpreter::execute and dial up the recursion limit.