Trial: build trunk with Oilpan everywhere.

third_party/WebKit/Source/core/frame/RemoteDOMWindow.h

 // Copyright 2014 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 RemoteDOMWindow_h
 #define RemoteDOMWindow_h
 
 #include "core/frame/DOMWindow.h"
 #include "core/frame/RemoteFrame.h"
 
@@ skipping 65 matching lines @@
     PassRefPtrWillBeRawPtr<CSSRuleList> getMatchedCSSRules(Element*, const String& pseudoElt) const override;
     int requestAnimationFrame(FrameRequestCallback*) override;
     int webkitRequestAnimationFrame(FrameRequestCallback*) override;
     void cancelAnimationFrame(int id) override;
     int requestIdleCallback(IdleRequestCallback*, const IdleRequestOptions&) override;
     void cancelIdleCallback(int id) override;
 
 private:
     explicit RemoteDOMWindow(RemoteFrame&);
 
-    RawPtrWillBeMember<RemoteFrame> m_frame;
+    RawPtrWillBeWeakMember<RemoteFrame> m_frame;

[haraken, 2015/11/30 01:48:47]

I'm wondering why this needs to be a weak member.

[sof, 2015/11/30 06:25:47]

The RemoteDOMWindow will turn into the global object (and have a wrapper holding
it alive) in some unit tests (frame "swap" tests involving remote frames.)

So once the RemoteFrame becomes detached, the WebRemoteFrameImpl object just
drops the reference to it. But it is still kept alive via the wrapper holding
onto the RemoteDOMWindow and consequently not finalized (which will take down
the wrapper & the RemoteDOMWindow.) Break the undesirable dependency by making
this weak.

A one line fix to a leak that it took some time to understand; I hope we don't
have to mirror the explicit protocol between LocalFrame <-> LocalDOMWindow as
far as destruction steps are concerned. But I have my doubts.

 };
 
 } // namespace blink
 
 #endif // DOMWindow_h