1323087 - Minimize the number of objects marked gray

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 2

[Andrew McCreight [:mccr8]]

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?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

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.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

There is a major regression too currently, bug 1323226

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 6

[Andrew McCreight [:mccr8]]

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.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

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