Allow Oilpan heap objects account for their external allocations.

Source/core/dom/Text.cpp

Index: Source/core/dom/Text.cpp
diff --git a/Source/core/dom/Text.cpp b/Source/core/dom/Text.cpp
index 1436baa977b7a440d3554a1f7f4f834e3726ec11..fdefd7b29afc312a7fc5b1f93bdfa6c497e2d7cc 100644
--- a/Source/core/dom/Text.cpp
+++ b/Source/core/dom/Text.cpp
@@ -44,6 +44,11 @@ namespace blink {
 
 PassRefPtrWillBeRawPtr<Text> Text::create(Document& document, const String& data)
 {
+#if ENABLE(OILPAN)
+    size_t length = data.length();
+    if (length > 48)
+        Heap::increaseExternallyAllocatedBytes(length);

[haraken, 2015/02/10 01:23:17]

Would it be possible to use these memory APIs in PartitionAlloc, not in Blink
code? (If it's not trivial to balance increaseExternallyAllocatedBytes and
decreaseExternallyAllocatedBytes, we can start with just issuing Heap::urgentGC
when PartitionAlloc is reaching a limit.)

[sof, 2015/02/11 15:58:25]

PartitionAlloc would have to know that it was an Oilpan-initiated
allocation..and deallocation. Having it separately signal memory pressure by
setting the urgent-gc flag would be helpful, but would require some
thought/coordination.

To my mind, external allocation accounting can be beneficial for "externally
heavy" Oilpan objects & have those guide GC scheduling. Accounting for every
allocation adds overhead and is too fine grained a measurement, i feel.

+#endif
     return adoptRefWillBeNoop(new Text(document, data, CreateText));
 }
 
@@ -408,6 +413,15 @@ PassRefPtrWillBeRawPtr<Text> Text::cloneWithData(const String& data)
     return create(document(), data);
 }
 
+void Text::trace(Visitor* visitor)
+{
+    size_t length = m_data.length();
+    if (length > 48)
+        Heap::increaseExternallyAllocatedBytesAlive(length);

[haraken, 2015/02/10 01:23:17]

It looks dangerous to call increaseExternallyAllocatedBytesAlive here since it
can trigger a nested GC inside a marking phase...

BTW, if we follow the AjustExternalAmountOfMemory API of V8,
"externallyAllocatedBytes" should keep track of the amount of memory currently
used in the embedder side, not the amount of memory allocated since the last GC.

[sof, 2015/02/11 15:58:25]

As is, re-up'ing the allocation during tracing cannot trigger a GC.

+
+    CharacterData::trace(visitor);
+}
+
 #ifndef NDEBUG
 void Text::formatForDebugger(char *buffer, unsigned length) const
 {