Introduce infrastructure for tracing ScriptWrappables.

third_party/WebKit/Source/bindings/core/v8/ScriptWrappableHeapTracer.h

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef ScriptWrappableHeapTracer_h
+#define ScriptWrappableHeapTracer_h
+
+#include <v8.h>
+#include <vector>
+
+namespace blink {
+
+class HeapObjectHeader;
+
+/**
+ * When this heap tracer is set to the v8::Isolate, the V8 will call it during
+ * its garbage collection. At the beginning, it will call TraceRoots, then
+ * repeatedly (as v8 discovers more wrappers) it will call TraceWrappableFrom,
+ * and at the end it will call ClearTracingMarks.
+ */
+class ScriptWrappableHeapTracer : public v8::EmbedderHeapTracer {
+public:
+    ~ScriptWrappableHeapTracer() override;
+    void TraceRoots(v8::Isolate*) override;
+    void TraceWrappableFrom(v8::Isolate*, const std::vector<std::pair<void*, void*>>& hiddenFieldsOfPotentialWrappers) override;
+    void TraceWrappableFrom(v8::Isolate*, v8::Persistent<v8::Object>* wrapper);
+    void AddHeaderToUnmark(HeapObjectHeader*);
+    void ClearTracingMarks(v8::Isolate*) override;
+private:
+    void TraceWrappableFrom(v8::Isolate*, std::pair<void*, void*> hiddenFields);
+    bool m_tracingInProgress = false;
+    std::vector<HeapObjectHeader*> m_headersToUnmark;

[haraken, 2016/04/13 12:26:22]

How is it guaranteed that Oilpan's GC does not happen while V8 is doing tracing?
(Maybe it's guaranteed at this point because you haven't implement incremental
marking?)

If that happens, the HeapObjectHeader* can be a stale pointer.

Actually this is (one of) the reasons I think it's not a good idea to use
Oilpan's header for the bit. Conceptually the bit should be set on
ScriptWrappabl. You can use the least significant bit of the ScriptWrappable
object.

[Marcel Hlopko, 2016/04/14 16:39:08]

Currently, there are no guarantees that oilpan gc does not happen, but I'm not
sure it is a problem. The fact that we marked a header means the object is
reachable from some wrapper. And for oilpan gc, all wrappers will keep their
script wrappables alive. Oilpan's reachability graph is supergraph of wrapper
reachability graph, therefore marked headers should not be deleted by the oilpan
gc. As long as oilpan doesn't move objects/headers, we should be fine. Or did I
miss something?

Using a bit in the ScriptWrappable is a good idea, however not all objects we
trace through are script wrappable. I am not aware of a cycle which would make
us trace forever, but still, we might visit non-wrappables multiple times. And
to be honest I have no idea what impact this can have in the real world,
therefore I lean to "safer" oilpan header marking.

Regarding the future plans for the incremental tracing, wrappable-marked objects
and objects on the marking queue should be considered as alive by oilpan. Wdyt?

[haraken, 2016/04/15 01:28:16]

Ah, good point. You're right.
Currently all ScriptWrappables are guaranteed to be on Oilpan's heap, but not
all DOM objects that are going to be traced by traceWrappers are on Oilpan's
heap. So you cannot assume that all objects that have traceWrappers() have
Oilpan's header. However, I think this is fixable -- i.e., it would be possible
to move all those objects to Oilpan's heap.

BTW, how are you planning to implement an incremental marking? Assume that we
have the following object graph in the DOM side. Also assume that all the
objects are on Oilpan's heap:

  ScriptWrappable1 => NonScriptWrappable1 => NonScriptWrappable2 =>
ScriptWrappable2

If a mutator (i.e., Blink) updates the object graph as follows during the
incremental marking, how can we detect it?

  ScriptWrappable1 => NonScriptWrappable1 => NonScriptWrappable3 => ...

Are you planning to implement a write/delete barrier to all Member<> updates in
Oilpan's heap?

In terms of performance, it would be unacceptable to insert write barriers to
all Member<> updates but acceptable to insert write barriers to selected
Member<>s (which get involved in traceWrappers()). However, it will require a
substantial amount of work in Oilpan's infrastructure.

[Marcel Hlopko, 2016/04/15 07:27:15]

Sad, I was hoping the DOMArrayBuffer and DOMArrayBufferView were the last
relevant not on the oilpan heap, they were only last script wrappables, right?
But then moving the object to oilpan (especially if they are going to be moved
anyway) is the cleanest solution.

For the incremental marking, our plan is to manually insert write barriers into
the relevant places, which will be time consuming and bug prone. We definitely
don't want to add write barriers to all oilpan writes (by e.g. hooking into
Member somehow). I will polish the design doc and send you a link so we can have
more visible discussion there.

+};
+
+} // namespace blink
+
+#endif // ScriptWrappableHeapTracer_h