Last Comment Bug 726442 - [meta] Run the CC less often by removing childless nodes from the purple buffer
: [meta] Run the CC less often by removing childless nodes from the purple buffer
Status: RESOLVED FIXED
[Snappy:P2]
:
Product: Core
Classification: Components
Component: XPCOM (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 726252 726331 726340 727572 727625 728460
Blocks: 698919
  Show dependency treegraph
 
Reported: 2012-02-12 09:24 PST by Andrew McCreight [:mccr8]
Modified: 2012-05-20 12:35 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Andrew McCreight [:mccr8] 2012-02-12 09:24:04 PST
In bug 725377, Gregor noticed that the cycle collector runs every 5 seconds.  Using bug 726252, I noticed that this was due entirely due to childless nodes being added to the purple buffer.

Childless nodes in the cycle collector graph can't be part of a garbage cycle.  Because of this, we don't need to suspect them.  Due to incomplete unlinking, we still may want to add them to the CC graph, should some other suspected node reach them and turn out to be garbage.

These nodes don't have a particularly huge impact on the size of the graph: their primary negative impact is causing the CC to run more often.  We can give these classes a CanSkip (which decides when to remove things from the purple buffer in between CCs) and maybe a CanSkipInCC (which decides when to remove things from the purple buffer at the start of a CC), but leave their CanSkipThis behavior alone (which decides when a node should be added to the CC graph).
Comment 1 Andrew McCreight [:mccr8] 2012-02-13 20:31:59 PST
Another category of things we can remove from the purple buffer are XPConnect roots: they are going to be added anyways, so there's no need to remember them in the purple buffer.
Comment 2 Andrew McCreight [:mccr8] 2012-02-14 11:59:11 PST
Here are the top childless nodes that show up in the purple buffer, from scrolling around on TechCrunch:

      72 nsDOMCSSAttributeDeclaration

     174 nsGenericElement (XUL)
      93 nsDOMCSSAttributeDeclaration
      67 nsBindingManager
      52 nsDOMAttributeMap

     682 nsDOMEvent
     264 nsGenericElement (XUL)
      95 nsEventStateManager
      94 nsBindingManager

     171 nsDOMCSSAttributeDeclaration
     138 nsGenericElement (XUL)
      89 nsBindingManager
      82 nsBaseContentList
      60 nsDOMAttributeMap

      80 nsBindingManager

This is with my fix for nsComputedDOMStyle and ChildContent.
Comment 3 Olli Pettay [:smaug] (reviewing overload) 2012-02-14 12:02:30 PST
Was there a GC before CC when nsDOMEvent showed up in the purple buffer?
Comment 4 Olli Pettay [:smaug] (reviewing overload) 2012-02-14 12:03:41 PST
...since I would expect DOMEvents to be deleted right after gc.
Comment 5 Andrew McCreight [:mccr8] 2012-02-14 13:06:53 PST
I don't know, sorry.
Comment 6 Andrew McCreight [:mccr8] 2012-02-14 14:59:48 PST
P1 because I think we can pick up some easy wins here.  We're pretty bad right now about how often we run the CC (even though it is faster), and knocking out 3 or 4 of these junky classes from the purple buffer could help a lot.
Comment 7 Andrew McCreight [:mccr8] 2012-02-14 21:02:16 PST
https://tbpl.mozilla.org/?tree=Try&rev=7664fb2957e4
Try run that adds purple buffer removal for childless nsComputedDOMStyles, nsChildContentList and nsDOMCSSAttributeDeclaration.
Comment 8 Andrew McCreight [:mccr8] 2012-03-06 15:32:24 PST
Should be fixed completely by bug 728460. We can still come up with other clever ways to remove boring things from the purple buffer, but CCs triggered by GCs are probably a bigger issue.

Note You need to log in before you can comment on or make changes to this bug.