Allow Oilpan heap objects account for their external allocations.

Source/core/dom/Text.cpp

 /*
  * Copyright (C) 1999 Lars Knoll (knoll@kde.org)
  *           (C) 1999 Antti Koivisto (koivisto@kde.org)
  * Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009 Apple Inc. All rights reserved.
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
  * version 2 of the License, or (at your option) any later version.
  *
@@ skipping 26 matching lines @@
 #include "core/rendering/RenderText.h"
 #include "core/rendering/svg/RenderSVGInlineText.h"
 #include "core/svg/SVGForeignObjectElement.h"
 #include "wtf/text/CString.h"
 #include "wtf/text/StringBuilder.h"
 
 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));
 }
 
 PassRefPtrWillBeRawPtr<Text> Text::createEditingText(Document& document, const String& data)
 {
     return adoptRefWillBeNoop(new Text(document, data, CreateEditingText));
 }
 
 PassRefPtrWillBeRawPtr<Node> Text::mergeNextSiblingNodesIfPossible()
 {
@@ skipping 344 matching lines @@
         return;
     }
     textRenderer->setTextWithOffset(dataImpl(), offsetOfReplacedData, lengthOfReplacedData);
 }
 
 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
 {
     StringBuilder result;
     String s;
 
     result.append(nodeName());
 
     s = data();
     if (s.length() > 0) {
         if (result.length())
             result.appendLiteral("; ");
         result.appendLiteral("value=");
         result.append(s);
     }
 
     strncpy(buffer, result.toString().utf8().data(), length - 1);
 }
 #endif
 
 } // namespace blink