For WebGL we have a few optimal times to trigger the GC while we're waiting on the GPU to resolve the frame. During that time the CPU is free to useful work but we don't have a way to schedule work without hitting the event loop and we can't do that because layout requires us to rebuild a display list which is a transient structure. If we can schedule a GC to run during that waiting period within a Layer Manager transaction then it should be a win. The problem is we don't have a clear idea how long the GPU will take, but if we implement this carefully we are probably better off putting a GC there then inserting it randomly using a timer. My questions: 1) Can I invoke a GC from any point, particularly from layers code (main thread code, no JS frames active)? 2) Should we invoke GC after each WebGL frame if it can stay within a ~5ms timeframe? 3) If we can't do 2) then it's likely still better to schedule it there then schedule it based on a timer so we'd need to see if a GC is incoming, do it before the glFinish and reset the gc timer.

To summarize the discussion I had with Luke about this on IRC: - We think that GC should be callable from the layers code. - We should able to provide a callback to the JS engine it could use the check if the frame is resolved. Incremental GC can check the callback during each slices and stop once the frame is ready.

I'm inclined for now to try a quick and dirty 'os.notifyObservers(null, "child-gc-request", null);' before a resolve. Maybe only run it some of the time. Does anyone have a webgl demo that is impacted by GC?

Try any sizeable non-emscripten WebGL demo? Such as http://webglsamples.googlecode.com/hg/aquarium/aquarium.html