Add-ons
The main news in the past two weeks has been about Kyle Huey’s patch that prevents most chrome-to-content leaks, which are the most common kind of add-on leak. Testing showed it worked beautifully, but caused a knock-on leak in add-ons built with old versions (1.3 and earlier) of the Add-on SDK. (This received a lot of attention.) Kyle then made a slight tweak that fixed that knock-on leak. So we’re currently still on track for Firefox 15 being “the one that fixes add-on leaks”.
For completeness, here are the add-ons that we know were temporarily affected by that knock-on leak: Wallflower, Visual Hashing, Translate This!, Easy YouTube Video Downloader. They (and probably quite a few others) are all working fine again now.
Here’s a quote from an email that one user sent to Kyle this week.
Firefox was leaking about 1.5GB per hour for me. It started with Firefox 3. I tracked it down to Ghostery and NoScript, but even without those addons it leaked about 500MB per hour of browsing.
GC and CC times got up into the 10 second range. Ugly. Really really ugly! And this is on top of the line massively overclocked hardware, too. I had to install a new addon to add a restart button to Firefox, because Firefox froze solid after hitting 2GB of memory usage. I also patched it after every update to allow up to 4GB, buying a little more time…
Then your patch comes along and solves it all… you are awesome man – totally awesome!
Another user — one who uses the leaky Autopager add-on — commented on Kyle’s blog.
Certainly, before this fix I would find that Firefox often became sluggish (input lag, slow paint operations, less than silky smooth scroll animations) as the memory usage built up. It’s hard to say how much various factors contributed to the whole, but GC pauses did undoubtedly cause the scroll animation stuttering.
Restarting was the cure. I haven’t noticed the same symptoms since, and while I haven’t had enough chance to make a conclusive judgement, the signs certainly seem to be good.
I have a full tab strip more often than not, and Fx set to load tabs from last time. This is offset by the wonderful and elegantly simple tabs on demand feature. I’m running a 2 year old laptop with 4GB ram.
And while we’re on the topic, here’s a comment from my blog.
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!
Good times.
The following add-ons had zombie compartments fixed: Youtube Ratings Preview, SPDY Indicator It’s likely these leaks would have been fixed by Kyle’s change, but since Firefox 15 won’t be released until August 28, it’s good that they’ve been fixed now. (Indeed, the AMO review policy still requires that add-ons not cause zombie compartments with the current release of Firefox; that policy may be revisited once Firefox 15 is released.)
Compartment-per-global
The other big news is that compartment-per-global (CPG) landed, thanks to the work of various people, especially Luke Wagner and Bobby Holley. Bobby explained what this means and explored some of the consequences.
CPG will allow lots of things within Firefox to become simpler and faster. The main disadvantage is, unfortunately, increased memory consumption, as can be seen on areweslimyet.com. (Thanks to Luke, this increase was less than it could have been.) This is mostly due to more fragmentation in the JavaScript heap — we now have many more compartments, and each 4KB heap arena cannot be shared between compartments, so there are many more partially empty arenas present.
You might think this would make me bang my head against the wall in frustration, but it doesn’t. That’s because even if I ignore the many non-MemShrink-related benefits of CPG, there are two big MemShrink-related ones.
First, CPG will enable per-tab memory reporting, something that users have been requesting for years.
Second, CPG will lead to much more detail in about:memory and about:compartments. For example, Nils Maier has written a patch that makes it obvious all the JavaScript modules that have been loaded. Another example: Justin Dolske found that plusone.google.com was doing something silly (constantly creating new iframes?) that caused huge numbers of compartments to be created; without CPG I think all those globals would have been lumped into a single compartment and the problem would have been much less obvious. More information in about:memory will lead to more diagnosis of existing problems — particularly leaks of various kinds — in both Firefox and websites.
Memory Reporting
Kevin Locke tweaked the JS memory reporters so that more compartments are distinguished, instead of being lumped together. This was his first Mozilla patch — well done, Kevin!
Nathan Froyd improved the coverage of the layout memory reporters. This significantly reduces “heap-unclassified” for huge pages like the single-page version of the HTML5 spec.
Bug counts
Here are the current bug counts.
- P1: 22 (-2/+3)
- P2: 83 (-6/+4)
- P3: 105 (-5/+6)
- Unprioritized: 3 (-1/+3)
Mostly bouncing around at the moment.
27 replies on “MemShrink progress, week 47–48”
Not much more to say here other than, “You guys rock”!
In another life, I developed and maintained the Elasticfox extension to facilitate the management of EC2 resources with Firefox. It was hard to track leaks and bizarre behavior down a few years ago. The new tools and API make me want to blow the dust off the code-base and start hacking again.
MM
Per-tab memory reporting is great. Are there any plans to make per-addon memory reporting?!
This would be more helpful, since users can identify offending addons and solve their problems more proactively, and addon testers can report memory usage to addon developers.
It’s partially there, particularly for add-ons that use the SDK — look at the system compartments. But in general, we don’t know how to do it.
So all these will come in Firefox 15. Looks like an important release to me.
Hueyfix and per-tab memory reporting? But my birthday’s not until September! 🙂
Welcome, congratulations and thanks Kevin!
Huey is most definitely awesome. Can we rename the next iteration of the location bar the hueybar? People inside Mozilla should get the reference 🙂
Very nice to hear these good news. I hope that we are going towards a new era in the browser area and in particular to a more detailed browsing experience to its users. It also would be nice to have a report of memory of each enabled add on in a clear way to identify leaks in add on and overall to the whole experience of controlling your browsing preferences more strictly and effectively.
Looking forward to CPG, and the kinds of fun things it can lead to. Especially in terms of killing future bloat – this should mean jsms and XPCOM components can be identified, so bloat across windows should be hopefully be a smaller problem.
The most surprising thing for me about the first mail was that this person suffered horrible performance, took the pains to track it down to two specific addons that were the main culprits, and… still consciously decided that keeping them was a better experience.
The combination of NoScript and Ghostery tells you that this user is probably very focused on security/privacy, and so presumably decided that the protections those add-ons give outweigh the inconvenience of restarting frequently.
Ditto in my case. I find NoScript to be quite critical for those points, but also to have more control over what sites can bring their toys to my sandbox. Keeps me free from much of the antics you can expect if you give sites free reign over your JS and plugins.
Anyway, I’m greatly thankful to everyone on the MemShrink team. We’re seeing great strides being taken here and swift progress. The news that CPG could herald further progress is more than welcome though; it would appear from areweslimyet that there is still room for improvement 😀
Is this a step towards a Chrome like guarantee that all resources of a tab will be freed when it is closed? In my understanding this was not possible in the past because there was no direct connection between a tab and its allocated memory.
If you’re talking about Kyle’s patch, then yes, it’s something of a step towards that. Still not nearly as rigorous as separate processes, though.
Nick, I thought with CPG all fragments would be associated with a tab or group and when that tab is closed it releases all the memory used – so it will bring it back to start-up RAM if all tabs closed?
I think that’s what Kamulos was asking?
Oh, thanks for the clarification. Yes, it has that characteristic. But it’s also possible that 4KB arenas might be shared between compartments in the future; there are all sorts of trade-offs in terms of minimizing memory consumption now vs. minimizing fragmentation later.
Do I understand correctly that fragmentation won’t be such an issue once the Generational GC arrives on scene?
That should be the case, yes.
I am just a ff enthusiast and not a coder but would the following be practical?
Create a program that would open two copies of FF simultaneously. One with a particular extension enabled and another with the same extension disabled. Only one window would be user visible but it would exactly replicate any user interaction to the other copy. Then it could analyze memory differences realtime between in using that extension and not. Perhaps allowing addon developers to sort out memory issues of individual addons?
Anyway, you guys are great. Thanks for the all the hard work!
Not easily. It’d lead to things like buying two of everything you buy online!
Simply avoid buying thing while testing. Reading news, browsing at sites without logging in or such would be enough to test add-ons, at least that’s what I think.
It seems like it would be a lot easier to just record the actions taken in 1 browser, then you could start the other and replay them.
In general, that’s never going to be perfect (nor is the above solution of running both browsers at once) because the websites will likely serve different ads to each browser and network traffic for one may end up delayed while the other gets through quicker.
You can make a perfect comparison between different browser builds/configurations; but to do so your test infrastructure has to capture the traffic (including timing delays) sent by the web servers in the recording stage and play it back in runs 2 though n instead of directly connecting to the third party servers.
IIRC MS has created a setup like that for testing IE; but I don’t recall where I read it and searching for anything including IE and testing generates an enormous number of irrelevant results.
The tests run on areweslimyet.com only use local files so there’s no non-determinism due to network accesses.
Is the HTML5 spec page tested at all to discover memory usage wins?
Seems like a good test case for heavy mem, as webkit guys are looking at it : http://trac.webkit.org/changeset/116419
hi just found this awesome blog of yours after some googling! great work your doing!
per tab memory consumption is THE reason i am using ffx. no really!
i am relieved to hear that long-term memory leaking has been greatly reduced!!!
recently switched to the ux channel (chromeless scrollbars)… but after suffering increasing sluggishness/memory- usage-increase issues, i did some over-the-thumb memory analysis. i never had that *ffx4 is a memory hog moment* but suffered dearly during some *whaagh bartab addon broken again* months, but that time showed plainly that no other browser is able to handle ~1000 tabs @~10 windows (~100 tabs loaded). needless to say this goes up to 4GB memory on a heavy workday…
this is just startup time & memory (completely reproducible ±5%) after things go idle. no addons except bartab. ~15 pinned tabs +1 per window = 20 loaded tabs, 5 windows, 5 non visible tab groups, in total 900 and odd tabs.
version restart cpu% threads real memory
3.6 15sec 2.5 17 399.4 MB
4 15sec 1.4 27 845.2 MB
7 13sec 1.3 27 645.1 MB
12 13sec 0.5 27 612.4 MB
13 16sec 0.3 26 611.9 MB
15 20sec 0.1 28 708.7 MB
ux 55sec 0.1 22 724.8 MB
13 16.6 31 4.38 GB No Intel (64 bit) 2.78 GB 31.9 MB
and in case anyone wonders: that last line is how high it gets when loading all 900 tabs… makes firefox totally unresponsive for about 5min. after that firefox runs almost butter smooth with occasional minor hiccups (instant to ~1s switching a tab). running about:memory icreases memory usage to 5.5GB. (by the way kudos how that *idle* cpu usage has gone down to almost 15%, in ffx 3.x this got as high as 90%)
i assume the nightlies have higher memory usage due to testing flags…
Nightly got Compartment Per Global which regressed memory upto 3-5% but the awesomeness what this bug fix can bring justify that much regression.
oh forgot to mention that with firefox 12 addons consume an additional 100mb whereas the exaxt same addons & session on ffx 15 add 300mb… in any way plausible?
Compartment per global is again answer to question. If addon is Addon SDK 1.3 and older based, your Nightly might be not updated to avoid leak fix which landed later. If addon is Binary then it might have many JS modules which resulted in many compartments by addon as result more memory usage by Addon.
Nicholas,
In your week 32 report you mentioned that there were 6 big ticket items.
#1: Better Detection and Notification of Leaky Add-ons
#2: Better Foreground Tab Image Handling
#3: Compacting Generational GC
#4: Better Memory Consumption Tracking
#5: Better Memory Reporting
#6: Better Script Handling
Would you be able to give us an update on each of those areas and say whether you think the hierarchy of importance has changed at all in the last 18 weeks?
I think it would be good to look at the fixes that have landed in each area.