[wrapper-tracing] WebGLRenderingContextBase: Fix wrapper tracing

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

 /*
  * Copyright (C) 2009 Apple Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 7658 matching lines @@
   visitor->trace(m_boundVertexArrayObject);
   visitor->trace(m_currentProgram);
   visitor->trace(m_framebufferBinding);
   visitor->trace(m_renderbufferBinding);
   visitor->trace(m_textureUnits);
   visitor->trace(m_extensions);
   CanvasRenderingContext::trace(visitor);
 }
 
 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);
   visitor->traceWrappers(m_currentProgram);
   visitor->traceWrappers(m_boundVertexArrayObject);
   // Trace wrappers explicitly here since TextureUnitState is not a heap
   // object, i.e., we cannot set its mark bits.
   for (auto& unit : m_textureUnits) {
     visitor->traceWrappers(unit.m_texture2DBinding);
     visitor->traceWrappers(unit.m_textureCubeMapBinding);
@@ skipping 51 matching lines @@
 
 void WebGLRenderingContextBase::getHTMLOrOffscreenCanvas(
     HTMLCanvasElementOrOffscreenCanvas& result) const {
   if (canvas())
     result.setHTMLCanvasElement(canvas());
   else
     result.setOffscreenCanvas(getOffscreenCanvas());
 }
 
 }  // namespace blink