Oilpan: Move synchronous Oilpan GCs out of V8 GC epilogues

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

Index: third_party/WebKit/Source/platform/heap/ThreadState.cpp
diff --git a/third_party/WebKit/Source/platform/heap/ThreadState.cpp b/third_party/WebKit/Source/platform/heap/ThreadState.cpp
index e8672bf1111b4e0078b40fd5993e1a6129d8ad3f..e630d215fa1e7f1a7b6cfe3d644e34d30e279dd8 100644
--- a/third_party/WebKit/Source/platform/heap/ThreadState.cpp
+++ b/third_party/WebKit/Source/platform/heap/ThreadState.cpp
@@ -597,16 +597,8 @@ void ThreadState::scheduleV8FollowupGCIfNeeded(BlinkGC::V8GCType gcType)
     ASSERT(!isSweepingInProgress());
     ASSERT(!sweepForbidden());
 
-    // TODO(haraken): Consider if we should trigger a memory pressure GC
-    // for V8 minor GCs as well.
-    if (gcType == BlinkGC::V8MajorGC && shouldForceMemoryPressureGC()) {
-#if PRINT_HEAP_STATS
-        dataLogF("Scheduled MemoryPressureGC\n");
-#endif
-        Heap::collectGarbage(BlinkGC::HeapPointersOnStack, BlinkGC::GCWithoutSweep, BlinkGC::MemoryPressureGC);
-        return;
-    }
-    if (shouldScheduleV8FollowupGC()) {
+    if ((gcType == BlinkGC::V8MajorGC && shouldForceMemoryPressureGC())

[sof, 2016/02/01 14:41:48]

Won't this regress on some tests that do run into memory pressure?

[haraken, 2016/02/01 15:05:57]

It may regress, but I think it isn't as terrible as you expect.

- V8 calls kGCTypeMarkSweepCompact's epilogue when it finishes the major GC.
Then V8 posts a new task to run kGCTypeProcessWeakCallbacks. (If V8 is under
memory pressure, the kGCTypeProcessWeakCallbacks is scheduled immediately after
the kGCTypeMarkSweepCompact's epilogue.)

- This CL moves scheduleV8FollowupGCIfNeeded from kGCTypeProcessWeakCallbacks'
epilogue to kGCTypeMarkSweepCompact's epilogue and then schedules a precise GC
at the end of the event loop.

- This means that before this CL, the precise GC doesn't run until the posted
task is scheduled, but after this CL, the precise GC is scheduled at the end of
the event loop. This is an improvement (i.e., the precise GC is scheduled
earlier).

- On the other hand, this CL stops running a conservative GC under memory
pressure. This is a regression but the memory pressure GC will anyway be
triggered when the next out-of-line allocation takes place.

- Overall, I guess this change isn't as terrible as you expect.

+        || shouldScheduleV8FollowupGC()) {
 #if PRINT_HEAP_STATS
         dataLogF("Scheduled PreciseGC\n");
 #endif