Bug 126331 – CStack: Refactor to split the tracking of the jsStackLimit from the native stackLimit.

• Status: RESOLVED
• Resolution: INVALID
• Component: JavaScriptCore

[Mark Lam]

Previously, when using the C stack for the JS stack, VM::m_jsStackLimit is a union with VM::m_stackLimit.  With this patch, we separate them into 2 distinct fields but haven't changed the computation of the limit values to set them with yet.

[Mark Lam]

This is a step in preparation for https://bugs.webkit.org/show_bug.cgi?id=126320.

[Mark Lam]

Created attachment 220148 [details]
the patch.

[Mark Lam]

Landed in r161172 on the jsCStack branch: <http://trac.webkit.org/r161172>.

[Geoffrey Garen]

Comment on attachment 220148 [details]
the patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=220148&action=review

> Source/JavaScriptCore/runtime/VMEntryScope.cpp:78
> +#if !ENABLE(LLINT_C_LOOP)
> +    void* jsStackLimit = m_stack.recursionLimit(requiredCapacity(JSStackCapacity));
> +    m_vm.setJSStackLimit(jsStackLimit);
> +#endif

These #ifdefs look wrong. The JS stack limit is CLoop-only. Why does the #ifdef say "*not* enable CLoop?"

[Mark Lam]

Comment on attachment 220148 [details]
the patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=220148&action=review

>> Source/JavaScriptCore/runtime/VMEntryScope.cpp:78
>> +#endif
> 
> These #ifdefs look wrong. The JS stack limit is CLoop-only. Why does the #ifdef say "*not* enable CLoop?"

This is not wrong.  The jsStackLimit is the limit that all JS code checks against (i.e. the LLINT and JITted code).  In the !ENABLE(LLINT_C_LOOP) case, VM::m_jsStackLimit is in a union with VM::m_stackLimit, and the 2 are the same.  In the ENABLE(LLINT_C_LOOP) case, the 2 are different.

That said, this is moot now.  This patch will be supplanted by https://bugs.webkit.org/show_bug.cgi?id=126320 where we'll adopt the new "simpler" way of computing the stack limit.