Open Bug 698919 Opened 8 years ago Updated Last year

[meta] specific improvements to reduce impact of the cycle collector on responsiveness


(Core :: XPCOM, defect)

Not set




(Reporter: mccr8, Unassigned)


(Depends on 8 open bugs)


(Keywords: meta, perf)

The cycle collector can cause unpleasant pause times, especially when things get leaky.  We should attempt to both reduce the length of those pauses (by improving cycle collector performance and investigating incremental approaches), and make them less annoying by being smarter about when and if we schedule the cycle collector to run.

We should also gather together bug reports where people report long CC pause times, but maybe it would make more sense to track that in a separate bug.

For reference, when I measured the cycle collector time (using shark and time logging), with a few tabs and some browsing around, cycle collector time was dominated by building the graph.  Most of the time graph building takes about 90% of the 40ms to 120ms ish cycle collector time.  Sometimes unlinking takes about a third of the cycle collector time, presumably when we close a tab and the CC has to free a bunch of things.  At the first shutdown CC, unlinking takes more time than building the graph, but I think that's unusual.  Of course, these "normal" CC times may not reflect the breakdown when things are getting slow, but they are a starting point.
Summary: reduce impact of cycle collector on responsiveness → [meta] reduce impact of cycle collector on responsiveness
Keywords: perf
There's also bug 646941 (which I haven't confirmed because I haven't seen these pauses since Firefox 3.6). Should this one be marked a dupe?
No, this is a meta bug for tracking various specific approaches for reducing the impact of cycle collector pause times.  It would probably be good to have a separate meta bug for tracking various instances of the CC/GC getting slower.  Unfortunately, those tend to be very hard to figure out.
Summary: [meta] reduce impact of cycle collector on responsiveness → [meta] specific steps to reduce impact of the cycle collector on responsiveness
Summary: [meta] specific steps to reduce impact of the cycle collector on responsiveness → [meta] specific improvements to reduce impact of the cycle collector on responsiveness
Depends on: 653013
There's going to be a meeting tomorrow on improving/measuring browser responsiveness:

I'll attend and take notes on cycle collector related things that are discussed.
Depends on: 697134
Randell Jesup saw TraverseExpandoObjects() take up a huge amount of time in a long CC in bug 696761, and Peter thinks Bug 700668 will help reduce that.
Depends on: 700668
In terms of figuring out where we are spending time, Smaug says "looks like in some cases unlinking takes more time than unroot, but not always. And rooting is quite cheap".
Depends on: 701878
Depends on: 702032
Depends on: 702813
Whiteboard: [Snappy]
Depends on: 705128
Depends on: 705272
Depends on: 706164
Depends on: 705582
Depends on: 377787, 549533
I guess I'll mark this as [Snappy:P1], as the cycle collector is a big source of pauses, but I'm not sure if a meta bug is appropriate for tracking like this or not.
Whiteboard: [Snappy] → [Snappy:P1]
Assignee: nobody → continuation
Depends on: 710496
Whiteboard: [Snappy:P1] → [Snappy:P1] (we should snappy nom and priority sub bugs)
Whiteboard: [Snappy:P1] (we should snappy nom and priority sub bugs) → [Snappy:P1]
Depends on: 712704
Depends on: 712735
Depends on: 713865
Depends on: 713462
Depends on: 714162
Depends on: 714250
Depends on: 714642
Depends on: 716006
Depends on: 716004
Depends on: 716598
Moved a bunch of these bugs into a sub-meta-bug.
No longer depends on: 712735, 714642, 716004, 700668, 705272, 713462, 713865, 714162, 714250, 716006
Depends on: 717711
Depends on: 722715
No longer depends on: 722715
Depends on: 716014
Depends on: 726442
Depends on: 726509
Depends on: 727965
Depends on: 730581
Depends on: 734890
Depends on: 741417
I guess it's now effective on nightly because ffx  has massively improved its score on the spinning balls v8 bench (

A few weeks ago, I had around 800ms delays each 7 seconds (even after Incremental GC activation) and now the biggest one is around 400ms.

You made a wonderful work and without loosing this big part (1/3) of balls managed in less than 20ms.

Bravo and merci to make the web ( so mine :) ) better!
Thanks for the feedback!  Personally, at least when testing with nothing else open in my browser, it was always GC pauses that were happening, not CC.  billm has landed a number of GC improvements over the last few weeks to improve incremental GC, so that's probably more to blame for your improvement than any changes to the CC we have made.
Ok thanks for the explanation and for your work, of you and billm, again.
I just thought that a better cycles management meant less garbage to deal with for the CG (but I have not enough time to go deep in FFX's sources to be sure).

Anyway, it's a pleasure to see the fast evolution of Mozilla.
Depends on: 744103
Noming for Kilimanjaro blocking due to the requirement "Content performance (gc+cc pauses and fps)". Note that there may be a more specific subset of this work that we actually want to target.
Blocks: k9o-perf
blocking-kilimanjaro: --- → ?
It is probably bug 741417, since when there are no cycles to collect, CC time should be
reasonable low, almost low enough.
Dropping Kilimanjaro nom from this bug in favour of bug 741417 and bug 728407 as suggested by Olli.
No longer blocks: k9o-perf
blocking-kilimanjaro: ? → ---
Depends on: 749201
Depends on: 722089
Depends on: 747675
Depends on: 751283
This is a meta bug, and CC performance is not so bad any more, so this doesn't really need an assignee or a Snappy tag.
Assignee: continuation → nobody
Whiteboard: [Snappy:P1]
Depends on: 827392
Blocks: 842137
No longer blocks: 842137
Depends on: 842137
Depends on: IncrementalCC
Depends on: 720916
Blocks: 956068
No longer blocks: 956068
Depends on: 956068
Depends on: 820233
Depends on: 1109816
You need to log in before you can comment on or make changes to this bug.