Oilpan: have Storage objects reside on the heap by default.

Source/modules/storage/DOMWindowStorage.h

 // Copyright 2015 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 DOMWindowStorage_h
 #define DOMWindowStorage_h
 
 #include "core/frame/DOMWindowProperty.h"
 #include "platform/Supplementable.h"
 #include "platform/heap/Handle.h"
@@ skipping 16 matching lines @@
     Storage* localStorage(ExceptionState&) const;
     Storage* optionalSessionStorage() const { return m_sessionStorage.get(); }
     Storage* optionalLocalStorage() const { return m_localStorage.get(); }
 
     DECLARE_TRACE();
 
 private:
     explicit DOMWindowStorage(LocalDOMWindow&);
     static const char* supplementName();
 
-    LocalDOMWindow& m_window;
-    mutable RefPtrWillBeMember<Storage> m_sessionStorage;
-    mutable RefPtrWillBeMember<Storage> m_localStorage;
+    RawPtrWillBeMember<LocalDOMWindow> m_window;

[haraken, 2015/04/26 08:55:36]

Not related to your CL, we should probably provide a
HeapSupplement::supplementedObject() method that returns the supplemented object
(in this case, the LocalDOMWindow object). Then the supplementing object doesn't
need to hold a poniter to the supplemented object.

[sof, 2015/04/26 14:16:35]

I was thinking about the same thing this morning :), brought about by the
pattern pointed out here.

The current Supplement/able design is minimal, not keeping any extra state
per-supplement like a back pointer to the supplementable host. The thinking
being afaict that lifecycle observers should handle that instead, if such access
is needed.

But with the number of cases where such back pointers are in use, it's worth
considering. Could provide a derived version of Supplement<> which provides it,
where needed.

+    mutable PersistentWillBeMember<Storage> m_sessionStorage;
+    mutable PersistentWillBeMember<Storage> m_localStorage;
 
 };
 
 } // namespace blink
 
 #endif // DOMWindowStorage_h