Leaky add-ons are a big problem, but there’s been lots of action relating to them recently. What follows is a summary of the situation and a request for help from currently Nightly testers who use add-ons.

Two Steps Forward

Kyle Huey’s patch to prevent Chrome-to-Content leaks landed recently. In theory it would prevent almost all add-ons zombie compartments, which constitute the majority of leaks from add-ons. And in practice, it appears to be working splendidly.

I did some testing of eight add-ons that are known to leak: McAfee SiteAdvisor 3.4.1(the old version that leaked every content compartment), Firebug 1.9.1, PicPasso 1.0.1, LoL 1.5, YouTube Ratings Preview 1.03, Enter Selects 7, HttpFox 0.8.10, and Link Resolve 0.7. I tested with a “before” browser build that lacked Kyle’s patch, and an “after” browser build that had it. For every one of the tested add-ons, I could reproduce the zombie compartment(s) with the “before” build, but could not reproduce any zombie compartment(s) with the “after” build. In other words, the patch worked perfectly.

To understand how important this is, consider this comment on Kyle’s blog describing the effect of the patch.

I seem to be seeing really significant improvements from this. Normally Fx would start at 170MB and by the end of the day that would often be creeping up to 800 or 900 MB. Today using latest nightly I again started at 170, but now at the end of the day I’m only at 230MB!

That’s a 4x reduction in memory consumption.

What effect does this have? The obvious benefit of reduced memory consumption is that there will be less potential for paging. For example, if the above user is on a low-end machine without much RAM, a reduction in memory consumption from 800+MB to 230MB might greatly reduce paging, which would make Firefox much faster.

However, what if the user has a high-end machine with 16GB of RAM? Then paging isn’t an issue. But this improvement will still be a big deal on such a machine. This is because garbage collection and cycle collection cause pauses, and the length of the pauses are roughly proportional to the amount of live heap memory. (Incremental garbage collection will soon be enabled, which will result in smaller garbage collection pauses, but there are no plans for incremental cycle collection and so cycle collection pauses will still be relevant.) So even on high-end machines with lots of RAM, leaks can greatly hurt browser performance. In other words, add-on leaks are a Snappy issue just as much as they are a MemShrink issue.

One Step Back

[Update: Kyle found a simple way to fix this problem with the Add-on SDK.]

So Kyle’s patch is great, but the cutting of the chrome-to-content references was unlikely to be totally free of side-effects. And sure enough, last week Josh Matthews noticed that Dietrich Ayala’s Wallflower add-on was causing many zombie compartments. Hmm, wasn’t Kyle’s patch supposed to stop exactly that? Well, it was expected to stop the most common cases, but there are some other leaks that could still cause zombie compartments.

The weird thing with this leak is that Wallflower is a really simple add-on. It’s built with the Add-on SDK and is only a few lines of code. It turns out that Kyle’s patch caused the Add-on SDK to leak badly. The exact reason is complex; you can see Kyle’s explanation here.

This sounds really bad. Lots of add-ons are built with the Add-on SDK. Have we just exchanged one class of add-on leaks for another? I don’t believe so, for two reasons.

Kyle’s patch prevents the single most common class of add-on leaks, and the Add-on SDK leak it caused is a much more obscure and unlikely leak. It’s unfortunate that this obscure leak happened to be in a piece of code that’s used by lots of add-ons. This obscure leak only occurs in old versions of the Add-on SDK. The leak doesn’t occur with the latest version, which is 1.6.1. Indeed, when Dietrich rebuilt Wallflower with version 1.6.1 the problem went away.

Still, the situation is far from ideal, because lots of add-ons are still built with older SDK versions. So, what to do? There’s a bug open discussing this question, but it’s gotten bogged down due to differing opinions on what to do. Version 1.6.1 happened to fix all leaks in the Add-on SDK that were known prior to this problem, so we should be encouraging add-on authors to rebuild with it anyway.

In the meantime, if you use Nightly builds and use add-ons, please monitor about:compartments and file bugs if you find that any add-ons are causing zombie compartments. If Wallflower is representative, the leaks will be very bad and so shouldn’t be hard to spot. Firefox 15 is scheduled for release on August 28th; we need as many affected add-ons to be rebuilt with the latest SDK before that date to minimize potential problems.

Problems with FUEL

Another cause of high memory consumption in add-ons is FUEL. I know very little about it other than it’s also part of the Add-on SDK sort of a proto-version of the Add-on SDK. The details are here and here. This is causing bad performance in Readability and probably other add-ons. Something to be aware of.