add-ons Firefox Memory consumption MemShrink

MemShrink progress, week 45–46


The big news this week is that Kyle Huey made chrome-to-content leaks impossible.  Kyle wrote about this in some detail.  This particular kind of leak can happen in Firefox, but more importantly, it’s responsible for most of the leaks in add-ons that we know about.  In other words, it should greatly reduce the problem of leaky add-ons, a problem I previously identified as the #1 MemShrink issue.  It’ll take a while to see the exact effects and whether they match expectations.  Nonetheless, this is a big deal!

Olli Pettay fixed a leak relating to Geolocation.

The following add-ons had leaks fixed: Collusion, SearchMenu, panchang, HTML5 Extension for Windows Media Player Firefox Plug-in.

Slimmer data structures

I reduced the size of JSScripts (here, here and here).  This increased the number of JSScripts that fit in a GC arena from 31 to 42 (on 32-bit platforms) and from 19 to 28 (on 64-bit platforms).  This reduced the size of the “scripts” entry in about:memory — which is often multiple MB for the compartments of complex web sites and apps like Gmail — by approximately 30%.  (The final two patches in the sequence are being held up by the current tree closure, but will land as soon as that has passed.)

Nathan Froyd reduced the size of mozilla::dom::Link — one of which exists for every <a> or <link> or <area> element shown in a page — by 4 bytes (on 32-bit platforms) and 8 bytes (on 64-bit platforms).

Ehsan Akhgari reduced the size of nsEditor — one of which exists for each text area in a page, and some other places — by 16 bytes on 64-bit platforms.

 Quote of the FORTNIGHT

PC Advisor featured an article about browser performance.  The article criticized the standard browser benchmarks for (a) not representing everyday browsing and (b) underestimating the effects of memory consumption on browser performance — two things that I agree with.

The article also presented some cross-browser memory consumption results from real-world-ish workloads.  The testing was imperfect — for example, it didn’t measure memory consumption after any kind of prolonged usage — but I liked the fact that the author had actually thought about things instead of just mindlessly running the standard benchmarks.

And with my PR hat on, I was happy with the conclusion.

Firefox is the clear winner of the bunch. It was the only browser that did not slow things down and I recommended it for both lower-end mobile devices and high-end desktops.

In general, cross-browser memory consumption comparisons are difficult to do well.  My preferred method is to run some set of benchmarks on a machine with a small amount of RAM, as that gives a genuine indication of the performance effect.  “Browser A was 50% slower on benchmark X when I halved the available RAM, but browser B was only 10% slower” is much more meaningful than “Browser A used 20% more memory on benchmark X than browser B”.  Choosing good benchmarks is still not easy, though.

Bug counts

Here are the current bug counts.

  • P1: 21 (-1/+0)
  • P2: 85 (-14/+15)
  • P3: 104 (-5/+9)
  • Unprioritized: 1 (-0/+1)

I’m thinking about omitting the bug counts from future MemShrink reports.  I don’t feel like they add much, but I’d be interested to hear if people think otherwise.

40 replies on “MemShrink progress, week 45–46”

I’m very happy about the progress, and the bug count is like saying “we’re still working on it”. The number and the usually long posts on the matter of memory make me feel like memshrink is serious work, and you’re working on it very good. And it’s also interesting to read. And of course I feel the improvements using firefox. Keep it up!

First, great work to all people involved in this project! Firefox is a great browser!

Second, please keep the bug count numbers for “behavioural reasons”: users sometimes read this report as a way to confirm that issues they still might have with Firefox’s performance are being worked on. The bug count gives an extremely reduced form (and therefore also inaccurate) but still intuitively easy to grasp metric for that. Your posts and arewefastyet kept me from switching to Chrome.

Thank you for your work! Please keep the bug count! I think dominik outlined the main reasons why it could be good to keep it.

Awesome! Love the work you folks do. Would love to hear results when tested with popular addons. You don’t have to provide detailed results for each addon, but a general “State of things” periodically would be better.

Very nice work guys ! About the bug count, I think keeping it is a good idea, but it would be great to add a bit of explanation about the new tickets, as “Major leaks have been discovered in module XY, counting for half of the tickets in P2″…

