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.
This is a step in preparation for https://bugs.webkit.org/show_bug.cgi?id=126320.
Created attachment 220148 [details] the patch.
Landed in r161172 on the jsCStack branch: <http://trac.webkit.org/r161172>.
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?"
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.