Prevent GCs when constructing GC mixin objects.

Source/platform/heap/ThreadState.cpp

Index: Source/platform/heap/ThreadState.cpp
diff --git a/Source/platform/heap/ThreadState.cpp b/Source/platform/heap/ThreadState.cpp
index a552cc3bcace888a7640d578698db16cd19550bd..11519e5bcda35073e0824e6ecc97ceaecb1128cd 100644
--- a/Source/platform/heap/ThreadState.cpp
+++ b/Source/platform/heap/ThreadState.cpp
@@ -236,6 +236,7 @@ ThreadState::ThreadState()
     , m_didV8GCAfterLastGC(false)
     , m_sweepForbidden(false)
     , m_noAllocationCount(0)
+    , m_noGCAllowedCount(0)

[haraken, 2015/02/23 08:24:23]

Can we add ASSERT(!m_noGCAllowedCount) to somewhere to check that the enter and
exit are balanced (e.g., when entering SafePointScope)?

[sof, 2015/02/23 10:29:02]

It is currently asserted for on leaving; is that sufficient?

     , m_isTerminating(false)
     , m_shouldFlushHeapDoesNotContainCache(false)
     , m_collectionRate(1.0)
@@ -669,6 +670,9 @@ bool ThreadState::shouldSchedulePreciseGC()
 // These heuristics affect performance significantly.
 bool ThreadState::shouldForceConservativeGC()
 {
+    if (UNLIKELY(m_noGCAllowedCount))

[haraken, 2015/02/23 08:24:23]

I'm wondering how unlikely this happens. What happens if we create a ton of
Nodes?

  for (...)
    document.createElement("div");

Given Node is a GCMixin, we might end up not triggering any conservative GC?

[sof, 2015/02/23 08:30:20]

Not sure I understand the concern - Node is an EventTarget, which is not a
mixin.

+        return false;
+
     size_t newSize = Heap::allocatedObjectSize();
     if (newSize >= 300 * 1024 * 1024) {
         // If we consume too much memory, trigger a conservative GC