I mention things like that when applicable, but usually there’s not much similarity between the new bugs.

I thought so. But may I ask why such an important bug fix should not get in the release code sooner?!

I can understand why not in Firefox 13, since it is in Beta (which should be feature complete, and only focus on simple bug fixes) and there isn’t enough time to fully test it. But Firefox 14 seems reasonable. Of course, I am no expert, but as a user I think this should be given a very high priority. More so than any other feature being developed. I think this should be treated as a critical bug fix, rather than a feature that has to go through the regular development process.

I guess, I am just trying to understand why important fixes don’t get released more quickly. The MemShrink project has been around for a long time, but we have only been able to get it’s benefit in FF11, because it took the fixes a long time to get released. That was a really long wait!

Aurora (currently FF14) is the alpha testing version. Similar to the Beta release it’s for testing purposes in a more stable environment than the nightly builds (FF15). The intent of both Aurora and Beta is to allow enough time for extensive testing of newly added features to make sure they haven’t don’t break anything. The only patches added to them are fixes for features that were added in the last set of nightly builds and security fixes. Adding major new features to them effectively resets the testing clock to zero; increasing the risk of a major bug making it to release.

In the case of the addon change in particular the time period is also intended to give 3rd party developers time to make sure their code works with the new version. Any addons that were intentionally keeping references to web pages after the tabs were closed (as opposed to just not cleaning up after themselves) that don’t have robust error handling will break as a result of the change.

The first (and biggest) MemShrink improvements made it into Firefox 7, which was released in late September 2011.

Nick are you suggesting that we should not expect as much improvement from Kyle’s fix as we got from fixes in Firefox 7?

Thank you for the information. I understand the need for extensive testing. I have not noticed any noticeable improvement in memory footprint before FF11. But I use many addons, so this is probably the reason that improvements weren’t noticeable for me. But FF11 was a huge improvement that I noticed quite drastically [even accounting to the addons being fixed for leaks]. It was almost half of that of FF10, using the same addons of same version.

If I remember correctly, the best thing I noticed in FF7 was responsiveness. Firefox used to become unresponsive and crash when it used large amounts of memory. But FF7 used large amounts of memory but without much degradation in user experience. That was a huge improvement. But I didn’t notice actual reduction in memory usage, just that FF7 was able to handle it without serious degradation in responsiveness.

Anyways, thank you guys for your continuous work on this project. It is only because I love FF that I am so eager to see the issues fixed. Keep up the fabulous work!

If I understood your bug counts correctly, you show how the number of open bugs has evolved during the week, but it doesn’t necessarily reflects how things have evolved. Showing a count of the bugs that have been resolved and of the bugs that have been filed during the week may better show progress.

-14 +15 does tell us about the churn: 14 P2 bugs were closed, and 15 were opened.

I like the bug count, and think it would be more useful if the count differentiated between closed and downgraded (or upgraded) bugs. AFAICT a bug downgraded from P1 to P2 shows up as -1 in P1 and +1 in P2.

That’s right. But I don’t think it would be worth the extra effort that would be required to give that info. Sorry.

Fair enough. The numbers are interesting to us watchers but probably not worth putting huge amounts of effort into.

Would a simple ‘net new’ or ‘net closed’ tickets number be easy to include?

Great stuff!
It would be fantastic if this fix drastically reduces the amount of memory leaked by add-ons. However, is this something that will only apply to AMO or also to the vast majority outside of the Mozilla addons website?

I agree with Florian about leaving the bug counts and maybe modifying them to mention how many were opened AND shut this week and how many fixes were from previous weeks.

On an unrelated note, I end up helping lots in family and friends, who cant understand why their homepage and search plugin default suddenly change to (or some variation) – I think this happens when Adobe Flash Player or Adobe Reader gets updated.

This is a major cause of annoyance as most people will just do a typical installation which has change search defaults tick-marked. Many people find this frustrating. Is this something that is being looked at by Firefox in future releases?

Yes, people having their search engines changed out from under them without them wanting to is one of the top support issues for Firefox. It is being looked into, but I’m not sure what course of action they are planning to take.

