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

Status: RESOLVED WORKSFORME

(Core :: Cycle Collector, defect)

Description

[Andrew McCreight [:mccr8]]

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.

Comment 1

[Roman]

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?

Comment 2

[Andrew McCreight [:mccr8]]

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.

Comment 3

[Andrew McCreight [:mccr8]]

There's going to be a meeting tomorrow on improving/measuring browser responsiveness:  http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/d9d0d4e3675067e3

I'll attend and take notes on cycle collector related things that are discussed.

Comment 4

[Andrew McCreight [:mccr8]]

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.

Comment 5

[Andrew McCreight [:mccr8]]

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".

Comment 6

[Andrew McCreight [:mccr8]]

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.

Comment 7

[Andrew McCreight [:mccr8]]

Moved a bunch of these bugs into a sub-meta-bug.

Comment 8

[Jean Claveau]

I guess it's now effective on nightly because ffx  has massively improved its score on the spinning balls v8 bench (http://v8.googlecode.com/svn/branches/bleeding_edge/benchmarks/spinning-balls/index.html).

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!

Comment 9

[Andrew McCreight [:mccr8]]

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.

Comment 10

[Jean Claveau]

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.

Comment 11

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

It is probably bug 741417, since when there are no cycles to collect, CC time should be
reasonable low, almost low enough.

Comment 13

[Lawrence Mandel [:lmandel] (use needinfo)]

Dropping Kilimanjaro nom from this bug in favour of bug 741417 and bug 728407 as suggested by Olli.

Comment 14

[Andrew McCreight [:mccr8]]

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.

Comment 15

[Andrew McCreight [:mccr8]]

No new bugs blocking this one in a decade, so let's close it.