975503 - Optimize incremental roots out of the CC graph

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I'm trying to figure out how to make the CCs faster in Mochitest-browser-chrome, to avoid timeouts with ICC enabled, and it looks to me that at least a number of the things in the graph are being rooted by windows and documents (for things like chrome://browser/content/pageinfo/pageInfo.xul and chrome://browser/content/browser.xul) in the purple buffer.

I need to compare the behavior with ICC to without. It is possible that we're just not doing a good job of optimizing these out of the graph normally, or that we frequently have windows/documents that can't be optimized out of the graph at the start of a CC, but they end up getting touched during the ICC.  If it is the latter, I'll have to come up with some kind of way to optimize them out of the graph.

Comment 1

[Andrew McCreight (out of office until 8/21) [:mccr8]]

This is in fact the fault of ICC.  With ICC disabled, the CC graph has about 2000 things in it.  With it enabled, it has more like 20,000 things in it.  I've hacked in some optimizations which seems to get the graph size down, though I haven't measured how long it takes.  I also need to examine why those garbage documents are being touched, as maybe we can avoid it somehow.

Comment 2

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I think the solution here is actually much simpler.  The problem appears to be that every time it Observes  the DOM_WINDOW_DESTROYED_TOPIC, the nsWindowMemoryReporter dispatches a runnable to the current thread that checks for ghost windows.  I assume that a runnable usually runs pretty quickly.  The runnable, if we're in the middle of a CC, touches every window, which means they won't be collected, but we still end up tracing through the whole thing, making the graph huge.

Simply redispatching the runnable if we're in the middle of an ICC seems to bring down the CC graph size to normal, though really, it might be good to have some kind of delay on this runnable anyways even without ICC, as firing off the ghost window detector constantly during bc doesn't seem useful.

Comment 3

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I think not running the ghost window reporter during ICC will be sufficient to fix this problem, and I'll just deal with that over in bug 977940.

Comment 4

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Attachment: Add code to optimize stuff out of the graph during ICC, commented out. (WIP)

for posterity.