Split out fallback stack limit determination.

third_party/WebKit/Source/platform/heap/StackFrameDepth.cpp

Index: third_party/WebKit/Source/platform/heap/StackFrameDepth.cpp
diff --git a/third_party/WebKit/Source/platform/heap/StackFrameDepth.cpp b/third_party/WebKit/Source/platform/heap/StackFrameDepth.cpp
index a7380d5687aafb2676bb0d3da91bc87a2855f64e..2f2123ebe6025898de443852cc509c11778dbef5 100644
--- a/third_party/WebKit/Source/platform/heap/StackFrameDepth.cpp
+++ b/third_party/WebKit/Source/platform/heap/StackFrameDepth.cpp
@@ -32,6 +32,23 @@ NEVER_INLINE static uintptr_t currentStackFrameBaseOnCallee(const char* dummy)
     return StackFrameDepth::currentStackFrame();
 }
 
+uintptr_t StackFrameDepth::getFallbackStackLimit()
+{
+    // Fallback version.
+    // Allocate a 32KB object on stack and query stack frame base after it.

[haraken, 2016/02/05 09:05:57]

If we take this approach, I think we can increase the threshold. Shall we try
128 KB (for example) and see if we get crash reports?

[sof, 2016/02/05 09:13:01]

On Windows this method will never be executed, so that won't make much of a
difference for the associated bug.

i.e., the compiler will hoist & include _chkstk() calls in prologues if the
method/function makes > 4k of local stack allocations -- the check isn't delayed
until the stack pointer is actually bumped. Which it will never be on Windows
where we can determine stack size reliably.

+    char dummy[kSafeStackFrameSize];
+
+    // Check that the stack frame can be used.
+    dummy[sizeof(dummy) - 1] = 0;
+#if ENABLE(ASSERT)
+    // Use a larger stack limit for what's acceptable if the platform
+    // thread ends up using the fallback size to decide if switching to
+    // lazy marking is in order.
+    s_isUsingFallbackStackSize = true;
+#endif
+    return currentStackFrameBaseOnCallee(dummy);
+}
+
 void StackFrameDepth::enableStackLimit()
 {
 #if ENABLE(ASSERT)
@@ -39,31 +56,19 @@ void StackFrameDepth::enableStackLimit()
     s_isUsingFallbackStackSize = false;
 #endif
 
-    static const int kStackRoomSize = 1024;
-
     size_t stackSize = getUnderestimatedStackSize();
-    if (stackSize) {
-        Address stackBase = reinterpret_cast<Address>(getStackStart());
-        RELEASE_ASSERT(stackSize > static_cast<const size_t>(kStackRoomSize));
-        size_t stackRoom = stackSize - kStackRoomSize;
-        RELEASE_ASSERT(stackBase > reinterpret_cast<Address>(stackRoom));
-        s_stackFrameLimit = reinterpret_cast<uintptr_t>(stackBase - stackRoom);
+    if (!stackSize) {

[haraken, 2016/02/05 09:19:02]

It would be worth having a comment and mention on what platforms we fall back to
the fallback stack size.

[sof, 2016/02/05 10:09:34]

Yes, added.

Having a non-zero default estimate for pthreads-based platforms, is probably
worth it. But not by this CL.

+        s_stackFrameLimit = getFallbackStackLimit();
         return;
     }
 
-    // Fallback version
-    // Allocate a 32KB object on stack and query stack frame base after it.
-    char dummy[kSafeStackFrameSize];
-    s_stackFrameLimit = currentStackFrameBaseOnCallee(dummy);
+    static const int kStackRoomSize = 1024;
 
-    // Assert that the stack frame can be used.
-    dummy[sizeof(dummy) - 1] = 0;
-#if ENABLE(ASSERT)
-    // Use a larger stack limit for what's acceptable if the platform
-    // thread ends up using the fallback size to decide if switching to
-    // lazy marking is in order.
-    s_isUsingFallbackStackSize = true;
-#endif
+    Address stackBase = reinterpret_cast<Address>(getStackStart());
+    RELEASE_ASSERT(stackSize > static_cast<const size_t>(kStackRoomSize));
+    size_t stackRoom = stackSize - kStackRoomSize;
+    RELEASE_ASSERT(stackBase > reinterpret_cast<Address>(stackRoom));
+    s_stackFrameLimit = reinterpret_cast<uintptr_t>(stackBase - stackRoom);
 }
 
 size_t StackFrameDepth::getUnderestimatedStackSize()