668881 - Increasing GC pauses on Marching Zombies game with Firebug enabled

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Nicholas Nethercote [inactive]]

Masterleep reported this problem in the comments of http://blog.mozilla.com/nnethercote/2011/06/29/memshrink-progress-week-2/.

He(?) wrote:

> I’m writing an HTML5 game using SVG and animating objects with Javascript. 
> Performance in Firefox is generally fine, except there are very frequent 
> stutters during smooth animation. I am ascribing these to GC pauses, but
> there are lots of them even when I’m not allocating anything directly.

I suggested he try turning on javascript.options.mem.log to determine if they are GC pauses or something else.  He replied:

> Thanks for the pointer, Nicholas. These are GC pauses, and I don’t think I 
> can do anything about them since my code isn’t allocating anything during the 
> animation loop.
>
> It’s unfortunate that there’s no way to do smooth animation in Firefox 5, 
> unless I’m missing something. The GC pauses can often be above 100ms on a 
> recent MacBook Pro which is quite noticeable.
>
> The pauses aren’t too horrible on a freshly started Firefox process, but if 
> you’ve been browsing around for an hour or two, they are bad.

So, questions and comments (addressed to both Masterleep and Firefox developers):

- How do the pauses compare to other browsers?

- Do recent and in-the-works improvements (bug 656120, bug 666058) help here?

- The fact that the pauses get larger after Firefox has been open for an hour or two is not good.

Comment 1

[Nicholas Nethercote [inactive]]

Andreas emailed me:

> This must be a leak. Please make this a high priority. It has been around for
> ages but we can't reproduce. Andrew mccreight can help.

Comment 2

[MasterLeep]

The stutter is quite a bit worse in Firefox than in Chrome or Safari.  It's not a new thing though - it's been this way since Firefox 3.5.

Comment 3

[Gregor Wagner [:gwagner]]

I copied the animations link from your blog Nick:
http://dungeoneers.com/bugs/perf/marching-zombies/perf.xhtml

With this tab alone I only see GC pauses of 20-25ms. They are not noticeable but the GC gets called every 6 seconds or so. These are JS_GC calls and not per-compartment GCs. 
There might be leaks but aside from that, the other browser workload will determine the total GC pause time. Bug 638660, bug 627200 and incremental GC will definitely help in the near future.

Comment 4

[Nicholas Nethercote [inactive]]

So there's two aspects to this:

(1) The stutters, which incremental GC (bug 641025) and/or generational GC (bug 619558) will likely help with, and possibly other GC improvements will also help (e.g. bug 656120, bug 666058).

(2) The increasing length of the stutters, which may be a leak like Andreas says in comment 1.

I'll rename this bug to focus on (2), because we have plenty of long-term work underway that should help with (1).

Comment 5

[MasterLeep]

Should it be the case that if I have no browser windows and no tabs other than the test case open, that I get back to the original quick GC times?  Because that's not what I observe.  It does feel that Firefox gets less efficient with increasing process lifetime.

Another somewhat odd behavior is the often significant variation in the GC time even when there are no other tabs / windows open, and the page is doing the same loop.


The original test case is here:
http://dungeoneers.com/bugs/perf/marching-zombies/perf.xhtml

It uses the normal game assets but has reduced javascript (30 simple lines, no jquery or anything like that):
http://dungeoneers.com/bugs/perf/marching-zombies/perf.js

Comment 6

[MasterLeep]

Attachment: error console showing GC times

attached is a screenshot of the GC times I'm seeing, with no other tabs / windows other than the test case, and no other processes running other than the Finder.

Machine is a 2.66GHz Intel Core 2 Duo Macbook Pro with 4GB ram, running OSX 10.6.8 and Firefox 5.

Comment 7

[Nicholas Nethercote [inactive]]

(In reply to comment #5)
> Should it be the case that if I have no browser windows and no tabs other
> than the test case open, that I get back to the original quick GC times? 
> Because that's not what I observe.  It does feel that Firefox gets less
> efficient with increasing process lifetime.

That shouldn't happen, that's why it sounds like a leak.

Can you try a nightly build from nightly.mozilla.org?  It has some GC improvements, and also a much-improved about:memory page.  Output from about:memory at different times might be instructive.

> Another somewhat odd behavior is the often significant variation in the GC
> time even when there are no other tabs / windows open, and the page is doing
> the same loop.

That sounds less unexpected, though I'm not certain.

Comment 8

[MasterLeep]

The leaky behavior might have to do with Firebug.  I haven't seen it again since disabling that.

Comment 9

[Nicholas Nethercote [inactive]]

Firebug 1.8 has fixed one bad leak, it might be worth re-trying.  See bug 669730.

Comment 10

[Nicholas Nethercote [inactive]]

Marking this RESOLVED INCOMPLETE due to lack of response from the reporter.  Please reopen if the problem is still present in Firebug 1.9 and Firefox 9.

Comment 11

[MasterLeep]

Sorry, I've been afraid to install and use Firebug since realizing it could cause problems like this.  I've gone over to Safari Inspector for now.

Comment 12

[Marco Castelluccio [:marco]]

MasterLeep could you try with Firebug 1.9 and Firefox 9? If the problem is still present, it's better to know :)