[oilpan] Move IDBDatabase, IDBDatabaseCallbacks, IDBDatabaseBackendInterface and other related clas…

Source/modules/indexeddb/IDBDatabaseCallbacksImpl.h

Index: Source/modules/indexeddb/IDBDatabaseCallbacksImpl.h
diff --git a/Source/modules/indexeddb/IDBDatabaseCallbacksImpl.h b/Source/modules/indexeddb/IDBDatabaseCallbacksImpl.h
index d4f2ca69c934d71bf01ff352df07aa3ec2e452dd..529f67186ae65dda134cba9f3f7bc2f586c5d925 100644
--- a/Source/modules/indexeddb/IDBDatabaseCallbacksImpl.h
+++ b/Source/modules/indexeddb/IDBDatabaseCallbacksImpl.h
@@ -36,7 +36,7 @@ class IDBDatabase;
 
 class IDBDatabaseCallbacksImpl : public IDBDatabaseCallbacks {
 public:
-    static PassRefPtr<IDBDatabaseCallbacksImpl> create();
+    static IDBDatabaseCallbacksImpl* create();
     virtual ~IDBDatabaseCallbacksImpl();
 
     // IDBDatabaseCallbacks
@@ -48,11 +48,13 @@ public:
 
     void connect(IDBDatabase*);
 
+    virtual void trace(Visitor*) const;
+
 private:
     IDBDatabaseCallbacksImpl();
 
     // The initial IDBOpenDBRequest or final IDBDatabase maintains a RefPtr to this
-    IDBDatabase* m_database;
+    Member<IDBDatabase> m_database;

[Mads Ager (chromium), 2013/11/28 10:24:46]

Here we are turning a raw (and therefore weak) pointer into a strong pointer
that keeps the database alive. I wonder if that can create a cycle involving a
persistents. In this changelist we have heap allocated objects that have ownptrs
to objects that contain persistents. So far I have only seen persistents used
where we used to have RefPtr, so that should be safe. However, this change from
raw to strong pointer might change that and create a cycle with Persistents in
it that cannot be reclaimed. We should draw a diagram of everything that points
to IDBDatabaseCallbacksImpl objects to see if such a cycle can occur.

[haraken, 2013/12/02 09:13:27]

Good point. I scanned the code base but it's unclear to me if this causes a
cycle or not. It's even harder to make sure that this won't cause a cycle in
future CLs as a side effect.

Probably would the following strategy be safe for our incremental replacement?

(1) Keep raw pointers as is.
(2) Once we move the entire hierarchy to the heap, we change the raw pointers
with Members.

 };
 
 } // namespace WebCore