Oilpan: Move synchronous Oilpan GCs out of V8 GC epilogues

third_party/WebKit/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 579 matching lines @@
 
     if (isGCForbidden())
         return;
 
     // This completeSweep() will do nothing in common cases since we've
     // called completeSweep() before V8 starts minor/major GCs.
     completeSweep();
     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
         schedulePreciseGC();
         return;
     }
     if (gcType == BlinkGC::V8MajorGC) {
 #if PRINT_HEAP_STATS
         dataLogF("Scheduled IdleGC\n");
 #endif
@@ skipping 887 matching lines @@
     threadDump->addScalar("dead_count", "objects", totalDeadCount);
     threadDump->addScalar("live_size", "bytes", totalLiveSize);
     threadDump->addScalar("dead_size", "bytes", totalDeadSize);
 
     WebMemoryAllocatorDump* heapsDump = BlinkGCMemoryDumpProvider::instance()->createMemoryAllocatorDumpForCurrentGC(heapsDumpName);
     WebMemoryAllocatorDump* classesDump = BlinkGCMemoryDumpProvider::instance()->createMemoryAllocatorDumpForCurrentGC(classesDumpName);
     BlinkGCMemoryDumpProvider::instance()->currentProcessMemoryDump()->addOwnershipEdge(classesDump->guid(), heapsDump->guid());
 }
 
 } // namespace blink