Oilpan: move DOMWindow object to the oilpan heap.

Source/bindings/v8/V8DOMWrapper.h

Index: Source/bindings/v8/V8DOMWrapper.h
diff --git a/Source/bindings/v8/V8DOMWrapper.h b/Source/bindings/v8/V8DOMWrapper.h
index 589599613bd9f94db0b21463db2470d7bfccc05f..8c8e4f3148ead7fca9f9a00d46305e7b840fa3ff 100644
--- a/Source/bindings/v8/V8DOMWrapper.h
+++ b/Source/bindings/v8/V8DOMWrapper.h
@@ -52,6 +52,7 @@ struct WrapperTypeInfo;
         template<typename V8T, typename T>
         static inline v8::Handle<v8::Object> associateObjectWithWrapper(T*, const WrapperTypeInfo*, v8::Handle<v8::Object>, v8::Isolate*, WrapperConfiguration::Lifetime);
         static inline void setNativeInfo(v8::Handle<v8::Object>, const WrapperTypeInfo*, void*);

[haraken, 2014/03/26 08:16:10]

Another thing I'm considering is we want to cause compile error if
setNativeInfo() is called for GarbageCollected objects. Currently it doesn't
cause compiler errors and we cannot notice the issue until we really create a
wrapper and hit the ASSERT in line 68. I have hit the issue a couple of times so
far.

+        static inline void setNativeInfoGarbageCollected(v8::Handle<v8::Object>, const WrapperTypeInfo*, void*);
         static inline void setNativeInfoWithPersistentHandle(v8::Handle<v8::Object>, const WrapperTypeInfo*, void*, PersistentNode*);
         static inline void clearNativeInfo(v8::Handle<v8::Object>, const WrapperTypeInfo*);
 
@@ -70,6 +71,20 @@ struct WrapperTypeInfo;
         wrapper->SetAlignedPointerInInternalField(v8DOMWrapperTypeIndex, const_cast<WrapperTypeInfo*>(type));
     }
 
+    // Identical to setNativeInfo() but for the "is GCed" assert.
+    inline void V8DOMWrapper::setNativeInfoGarbageCollected(v8::Handle<v8::Object> wrapper, const WrapperTypeInfo* type, void* object)

[haraken, 2014/03/26 01:13:32]

The GC interaction between V8 and oilpan is complicated, so I'm not really happy
to add one more version of setNativeInfo. (We really need to be careful about
what should do in derefObject() -- whether we should call deref() or we should
delete a persistent handle or we should do nothing.)

Instead of introducing setNativeInfoGarbageCollected, can we just use
setNativeInfoWithPersistentHandle? We'll need to create multiple persistent
handles for one DOMWindow wrapper (one persistent handle for one hidden
prototype chain), but it would be OK because # of DOMWindow objects are limited.

[sof, 2014/03/26 06:36:46]

I did explore that option. Handful of tests were leaking documents (rather
badly) due to DOMWindows not being released.

[Mads Ager (chromium), 2014/03/26 07:29:43]

Yeah, the problem with that is that there is only one real wrapper that gets a
callback. Therefore, the extra allocated persistent handles will never be
deallocated. This was the same before. Only one of these objects (the real
wrapper object) performs a manual 'ref' of the native pointer and a manual
'deref' in the weak callback from V8 when the wrapper is gone. The other one
(inner global object) just has the raw pointer. That is OK because these objects
always live and die together. The inner global object and the DOMWindow cannot
be distinguished in JavaScript (the DOMWindow is a hidden prototype of the inner
global object that you cannot change and cannot get to).

I don't think we should mess with that setup. Maybe we can find a renaming that
makes it clear that this is a special case that we should not call otherwise.
Right now, the name suggests that this is the one you should call for garbage
collected objects. Maybe rename to setNativeInfoForInnerGlobalObject, make it
take a DOMWindow*, and add a comment that it is safe to not use a persistent
because the inner global object and the DOMWindow wrapper die together and the
DOMWindow wrapper holds a Persistent that keeps the DOMWindow alive until they
die?

[haraken, 2014/03/26 08:07:16]

Yeah. Given that DOMWindow is not the only object that has hidden wrappers
(e.g., HTMLDocument, DedicatedWorkerGlobalScope etc have hidden wrappers as
well), we can probably name it  "setNativeInfoForHiddenWrapper".

[sof, 2014/03/26 10:42:04]

...
I've renamed it so + added a comment (in V8WindowShell::installDOMWindow())
which
I hope captures reality precisely - please let me know. Thanks for detailed
explanation of the object relationships involved, ager.

The persistent field in this case wasn't being initialized; added that also.

+    {
+        ASSERT(wrapper->InternalFieldCount() >= 2);
+        ASSERT(object);
+        ASSERT(type);
+#if ENABLE(OILPAN)
+        ASSERT(type->isGarbageCollected);
+#endif
+        wrapper->SetAlignedPointerInInternalField(v8DOMWrapperObjectIndex, object);
+        wrapper->SetAlignedPointerInInternalField(v8DOMWrapperTypeIndex, const_cast<WrapperTypeInfo*>(type));
+    }
+
+
     inline void V8DOMWrapper::setNativeInfoWithPersistentHandle(v8::Handle<v8::Object> wrapper, const WrapperTypeInfo* type, void* object, PersistentNode* handle)
     {
         ASSERT(wrapper->InternalFieldCount() >= 3);