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.
Assignee: nobody → continuation
Attachment #605841 - Attachment is obsolete: true
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.
Attachment #606787 - Flags: review?(bugs)
Comment on attachment 606787 [details] [diff] [review] mark global held by live XBLDocInfo We could do this now.
Attachment #606787 - Flags: review?(bugs) → review+
Thanks for the reviews. https://hg.mozilla.org/integration/mozilla-inbound/rev/7c0ac8201f4e
Target Milestone: --- → mozilla14
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.