Oilpan: fix computation of ThreadState::m_collectionRate.

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 deaa5135d82c09596854b74a0164c6e37fec1fe5..4322bac7365fc1242b8fc16090670446ee4989eb 100644
--- a/Source/platform/heap/ThreadState.cpp
+++ b/Source/platform/heap/ThreadState.cpp
@@ -857,16 +857,6 @@ void ThreadState::completeSweep()
             m_heaps[i]->completeSweep();
     }
 
-    if (isMainThread()) {
-        // FIXME: Heap::markedObjectSize() may not be accurate because other
-        // threads may not have finished sweeping.
-        m_collectionRate = 1.0 * Heap::markedObjectSize() / m_allocatedObjectSizeBeforeSweeping;
-    } else {
-        // FIXME: We should make m_lowCollectionRate available in non-main
-        // threads.
-        m_collectionRate = 1.0;
-    }
-
     setGCState(gcState() == Sweeping ? NoGCScheduled : GCScheduled);
 }
 
@@ -893,12 +883,24 @@ void ThreadState::preGC()
     makeConsistentForSweeping();
     prepareRegionTree();
     flushHeapDoesNotContainCacheIfNeeded();
+    if (isMainThread())
+        m_allocatedObjectSizeBeforeGC = Heap::allocatedObjectSize() + Heap::markedObjectSize();
 }
 
 void ThreadState::postGC(GCType gcType)
 {
     ASSERT(isInGC());
     setGCState(gcType == GCWithSweep ? EagerSweepScheduled : LazySweepScheduled);
+    if (isMainThread() && m_allocatedObjectSizeBeforeGC) {
+        // FIXME: Heap::markedObjectSize() may not be accurate because other
+        // threads may not have finished sweeping.
+        m_collectionRate = 1.0 * Heap::markedObjectSize() / m_allocatedObjectSizeBeforeGC;

[haraken, 2015/01/14 01:36:26]

Heap::markedObjectSize() is accumulated in the (lazy) sweeping phase, and thus
Heap::markedObjectSize() would be 0 at this point in most cases, wouldn't it?
Things happen in the order of preGC => marking => postGC => lazy sweeping.

(However, if that is the case, m_collectionRate will be evaluated as 0 in most
cases and thus shouldForceConservativeGC() will use the not-high-collection-mode
condition to trigger conservative GCs. I'm wondering why it doesn't regress
performance of LargeDistribution.)

[sof, 2015/01/14 06:14:27]

Thanks, I realized the same overnight. Sorry about the pointless CL churn, will
address.
The miscalculation above represents the other extreme, in a sense. I'll gather
some more data on what&how conservative GCs that triggers, once the rate
calculation has been sorted out.

[sof, 2015/01/14 09:53:24]

Now tidied, to some extent. The lagging sweeps across threads is a bit confusing
to interpret in a sense-making manner.

Re: LargeDistributionWithoutLayout -- the conservative GCs that it triggers
aren't via the two special cases in shouldForceConservativeGC(), so there's no
change in behavior to be expected wrt it and this CL.

+        ASSERT(m_collectionRate >= 0. && m_collectionRate <= 1.);
+    } else {
+        // FIXME: We should make m_collectionRate available in non-main threads.
+        m_collectionRate = 1.0;
+    }
+
     for (int i = 0; i < NumberOfHeaps; i++)
         m_heaps[i]->prepareForSweep();
 }
@@ -1037,8 +1039,6 @@ void ThreadState::postGCProcessing()
         return;
 
     m_didV8GCAfterLastGC = false;
-    if (isMainThread())
-        m_allocatedObjectSizeBeforeSweeping = Heap::allocatedObjectSize();
 
 #if ENABLE(GC_PROFILE_HEAP)
     // We snapshot the heap prior to sweeping to get numbers for both resources