In the past, we've discussed a number of ways to make more objects be black (rather than gray). One that I remember is that dom::TraceBlackJS should mark all windows in the bfcache black rather than just the active one. There may be other places. Olli, Andrew, do you remember any others? I'm filing this bug because tracing gray objects in the JS engine is non-incremental, and we're finding in bug 1314828 that it's slow. We can try to make it incremental, but it would be easier to just avoid tracing as many gray objects.

Don't we basically want to try to move as much as possible http://searchfox.org/mozilla-central/rev/5ee2bd8800b007d6c120d9521d5bf01131885afb/dom/base/nsCCUncollectableMarker.cpp#449-465 to happen during black marking. The question is how and how slow it would become. We have those different states because those are slow operations http://searchfox.org/mozilla-central/rev/5ee2bd8800b007d6c120d9521d5bf01131885afb/dom/base/nsCCUncollectableMarker.cpp#438-444 I wonder, could we re-purpose mMarkedCCGeneration in nsIDocument to cover also GC, and then after marking documents, at least some black marking could be done to nodes' event listeners and such. (but then, the hashtable containing event listener mananagers for nodes can be *huge*) UnmarkGrayStrongObservers() at least should be easy to move to black marking.

I'd theorize that if you are only looking at the most terrible GCs, then you are probably looking at cases where we have ghost windows and entire compartments are getting marked gray. I don't think trimming around the margins is going to help all that much. Is this only marking roots gray that is non-incremental, or is it all gray marking?

That sounds likely indeed. Though UnmarkGrayStrongObservers() is still possibly one case where large-ish areas of JS heap stay gray even though it could _always_ be black.

There is a major regression too currently, bug 1323226

I did some further analysis of the ghost window issue. First I only looked at GCs where the max_pause >= 100ms. Then I classified them on two axes: 1. Was the bad pause time caused by mark_gray or mark_gray_and_weak. This is based on whether the slowest slice would be <= 40ms if the mark_gray and mark_gray_and_weak times are subtracted off. 2. Were there any ghost windows in the report? This is how it broke down: 0 ghost windows >=1 ghost windows mark_gray slow 5086 3824 mark_gray not slow 64444 31253 So when mark_gray is slow, 57% of GCs happen with no ghost windows. When mark_gray is not slow, 67% of GCs happen with no ghost windows. So there might be some correlation, but I don't think it's very strong.

That's good to know. I also realized later when talking to Bill that we also have a lot of gray in a GC after we close a tab, and there's not a lot that can be optimized out of that, and it won't be a ghost window.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information