Oilpan: move 2D Canvas and WebGL objects to the heap.

Source/core/html/canvas/WebGLContextGroup.h

Index: Source/core/html/canvas/WebGLContextGroup.h
diff --git a/Source/core/html/canvas/WebGLContextGroup.h b/Source/core/html/canvas/WebGLContextGroup.h
index 6c2f995354013332bda0e70ba332cefb2c2f7aec..7631e79b2e689c9e33af5af4af5531ea1587c2f8 100644
--- a/Source/core/html/canvas/WebGLContextGroup.h
+++ b/Source/core/html/canvas/WebGLContextGroup.h
@@ -58,13 +58,19 @@ public:
 
     void loseContextGroup(WebGLRenderingContextBase::LostContextMode);
 
-  private:
+private:
     friend class WebGLObject;
 
     WebGLContextGroup();
 
     void detachAndRemoveAllObjects();
 
+    // FIXME: Oilpan: this object is not on the heap, but keeps bare

[Mads Ager (chromium), 2014/07/11 06:47:23]

Could you update the comment with the reason why we are not using oilpan pointer
types here? Lead to leaks through RefPtr/Persistent chains? When this object is
moved to the oilpan heap should these just be normal HeapHashSet<Member<T> >?

[sof, 2014/07/11 09:42:02]

It's covered in the review why this collection (and owning object) is really
quite tricky to keep on the heap, but will certainly try to.

[Mads Ager (chromium), 2014/07/11 10:18:52]

I guess my question boils down to whether or not these could be:

WillBePersistentHeapHashSet<RawPtrWillBeMember<WebGLRenderingContextBase> >

That might lead to leaks, not sure. Off-heap collections of raw pointers is
something we should avoid if we possibly can. :)

[sof, 2014/07/14 11:47:53]

That persistent reference would keep the rendering context(s) alive, so wouldn't
be workable.

Hmm, looking closer at how WebGLContextGroup is currently used.. the above set
only ever has one entry, which is the rendering context object creating it (and
keeping a RefPtr.) Is that because WebGLContextGroup will be generalized to hold
multiple rendering contexts in the future, or that it previously did? If the
former, then I believe we can get rid of this abstraction and make
WebGLSharedObjects be quite similar to WebGLContextObjects in terms of resource
finalization.

WebGL folks: could you comment on that, please?

[sof, 2014/07/14 13:58:45]

Tried this locally & it works out.

The single-rendering-context-WebGLContextGroup use is something that ager also
discovered; so, does WebGLContextGroup still have a role to play?

+    // pointers to garbage collected objects in the two hash sets
+    // below. The objects are responsible for managing their
+    // registration with WebGLContextGroup, and vice versa, the
+    // WebGLContextGroup takes care of detaching the group objects if
+    // the set of WebGLRenderingContextBase contexts becomes empty.
     HashSet<WebGLRenderingContextBase*> m_contexts;

[Mads Ager (chromium), 2014/07/11 09:15:01]

I think I might be confused, but based on my searching in the code I cannot
figure out how there can ever be more than one context in m_contexts. The only
place that I can find that adds anything to m_contexts is one call right after
the context group has been created:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

It looks like this could just be a pointer that is set on creation instead of a
set? Am I missing something?

     HashSet<WebGLSharedObject*> m_groupObjects;
 };