Categories
add-ons Firefox Garbage Collection Memory consumption MemShrink

MemShrink progress, week 57–60

I’ve been on vacation for two weeks, so this report covers the past four weeks.  I still have a mountain of unread emails, bug reports and blog posts to get through, but hopefully I haven’t missed much.

Hueyfix

I wrote about Firefox 15 and how it contains the “Hueyfix” that prevents most memory leaks caused by add-ons.  It got lots of attention.

Relatedly, a regression caused by the Hueyfix was discovered:  it caused some Greasemonkey scripts to leak badly, such as “YousableTubeFix” and “Textarea backup with expiry”.  A change was made to Firefox to allow this to be prevented (which has been backported to Firefox 15 Beta), and Greasemonkey 0.9.22 should fix the problem, although that hasn’t yet been confirmed.  If you have had problems with Firefox 15 and you are using Greasemonkey, this is a likely cause.  I’m not aware of any other regressions caused by the Hueyfix.

Also relatedly, Gabor Krizsanits made a change inspired by the Hueyfix that cuts references to sandboxes once they should no longer be used.  This prevents a whole class of possible leaks in add-ons using the Add-on SDK.

Miscellaneous

Gregor Wagner tweaked the JS engine’s garbage collection heuristics to greatly reduce the peak memory consumption in certain cases.  Gregor previously tweaked the GC heuristics in Firefox 7 with great success.

Tim Taubert fixed a leak caused by opening and closing the bookmarks sidebar.  This was a precursor to a more important change from Tim, which adds automated checking of the cycle collection logs to check for leaks during testing.  This should allow a whole class of memory leaks to be detected automatically, thus preventing regressions.

Benoit Jacob made a change that prevents the number of WebGL contexts growing excessively.  This can greatly improve memory consumption on certain sites that use WebGL.

Nick Cameron fixed a problem that caused huge memory consumption (multiple GB) on pages using canvas in conjunction with certain Intel graphics cards and/or drivers.  I don’t understand the details, but it sounds like some cards and/or drivers might still have problems.

Bug Counts

Here are the current bug counts.

  • P1: 23 (-0/+3)
  • P2: 89 (-9/+8)
  • P3: 105 (-2/+5)
  • Unprioritized: 1 (-2/+1)

Nothing spectacular there.

12 replies on “MemShrink progress, week 57–60”

Did you manage to provide Justin Lebar with the details of your problem? He did express and interest in investigating it in the last comments on the last post.

I was on AWSY today, and noticed a few things in the miscellaneous measurements graph:

1. The last data point captured in this graph is from 4 July 2012
2. There were 2 upward bumps in the JS Heap measurement (JS: After TP5 [+30s]): a large one on May 5 and a smaller one on June 14

The bump on May 5 could be explained by the compartment-per-global change. I do not have enough data to know the cause for the bump on June 14. Please confirm my conjecture on the first, larger bump.

I am more curious about why we are no longer graphing the measurements of JS Heap usage in this graph. Is it due to a lack of measurements or a graphing issue? The latter is easier to fix than the former.

Thanks,
Manoj

The May 5th one is very likely CPG. Not sure about the June 14 one, but it might be related to incremental GC.

The JS line is broken because I changed the structure of the JS reporters. Thanks for letting me know, I’ll ask John to tweak AWSY accordingly.

It looks like John’s tweaks broke AWSY entirely instead:

“An error occured while loading the graph data (./data/areweslimyet.json) error: ”

nothing is shown after “error:”

AWSY is running again. In addition to the two Manoj asked about, there was a brief spike on July 25/26; that appears largely fixed. Do you know what that one was?

I don’t know what caused the spike. If I had to guess I’d suggest it’s due to an incremental GC tweak.

Just wanna share some thing that happened to me…

Just get my first memory leak today, I’m using FF 14.0.1…
Using some Extension that can caused memory leak, (they are fine prior today)

It’s eating up 3+ Gb memory, and later crash the FF. Tried as suggested Disable Plugin, using FF beta 15… not much help it still happening…

The only thing difrent from now and couple hours ago (when everything fine) is i’m updated my GPU driver (curent using AMD 12.8 my prior was 12.7)

I’m now disable the hardware accel, not crashing for now so i’m thinking it was the driver update broke the FF

Hope this info helps, and I’m sorry if this not appropried place to post…

Comments are closed.