Oilpan: make DOMWindowProperty a GC mixin.

Source/core/frame/DOMWindowProperty.h

Index: Source/core/frame/DOMWindowProperty.h
diff --git a/Source/core/frame/DOMWindowProperty.h b/Source/core/frame/DOMWindowProperty.h
index eb3542d30b268ca52d08918fd0ff5ce28a1d52ef..2666f88c0fe13096ea5714ecf1f10fff7d89652a 100644
--- a/Source/core/frame/DOMWindowProperty.h
+++ b/Source/core/frame/DOMWindowProperty.h
@@ -26,12 +26,14 @@
 #ifndef DOMWindowProperty_h
 #define DOMWindowProperty_h
 
+#include "platform/heap/Handle.h"
+
 namespace blink {
 
 class LocalDOMWindow;
 class LocalFrame;
 
-class DOMWindowProperty {
+class DOMWindowProperty : public WillBeGarbageCollectedMixin {
 public:
     explicit DOMWindowProperty(LocalFrame*);
 
@@ -40,11 +42,15 @@ public:
 
     LocalFrame* frame() const { return m_frame; }
 
+    virtual void trace(Visitor*);
+
 protected:
+#if !ENABLE(OILPAN)
     virtual ~DOMWindowProperty();
+#endif
 
     LocalFrame* m_frame;

[haraken, 2014/09/10 02:49:36]

How is it guaranteed that this m_frame does not become a stale pointer?

[sof, 2014/09/10 05:49:40]

It will be non-null if the LocalDOMWindow is somehow not frameDestroyed() before
being finalized. It can only be finalized if any of its DOMWindowProperty are no
longer references (cf. strong reference on the the next line here.)

=> LocalDOMWindow and DOMWindowProperty will die together. Not clearing m_frame
will not be observable, and it cannot be used as a stale reference.

We can loosen the connection and make the LocalDOMWindow back reference weak,
but I don't think it is called for. wdyt?

[Mads Ager (chromium), 2014/09/10 06:34:13]

My two cents: We should avoid using weakness if we can. It seems to me that a
DOMWindowProperty should keep the DOMWindow it is a property of alive. I would
keep the strong relationship.

[haraken, 2014/09/10 07:46:53]

Agreed. I prefer keeping the bi-directional strong references between
LocalDOMWindow and DOMWindowProperty.

However, what confuses me is that you are using WeakMember<LocalFrame> in your
original move-Frame-to-the-heap CL
(https://codereview.chromium.org/517043003/diff/380001/Source/core/frame/DOMWi...).
Doesn't it mean that DOMWindowProperty outlives the LocalFrame?

What's a lifetime relationship between LocalFrame, DOMWindowProperty and
DOMWindow?

[sof, 2014/09/10 08:21:37]

Yes, some tests (all resource leak related, i think) fail if you don't keep it
as such. i.e., if you externally close the frame, but keep other references to
its contained DOMWindow, you can observe the frame as alive. If that isn't a
weak reference.

I decided not to try to overturn that behavior.
What specifically do you want to know? This is such a huge question to pose.

[haraken, 2014/09/10 08:34:42]

Thanks. What I want to understand is why the following situation cannot happen:

- LocalFrame dies but LocalDOMWindow and DOMWindowProperties are still alive.
Then the m_frame becomes a stale pointer (until you move the Frame to the heap
and use a WeakMember).

-    LocalDOMWindow* m_associatedDOMWindow;
+    RawPtrWillBeMember<LocalDOMWindow> m_associatedDOMWindow;
 };
 
 }