Introduce infrastructure for tracing ScriptWrappables.

third_party/WebKit/Source/core/dom/Node.idl

Index: third_party/WebKit/Source/core/dom/Node.idl
diff --git a/third_party/WebKit/Source/core/dom/Node.idl b/third_party/WebKit/Source/core/dom/Node.idl
index de0bfaef52be84cb820edb589438b3526acce912..c5e2f7af86c1346ecfbf6d6060ec188f3bd9ccb7 100644
--- a/third_party/WebKit/Source/core/dom/Node.idl
+++ b/third_party/WebKit/Source/core/dom/Node.idl
@@ -22,6 +22,7 @@
 
 [
     DependentLifetime,
+    TraceWrappableReferences=(ownerDocument,parentNode,parentElement,nextSibling,previousSibling,firstChild,maybeRareData)

[haraken, 2016/04/13 00:44:01]

Hmm. In your approach, developers need to do the following things:

1) Write a list of methods to be traced by the ScriptWrappableVisitor in an IDL
file.
2) If the method is not an existing const getter, implement the getter.
3) Add ScriptWrappableVisitor::accept(const T* data) as needed.

I'm a bit concerned about 2) because in long term we're planning to replace 
almost all [SetWrapperReferenceFrom/To], ScriptValues, ScopedPersistents in the
code base with the traceWrapper. Then we'll end up with implementing a lot of
getters.

Alternately I think it would be more straightforward to ask developers to write
traceWrapper methods in each C++ class. Also it is aligned with the tracing
model of Oilpan.

class Node {

void traceWrapper(ScriptWrappableVisitor* visitor) {
  visitor->trace(m_parent);
  visitor->trace(m_firstChild);
  visitor->trace(m_nodeRareData);
}

};

Also I'd like to keep the embedder-side tracing APIs as simple as possible. For
example, I want to remove the distinction between "trace", "mark", "visit" and
"accept", and the distinction between "traceWrapper" and "traceWrapperChildren".
We can do this by:

- making visitor->trace(T*) mark the object and call traceWrapper of the object
if T is ScriptWrappable
- making visitor->trace(T*) just call traceWrapper of the object if T is not
ScriptWrappable

What do you think?

[Marcel Hlopko, 2016/04/13 08:46:09]

Thank you for your wonderful comments!

To be honest, most of the "complexities" of visiting were relics of past
approaches and were plain needless in the current approach. So thank you for
catching that :)

I refactored the code, looking much better now. Ptal.

Regarding code generation, let me sum up the pros and cons:

pros:
* all 53 cases of SetWrapperReferenceFrom could be just sed-ded to
TraceWrappableReferences
* all 34 cases of SetWrapperReferenceTo could be sed-ded after refactoring in
https://codereview.chromium.org/1876843002
* for the rest of more than 1000 idl files, I don't have exact numbers, but the
feeling is, that most of the wrappable classes already have const getters
* declarative nature, "just tell us the dependencies and we will trace them for
you"
cons:
* inconsistency, some stuff is generated, some hand written
* inconsistency with oilpan, as all oilpan tracing methods are hand written
* you still have to update header file + idl file (instead of header file and
cpp file) - not a big win
* we need the refactoring in https://codereview.chromium.org/1876843002 to
generate traceWrappers for dom/Node and dom/Element, the most complex ones.

As there is not a huge win in generation, and you are against it, I will remove
it, if you haven't changed your mind :)

p.s.
I will cleanup V8 side naming (e.g. from TraceWrappablesFrom to
TraceWrappersFrom) once we land this cl.

 ] interface Node : EventTarget {
     const unsigned short ELEMENT_NODE = 1;
     // FIXME: Attr should not inherit from Node. crbug.com/305105