This is another pattern that shows up very frequently on my simple test case of Gmail + error console: there's an nsXBLDocumentInfo that appears to be live, but it contains an nsXBLDocGlobalObject that points to a JSContext that points to another JSContext, which points to an "nsXBLPrototypeScript compilation scope" object, that reaches about 45 JS objects. I think we can extend the CanSkip function for nsXBLDocumentInfo to reach through that chain and unmarkGray what the JSContext holds onto. I see about a dozen of these in my CC graph, so that could be another 540 nodes we could get rid of.
I should probably also just make nsXBLDocumentInfo into a skippable class, as there are a dozen or so in the graph with no children.
I just piggybacked on nsXBLDocumentInfo::MarkInCCGeneration instead of turning nsXBLDocumentInfo into a skippable class. I think we should use a more general solution for childless nodes.
Created attachment 606787 [details] [diff] [review] mark global held by live XBLDocInfo
Comment on attachment 606787 [details] [diff] [review] mark global held by live XBLDocInfo This had a good try run with some of my other patches. https://tbpl.mozilla.org/?tree=Try&rev=869ed959b506 In the medium term, I want to move all of these two unmarking functions that MarkInCCGeneration (unmark protos and unmark script context) into the GC. If you think it makes sense, Olli, I can just directly do that instead of having this intermediate bug.
Comment on attachment 606787 [details] [diff] [review] mark global held by live XBLDocInfo We could do this now.
Thanks for the reviews. https://hg.mozilla.org/integration/mozilla-inbound/rev/7c0ac8201f4e