Allow Oilpan heap objects account for their external allocations.

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 651 matching lines @@
     // but not for less than 512 KB.
     size_t newSize = Heap::allocatedObjectSize();
     return newSize >= 512 * 1024 && newSize > Heap::markedObjectSize() / 2;
 #endif
 }
 
 // FIXME: We should improve the GC heuristics.
 // These heuristics affect performance significantly.
 bool ThreadState::shouldForceConservativeGC()
 {
+    if (Heap::isUrgentGCRequested())
+        return true;
+
     size_t newSize = Heap::allocatedObjectSize();
     if (newSize >= 300 * 1024 * 1024) {
         // If we consume too much memory, trigger a conservative GC
         // on a 50% increase in size since the last GC. This is a safe guard
         // to avoid OOM.
         return newSize > Heap::markedObjectSize() / 2;
     }
     if (m_didV8GCAfterLastGC && m_collectionRate > 0.5) {
         // If we had a V8 GC after the last Oilpan GC and the last collection
         // rate was higher than 50%, trigger a conservative GC on a 200%
         // increase in size since the last GC, but not for less than 4 MB.
         return newSize >= 4 * 1024 * 1024 && newSize > 2 * Heap::markedObjectSize();
     }
     // Otherwise, trigger a conservative GC on a 400% increase in size since
     // the last GC, but not for less than 32 MB. We set the higher limit in
     // this case because Oilpan GC is unlikely to collect a lot of objects
     // without having a V8 GC.
     return newSize >= 32 * 1024 * 1024 && newSize > 4 * Heap::markedObjectSize();
 }
 
 void ThreadState::scheduleGCIfNeeded()
 {
     checkThread();
     // Allocation is allowed during sweeping, but those allocations should not
     // trigger nested GCs
-    if (isSweepingInProgress())
-        return;
+    if (isSweepingInProgress()) {
+        if (!Heap::isUrgentGCRequested() || !isSweepingScheduled())

[haraken, 2015/02/23 08:42:27]

Do we want to have the 'isSweepingScheduled()' check?

[sof, 2015/02/23 12:26:13]

I think we do as otherwise we would allow nested GCs?

[haraken, 2015/02/23 14:59:07]

How can it lead to nested GCs? Given that we clear the urgent GC flag at the
beginning of a GC, Heap::isUrgentGCRequested() will return false if we reach
here during the GC.

[sof, 2015/02/23 15:03:40]

If you're in the Sweeping state and you don't perform this check & the urgent-gc
has been set by some external agent, you'll fall into doing a nested
conservative GC below. 

[haraken, 2015/02/23 15:06:22]

Thanks, makes sense.

It seems more straightforward (and robust) to add some logic to
Heap::collectGarbage to prevent nested GCs. (e.g., Add a check to prevent
GCScope from getting nested.)

[sof, 2015/02/23 15:22:40]

Having that "is-allowed" check in an already conditional scheduling operation
(scheduleIfNeeded()), seems reasonable to me. i.e., like before/right now.

+            return;
+        // Urgent GC requested with only a GC scheduled; fall through
+        // and have it be serviced by a conservative GC.
+    }
     ASSERT(!sweepForbidden());
 
-    if (shouldForceConservativeGC())
-        Heap::collectGarbage(ThreadState::HeapPointersOnStack, ThreadState::GCWithoutSweep);
-    else if (shouldSchedulePreciseGC())
+    if (shouldForceConservativeGC()) {
+        // If GC is deemed urgent, eagerly sweep and finalize any external allocations right away.
+        GCType gcType = Heap::isUrgentGCRequested() ? GCWithSweep : GCWithoutSweep;
+        Heap::clearUrgentGC();

[haraken, 2015/02/23 08:42:27]

Would it be better to move clearUrgentGC() into Heap::collectGarbage()?
Otherwise, the following scenario can happen:

1) An urgent GC is scheduled
2) Heap::collectGarbage() runs for some reason.
3) shouldGCIfNeeded() is called.
4) An urgent GC is invoked.

[sof, 2015/02/23 12:26:13]

That makes good sense to do for the cases where urgent GCs are externally
requested. And it is actually already done via resetHeapCounters(), so the
clearing here shouldn't be done (and will be redundant, typically.)

+        Heap::collectGarbage(HeapPointersOnStack, gcType);
+        return;
+    }
+    if (shouldSchedulePreciseGC())
         schedulePreciseGC();
     else if (shouldScheduleIdleGC())
         scheduleIdleGC();
 }
 
 void ThreadState::performIdleGC(double deadlineSeconds)
 {
     ASSERT(isMainThread());
 
     m_hasPendingIdleTask = false;
@@ skipping 611 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