Categories
add-ons Firefox MemShrink

Additional Update on Leaky Add-ons

I wrote last week about leaky add-ons.  Specifically, Kyle Huey landed a patch that in most cases prevents zombie compartments, which are the most common kind of memory leak in add-ons.  However, this change itself caused a different memory leak in some add-ons built with versions 1.3 and earlier of the Add-on SDK.  I described this as “two steps forward, one step back”.

Happily, Kyle landed a patch that slightly delayed the cutting of the chrome-to-content references.  This has the following consequences.

  • It doesn’t compromise the “two steps forward”.
  • It fixes the “one step back”.
  • It should reduce the potential for similar, as-yet-unknown backward steps.
  • The repacking of add-ons with newer versions of the Add-on SDK is now less urgent than it was.  It’s still a good idea, though, because older version had some other, albeit much smaller, leaks.

This is good news.  Firefox 15 is scheduled for release on August 28.  Assuming we don’t hit other problems with these changes prior to release, for users with add-ons there’s a good chance that Firefox 15 will use less memory and suffer fewer annoying pauses.

Once again, it would be great if users of Nightly builds, particularly those that use add-ons, could pay attention to memory consumption and file bugs for any bad behaviour.  Thanks!

16 replies on “Additional Update on Leaky Add-ons”

Woohoo! This is awesome!
We get to have our cake & eat it too (then add ice cream).
I’m curious what the slight delay looks like? Seconds? Minutes? (less than a second?)

Is the delay going to be removed as soon as all major add-ons will have upgraded to the newest SDK?

Thanks!

There are a large number of working addons that are essentially abandonware at this point. Unless Mozilla automatically rebuilds them to the current SDK I think this will need to be kept indefinitely.

I’d still love to see a proper changelog somewhere, like Firefox used to have before the new release cycle. Font rendering (specifically, letter spacing) in 12 and 13 has been kinda horrible on sites that use Arial, like Google and Wikipedia, so I’d love to know what happened there and what I can do to either fix it or report it. It’s unrelated to memory use though.

ok guys, you’re just awesome!

Opened my firefox today, 30+ Tabs (only counting the ones in the active group, the others aren’t loaded), using just little more than 330 MB of RAM. A year ago, with Firefox 4, this would have been impossible. Keep it going!

When is the Hueyfix scheduled to push into Aurora? Right now I just installed Nightly at work – scary! However I’m not sure it can be any worse than Firefox 12 which had decided to adopt a policy of crashing at least once a day due to:

XPC_WN_NoHelper_Finalize

*sigh*

What is considered bad behavior? I can leave 8 pinned tabs overnight and see memory usage (according to memchaser) of about 800MB. As soon as I get up and start using the browser, it jumps up to 1500MB with GC taking ~11s and CC taking 6-15s. Can’t really tell why or what is causing it though… Feel free to email me with ideas…

GC/CC times on the order of seconds is definitely “bad behavior”.

It’s not always Firefox’s bug, though. For example, IRC Cloud was leaking memory like crazy a while back and causing us all sorts of pain. We fixed some things on our end, but there’s only so much we can do.

I’d try to isolate the problem to a particular tab or add-on and then file a bug. Or do it in the reverse order, if you’d like. 🙂

Comments are closed.