Search code examples
memorystackwebkitv8

Is the maximum call stack size in WebKit three times greater than that of V8? Why?

I see from this blog post the following function to compute the max call stack size: 

function computeMaxCallStackSize() {
    try {
        return 1 + computeMaxCallStackSize();
    } catch (e) {
        // Call stack overflow
        return 1;
    }
}

if ran from Chrome's console, 12530 is the result (for V8)

Assuming that the same function computes the same result for WebKit, why when ran for Safari is 36243 the result? This is ~three times the size? The only time that I've ran into this error is when creating a good ole infinite loop. Is this an arbitrary decision? Does a larger stack size confer larger benefits?

Solution

  • The maximum number of (recursive or not, doesn't matter) calls is determined by (1) the size of available stack space, divided by (2) the size of each stack frame of the active function(s).

    (1) has an upper limit imposed by the operating system; on systems I'm aware of it's usually between 1MB and 8MB. Below that limit, a JavaScript engine can set its own limit. V8 sets a limit of a bit less than one megabyte on all platforms, in order to have different platforms behave as similar to each other as possible. I don't know what Safari/JavaScriptCore does.

    (2) depends on the implementation details of the JavaScript engine (specifically, how many slots in each stack frame it uses for internal data), as well as on the number of local variables in each of the functions that are involved.

    As you observe, one usually only runs into the stack limit in case of accidental infinite recursion. So for most real applications, the specific value of the limit doesn't matter, and a larger stack provides no benefit.

    Note that stack space is unrelated to maximum memory consumption (aka heap space). You can have gigabytes of heap with only a megabyte of stack.