664613 - Insufficiently frequent GC

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

Our GC is tuned primarily for benchmarks like Sunspider and V8bench.  For example, if we GC during SunSpider our time increase by 50% or something ridiculous, so it's paramount we don't collect.

But it appears that this hurts real-world websites.  We're getting lots of reports of large JS heaps.  Bug 664128 is one example;  having read a lot of leak reports since FF4 came out I think there are other examples, and I'll add them here as I find them.

The current GC triggers, AFAIK:

- When the heap size reaches 3x bigger than it was after the last GC, we GC

- When 32MB of non-OffTheBooks memory has been malloc'd/new'd, we GC

Things that will help here:

- Bug 656120: time-based collections when idle

- Bug 641025: incremental GC (we can do partial GCs more frequently)

- Bug 619558: generational GC (we can do nursery GCs frequently, and the main heap will grow more slowly)

Comment 1

[avada]

Out of curiosity. Is it normal that GC is that expensive? Don't other browsers garbage collect while still getting a good score?

Comment 2

[Igor Bukanov]

(In reply to comment #1)
> Out of curiosity. Is it normal that GC is that expensive? Don't other
> browsers garbage collect while still getting a good score?

Our GC is getting less expensive. That would be especially true after fixing the bug 638660. So we may reconsider the frequency of the GC after that as a quick haxck to address the problem.

Comment 3

[Nicholas Nethercote [inactive]]

They (Chrome, at least, not sure about the others) have generational GC, which means that a large fraction of the garbage can be collected via very frequent and cheap nursery collections.

Comment 4

[Gregor Wagner [:gwagner]]

(In reply to comment #0)
> 
> The current GC triggers, AFAIK:
> 
> - When the heap size reaches 3x bigger than it was after the last GC, we GC
> 
> - When 32MB of non-OffTheBooks memory has been malloc'd/new'd, we GC
> 

We also perform a compartment-GC (from MaybeGC) if we reach 75% of the trigger limit.

(In reply to comment #3)
> They (Chrome, at least, not sure about the others) have generational GC,
> which means that a large fraction of the garbage can be collected via very
> frequent and cheap nursery collections.

Well it's not always that cheap :) http://t.co/xUUxoaD

Comment 5

[Nicholas Nethercote [inactive]]

(In reply to comment #4)
> 
> > They (Chrome, at least, not sure about the others) have generational GC,
> > which means that a large fraction of the garbage can be collected via very
> > frequent and cheap nursery collections.
> 
> Well it's not always that cheap :) http://t.co/xUUxoaD

Sounds like their nursery collections are cheap but their full collections are slow?

Comment 6

[Gregor Wagner [:gwagner]]

(In reply to comment #5)
> (In reply to comment #4)
> > 
> > > They (Chrome, at least, not sure about the others) have generational GC,
> > > which means that a large fraction of the garbage can be collected via very
> > > frequent and cheap nursery collections.
> > 
> > Well it's not always that cheap :) http://t.co/xUUxoaD
> 
> Sounds like their nursery collections are cheap but their full collections
> are slow?

Yes. If I read their debug output correctly they only perform a "mark-and-sweep" GC when the long pauses occur. So their old-generation GC is very expensive.
They can also do a "mark-and-compact" GC but that might even be more expensive.

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

But why do their mark-and-sweep GCs get more expensive over time and ours don't?

Comment 8

[Gregor Wagner [:gwagner]]

(In reply to comment #7)
> But why do their mark-and-sweep GCs get more expensive over time and ours
> don't?

Good point and I don't have an answer. I was running chrome with this debug output for a few days now and during animations the GC pause time peaks usually increase for "mark-and-sweep".

Their advantage is their tiny heap size.
For the v8 benchmarks (except splay) they usually have <15 MB upper limit.
For splay they increase it to 80MB in 6MB steps but their pause times are very high. For example:
Mark-compact 79.8 -> 25.9 MB, 244 ms.
Mark-sweep 79.2 -> 26.1 MB, 120 ms.
So it makes sense that they spend almost 10% in GC during the V8 benchmarks.

Comment 9

[Gregor Wagner [:gwagner]]

We are not very good with automated testing of memory behavior over a long period of time.
Maybe I am wrong but all the tests we perform after a check-in don't really monitor a long term memory behavior.
Since we can't detect such bugs, the only source for bug reports are users that care enough to inform us. So it's impossible to get an accurate regression range.

It would be extremely important to have a daily score for the memory footprint. So just take a nightly build and let it run with 50 popular pages for a day and monitor the footprint every hour or so.

Comment 10

[Andrew McCreight [:mccr8]]

Bug 663416 is looking into something like that.

Comment 11

[Nicholas Nethercote [inactive]]

I'm going to close this bug;  it's only tracking 3 bugs, one of which has been fixed, and the other two have MemShrink whiteboard markings, so I don't think this bug serves much purpose.