[wrapper-tracing] WebGLRenderingContextBase: Fix wrapper tracing

third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp

Index: third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
diff --git a/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp b/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
index 9240884ee8718c62410b7b6dca462d0dcfef5044..7ea80ad0484aa98d78bfe695e090660ba34346fe 100644
--- a/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
+++ b/third_party/WebKit/Source/modules/webgl/WebGLRenderingContextBase.cpp
@@ -7676,9 +7676,7 @@ DEFINE_TRACE(WebGLRenderingContextBase) {
 }
 
 DEFINE_TRACE_WRAPPERS(WebGLRenderingContextBase) {
-  if (isContextLost()) {

[Michael Lippautz, 2016/12/07 08:36:11]

I need some help with proper semantics here: It is now possible to revive a
rendering context, right? E.g. the state without a context can only be
transient. If so, then we should trace wrappers no matter what.

(This was copied from regular Oilpan tracing but it has been removed there.)

-    return;
-  }
+  visitor->traceWrappers(m_contextGroup);

[Michael Lippautz, 2016/12/07 08:36:11]

The context group is TraceWrapperBase which indicates we should trace wrappers
through its contexts.

However, I don't see an IDL file and m_contextGroup is also not part of
WebGLRenderingContextBase::visitChildDOMWrappers, so I am not sure what the
expected behavior is.

[haraken, 2016/12/07 09:06:29]

kbr@: Would you help me understand why we need to trace m_contextGroup? This is
doing something strange because  WebGLContextGroup::m_contexts is a hash map of
weak members. We're tracing the members weakly in oilpan but strongly in V8.

(We're doing the strange thing in Document::m_nodeLists but that's a very
special case.)

[Ken Russell (switch to Gerrit), 2016/12/07 09:22:37]

WebGLRenderingContextBase strongly owns WebGLContextGroup. WebGLContextGroup
maintains weak references back to the WebGLContextBases. (Right now there is
only a 1:1 mapping. We will probably get rid of WebGLContextGroup, at which
point the lifetimes will be a lot simpler)

WebGLObjects maintain strong references to *either* their allocating
WebGLRenderingContextBase, or WebGLContextGroup, depending on whether they
conceptually are per-context or per-share-group objects.

WebGLContextGroup isn't a concept publicly visible to JS. However, we must trace
from WebGLSharedObject to its WebGLContextGroup, and from there to any
WebGLRenderingContextBase objects in that WebGLContextGroup.

   visitor->traceWrappers(m_boundArrayBuffer);
   visitor->traceWrappers(m_renderbufferBinding);
   visitor->traceWrappers(m_framebufferBinding);