Oilpan: Schedule a precise GC when a page navigates

Source/platform/heap/ThreadState.cpp

 /*
  * Copyright (C) 2013 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 630 matching lines @@
     // Heap::markedObjectSize() may be underestimated if any thread has not
     // finished completeSweep().
     size_t currentObjectSizeKb = currentObjectSize() >> 10;
     // Schedule a precise GC if Oilpan has allocated more than 1 MB since
     // the last GC and the current memory usage is >50% larger than
     // the estimated live memory usage.
     return allocatedObjectSizeKb >= 1024 && currentObjectSizeKb > (estimatedLiveObjectSizeKb * 3) / 2;
 #endif
 }
 
+bool ThreadState::shouldSchedulePreciseGCOnNavigation(float estimatedRemovalRatio)
+{
+    // Avoid potential overflow by truncating to Kb.
+    size_t allocatedObjectSizeKb = Heap::allocatedObjectSize() >> 10;
+    // The estimated size is updated when the main thread finishes lazy
+    // sweeping. If this thread reaches here before the main thread finishes
+    // lazy sweeping, the thread will use the estimated size of the last GC.
+    size_t estimatedLiveObjectSizeKb = (estimatedLiveObjectSize() >> 10) * (1 - estimatedRemovalRatio);
+    // Heap::markedObjectSize() may be underestimated if any thread has not
+    // finished completeSweep().
+    size_t currentObjectSizeKb = currentObjectSize() >> 10;
+    // Schedule a precise GC if Oilpan has allocated more than 1 MB since
+    // the last GC and the current memory usage is >50% larger than
+    // the estimated live memory usage.
+    return allocatedObjectSizeKb >= 1024 && currentObjectSizeKb > (estimatedLiveObjectSizeKb * 3) / 2;
+}
+
 // TODO(haraken): We should improve the GC heuristics.
 // These heuristics affect performance significantly.
 bool ThreadState::shouldForceConservativeGC()
 {
     if (UNLIKELY(isGCForbidden()))
         return false;
 
     if (shouldForceMemoryPressureGC())
         return true;
 
@@ skipping 238 matching lines @@
     // Prevent that from happening by marking GCs as forbidden while
     // one is initiated and later running.
     if (isGCForbidden())
         return;
 
     switch (gcState()) {
     case FullGCScheduled:
         Heap::collectAllGarbage();
         break;
     case PreciseGCScheduled:
-        Heap::collectGarbage(NoHeapPointersOnStack, GCWithoutSweep, Heap::PreciseGC);
+        Heap::collectGarbage(NoHeapPointersOnStack, GCWithSweep, Heap::PreciseGC);

[haraken, 2015/08/03 01:03:59]

Maybe is the regression you're observing in the shadow-dom benchmarks related to
the synchronous sweep? What happens if we change this to GCWithoutSweep? (Maybe
the regression in the shadow-dom benchmarks will be gone but the regression in
Speedometer re-appears.)

         break;
     case IdleGCScheduled:
         // Idle time GC will be scheduled by Blink Scheduler.
         break;
     default:
         break;
     }
 }
 
 void ThreadState::flushHeapDoesNotContainCacheIfNeeded()
@@ skipping 609 matching lines @@
         json->beginArray(it->key.ascii().data());
         for (size_t age = 0; age <= maxHeapObjectAge; ++age)
             json->pushInteger(it->value.ages[age]);
         json->endArray();
     }
     TRACE_EVENT_OBJECT_SNAPSHOT_WITH_ID(TRACE_DISABLED_BY_DEFAULT("blink_gc"), statsName, this, json.release());
 }
 #endif
 
 } // namespace blink