On the homepage/search engine issue, let’s just say there are different opinions within Mozilla about how this problem should be addressed.

Hi Nicholas,

Please keep us updated in future blog posts with the progress of Kyle’s patch now that it has landed in the Nightly channel. It would be great to hear how things are going.

I just tested the old leaky version of McAfee SiteAdvisor with Nightly. There were no zombie compartments! I’ll test a few more leaky add-ons today, hopefully the results will be equally good.

That’s brilliant. Let’s hope this bug can power it’s way into the release version of Firefox 15 and sort out loads of other problems of the same kind!

Great Works Indeed. After a few weeks of silence, great things happens when we have patients.

I also wonder what happen to Incremental GC, since it has been landed but not turn on yet.

I think one of the good things about this MemShrink Post is that it is like a half PR half progress report. Unlike another project’s report, most of them are too technical, this actually explains and summarize things in easy to understand manner.

There’s also been interesting bugs filed within the last two days about FUEL holding on to windows, tabs, and extension info until shutdown; the reporter was seeing long delays on shutdown when it tries to clean up, IIRC. That should be very useful for MemShrink too.

Yeah, it sounds like any add-on that uses FUEL will have cause awful leaks. Sigh.

Was having a snoop around on about:memory with verbose, could you explain two things for me (if you can)?

1,170,927,616 B (100.0%) — vsize
├────616,284,160 B (52.63%) — anon
│ ├──615,243,776 B (52.54%) ── anon, outside brk() [rw-p][124]
│ ├──────917,504 B (00.08%) ── anon, outside brk() [rwxp][11]
│ └──────122,880 B (00.01%) ── anon, outside brk() [—p][30]

What are these 3 and why does the last one exist if it cannot be read, written or executed?

1,170,927,616 B (100.0%) — vsize
├────616,284,160 B (52.63%) ++ anonymous
├────352,878,592 B (30.14%) ++ shared-libraries
├────201,596,928 B (17.22%) — other-files
│ ├───67,112,960 B (05.73%) ── pulse-shm-3867894244 [rw-s]
│ ├───67,112,960 B (05.73%) ── pulse-shm-4271229540 [rw-s]

Pulse is holding onto two large shm, why two & why so large? 😀

Hi, great work, can’t wait to get my hands on the new fixes.

Btw, in 14a2 the about:memory seems to have changed a bit, but most importantly heap-unclassified has fallen to 11%, and js to 22% leaving window-objects the largest piece left on fresh start memory usage (after loading a set of bookmarks). Digging deeper, the layout/style-sets is the consumes most of the memory in all of the open pages.

Is there anything to be done to it, similar to getting rid of the JS slack with allocation sizes and optimizing data structures?

Here’s how the memory usage often looks like, with some leaks/fragmentation/etc eventually pushing resident size (both in about:memory and task manager) close to 1600MB on 32 bit environment, causing a crash:

1,363.64 MB (100.0%) — explicit
├────782.88 MB (57.41%) ++ window-objects
├────309.23 MB (22.68%) — js
├────158.84 MB (11.65%) ── heap-unclassified
├─────49.07 MB (03.60%) — images
├─────25.19 MB (01.85%) ── network-memory-cache
├─────15.54 MB (01.14%) ── atom-table
├─────14.47 MB (01.06%) — storage
└──────8.42 MB (00.62%) ++ (7 tiny)

i created a new profile in nightly, then configured and ran

a single ghost window and zombie compartment are left after finishing the test, clicking the close opened tabs button, opening a new window and closing the old.

Can anyone else confirm this?, Nicholas?

Nicholas, can you please provide some links to the important bugs which will further reduce memory usage, or of importance to Memshrink project. I am starting to believe that Nightly is at its best now. I just don’t want to say that “Project Memshrink was a big success.” Not yet.

I have, already. I just wanted to know any good progress to be seen in a couple of weeks. I have been following Memshrink since the first week itself, so I have no doubt on its impact and importance. Its just that most of the p1 bugs have been inactive for some time.

It’s hard to predict. I generally report on things once they’re finished.

Comments are closed.