Categories
add-ons B2G Firefox Memory consumption MemShrink

MemShrink progress, week 71–72

B2G

Justin Lebar led the B2G charge this fortnight, doing the following.

Thinker Li identified that we were using overly large (128 KiB) arena chunks for type inference data in the JS engine.  Reducing them to 32 KiB saved over 3 MiB of memory on B2G.

Fabrice Desré disabled the add-on manager services, saving about 1 MiB.

These changes have all been backported to Aurora, because that’s the current home of the code that will be used for the V1 release of B2G.

Social API

Jared Wein modified the social sidebar so that it unloads itself 10 seconds after it’s been hidden.  This is good because lots of people thought that closing the sidebar was equivalent to disabling the social functionality, and with this change it now effectively is.

Felipe Gomes fixed a major problem which caused the social API to create and leak many unnecessary ports.

Gecko & SpiderMonkey

Benoit Jacob fixed a leak relating to WebGL and cycle collection.  This fixed 10 seconds pauses that occurred after running the RO.ME demo, and also fixed leaks seen in the WebGL version of Nokia Maps.

Kyle Huey fixed a bug that was causing storage code to leak one thread per connection.  This doesn’t affect most Firefox users much, because most connections live for the full lifetime of the process.  However, it could affect some add-ons, and it helped avoid some frequent OOM oranges in some of our tests.

Benjamin Peterson reduced the amount of memory used to compress JavaScript source code.

Add-ons

Zig fixed a zombie compartment in the Visited add-on.

Bug Counts

Here are the current bug counts.

  • P1: 18 (-4/+3)
  • P2: 113 (-2/+14)
  • P3: 97 (-1/+7)
  • Unprioritized: 2 (-13/+2)

Note:  in all my previous MemShrink reports, I mentioned bug fixes as soon as they landed on mozilla-inbound.  As of this week, I’m changing things so that I (mostly) only mention bug fixes that have landed on mozilla-central and thus been marked as RESOLVED.  This will make my life easier (tracking RESOLVED bugs is easy with Bugzilla search), and it will also mean that the changes in bug counts better match the descriptions of bug fixes.  But it means that some bug fixes will be reported two weeks later than they previously would.

Categories
about:memory add-ons B2G DMD Firefox Memory consumption MemShrink

MemShrink Progress, week 69–70

It’s been a bumper two weeks for MemShrink.

B2G

Gregor Wagner tweaked the JS garbage collection heuristics on B2G so that collections occur more frequently.  This prevents too much garbage from accruing, which is important on low-memory B2G devices.

Justin Lebar disabled sync on B2G, because it isn’t used.

Justin also implemented the ability to dump GC/CC logs when a particular signal is received, which is particularly useful for B2G.

B2G’s Operation Slim Fast is in full swing.  Please see the tracking bug for details about what is happening.  While there are a number of important fixes in the pipeline, memory consumption is still a critical issue for B2G simply because the devices don’t have much memory in the first place.  Any additional help from Mozilla developers will be greatly appreciated.  For example, if anyone can help identify unnecessary compartments, that would be helpful.

Memory Reporting

Boris Zbarsky improved the reporting coverage of style sheets.  We’ve seen this improved coverage account for over 1% of explicit on desktop and over 2% of explicit on B2G.

I fixed some double-counting of style sheets, and slightly improved the reporting coverage of style sheets and JS compartments.

Nathan Froyd added memory reporting for telemetry.

Justin Lebar fixed some over-reporting of the JS stack.  Justin also added to about:memory the ability to read JSON memory report data from the clipboard.

I renamed DMD as DMDV, in preparation for its in-progress, non-Valgrind replacement to take over the original name.

Testing With Valgrind

Gary Kwong has done some heroic work recently getting Valgrind tests passing on Tinderbox.  (Strictly speaking, the tests run Memcheck, which is the default Valgrind tool and is synonymous with Valgrind)  His blog post about it is well worth reading.

This is important for MemShrink because Memcheck can detect an important class of memory leaks — ones where all references to a block of memory are lost and so the block leaks forever.  But it’s also important for Firefox as a whole because Memcheck can detect a slew of other memory-related errors, such as writing unaddressable memory (e.g. buffer overruns) and using undefined values in dangerous ways.  These are the kinds of defects that cause crashes, security vulnerabilities, and other major problems.

The tests are currently hidden on TBPL because they only run on mozilla-central once a day, which is generally not enough for a test suite to be reliable enough to be worth unhiding.  Having said that, the ability to write suppressions for errors found with Memcheck complicates considerations;  see bug 800435 for further discussion.

Add-ons

Gregg Lind fixed things so that our Aurora/Beta users are certain to get an up-to-date, non-leaky version of the Test Pilot add-on.  (Version 1.1.2 was the leaky version;  version 1.2.0 or later has the fix.)  This was a longstanding MemShrink:P1 bug.

Erik Vold fixed a zombie compartment in Scriptish.  Version 0.1.8 has the fix.

Josep del Rio fixed a zombie compartment in Speed Dial.  Version 0.9.6.10 has the fix.

Miscellaneous

Boris Zbarsky fixed a bad zombie compartment leak relating to expandos.  This was a recent regression, and the fix is present on Aurora and Beta.  The problem was first reported in the comments of my MemShrink report from four weeks ago — many thanks to Alex for reporting it and preventing it from reaching an official Firefox release!

Bug Counts

Here are the current bug counts.

  • P1: 19 (-2/+5)
  • P2: 101 (-2/+6)
  • P3: 91 (-6/+0)
  • Unprioritized: 13 (-1/+11)

The unprioritized count is high because we spent the first part of today’s MemShrink meeting talking with Gavin Sharp, Jared Wein and Felipe Gomes about the upcoming social API, and then spent some additional time discussing B2G with David Clarke.  As a result we didn’t have time to triage the 23 new MemShrink bugs.  We’ve scheduled an out-of-band MemShrink meeting for next week to get on top of the bug list.

Visiting Mountain View

I’ll be in Mountain View all next week for the JS team work week.  I’ll be happy to meet up with anyone who wants to talk about memory consumption!

Categories
B2G Firefox Memory consumption MemShrink

MemShrink progress, week 67–68

It’s been a busy couple of weeks for MemShrink.

B2G Memory Reporting

about:memory is our main tool for understanding memory consumption. On desktop Firefox it works very well.  On Firefox mobile it works less well, partly because it’s hard to read all that text on a small screen, and partly because you can’t cut and paste, which makes bug reporting difficult.  And on B2G (a.k.a. Firefox OS) it currently doesn’t work at all.

To remedy this, I implemented the ability to import and export memory reporter data in JSON format, and Justin Lebar sped up the exporting of this data and implemented a signal-based mechanism for triggering it.  The idea is that developers can trigger an export of the data from their device and then view it in about:memory in desktop Firefox.

This will allow detailed memory profiling for B2G, which I have listed as #3 on the current MemShrink “big ticket items” list.  The timing is good, because B2G has reached feature-freeze and so focus will now move to its performance and memory consumption as part of “Operation Slim Fast“.

(On a related note, Kartikaya Gupta and other engineers have started looking closely at the memory consumption of Firefox mobile on low-end devices.)

Generic Memory Reporting

I added memory reporting to IonMonkey.  Happily, it appears to use very little memory, especially compared with JaegerMonkey.  This is partly because it generates smaller code than JaegerMonkey, but mostly it’s because IonMonkey is only used to compile the small fraction of code that has been executed many 1000s of times.  In comparison, JaegerMonkey is used to compile the much larger fraction of code that has been executed more than a few times.

Kyle Huey added memory reporters for attribute nodes and attribute maps, which improves the coverage of the memory reporting for the DOM.

Gecko Slimmings

Kyle Huey optimized the representation of repeated inline style rules.  This means that for pages with many elements of the form <foo style="blah">, the repeated style="blah" part is now shared between the elements.  This is a huge win on certain large, auto-generated pages.  For example, on one page that holds a gigantic Mercurial diff, this change reduced 64-bit Firefox’s memory consumption from 1,759 MiB to 1,306 MiB.

Kyle Huey and Olli Pettay fixed a leak relating to web workers.

Patrick McManus fixed a leak in network code that was causing intermittent oranges for Mochitests.

Seth Fowler made nsConsoleService only post a LogMessageRunnable to the event queue if there are any observers for it.  This can save a lot of memory for pages that contains many errors.

Bad Graphics Drivers

An ongoing problem we have is that badly-written graphics drivers can cause outlandish (e.g. multi-GB) memory consumption.  Here’s one example that was fixed by blocklisting one particular AMD driver.  (That driver was also causing lots of crashes.)

It’s got to the point that if someone is seeing excessive memory consumption with no apparent explanation — e.g. immediately after start-up, with few tabs open — I’ll suggest they set layers.acceleration.disabled to true in about:config and there’s a good chance it’ll fix the problem.  (Restarting in safe mode also disables hardware acceleration.)  I don’t have any good ideas on how to improve this situation.

Bug Counts

Here are the current bug counts.

  • P1: 16 (-8/+3)
  • P2: 97 (-2/+10)
  • P3: 97 (-6/+3)
  • Unprioritized: 3 (-3/+3)

In today’s MemShrink meeting we closed and downgraded a number of P1 bugs that (a) have been partially addressed, or (b) are less important than they first seemed, or (c) are duplicates.

Categories
Firefox Garbage Collection Memory consumption MemShrink

MemShrink progress, week 65–66

Gecko

Tim Taubert set the style of a not-yet-restored tab’s <browser> element to display:none, eliminating the need for any layout data to be stored in memory for such a tab.  This was a MemShrink:P1 bug and is a nice improvement for users who typically have many (e.g. 100+) tabs open, because it saves 0.17MB per not-yet-restored tab on 64-bit platforms, and slightly less on 32-bit platforms.

Bobby Holley fixed a defect that was causing some add-ons (NoScript, Roboform, and Google PageSpeed) to create ghost windows.   This fix has been also been ported to the Aurora and Beta channels and so will be present in Firefox 16.

Add-on SDK

Version 1.10 of the Add-on SDK was released.  It has two fixes that prevent various leaks.  Furthermore, Alexandre Poirot fixed two other leaks in the Add-on SDK;  these changes will presumably make it into version 1.11.

The Add-on SDK has had a lot of leaks fixed over the past few months.  Hopefully we’re getting near the end of them!

Generational GC

I have started helping with the ongoing project to convert the JavaScript engine’s mark-and-sweep garbage collector to a compacting, generational collector.  This is the #2 item on the current MemShrink “Big Ticket Items” list because it should significantly reduce JS memory consumption, and it should also help performance in other ways.

It’s a big task because it makes a very fundamental change to the JS engine: garbage-collected things such as JS objects, strings and functions can move.  This is a big deal because these things are represented within the JS engine as C++ objects of various kinds, and it’s not normal for C++ objects to move!  Think about it — if you have a pointer to a C++ object, and the object moves, the pointer is no longer valid.

I won’t go into detail about how we handle this but the important thing to know is that pretty much every place in the JS engine where we have a raw C++ pointer to a GC thing object needs to be manually changed to use a new representation.  This is literally tens of thousands of changes that must be completed before the garbage collector can be made either compacting or generational (the two properties are orthogonal, with both providing benefits).

If you are interested in following the progress of this conversion, take a look at bug 753203.

A reminder

In these MemShrink reports I usually write about Firefox changes just after they first land on mozilla-central.  Such changes will show up in Nightly builds within a day, but won’t reach an official Firefox release for 12–18 weeks, as per Firefox’s release schedule.  If you remember that you’ll avoid any confusion about which changes are in which release.

For example:  except where noted otherwise, the changes I’ve mentioned above will be in Firefox 18 — assuming they don’t cause problems that cause them to be backed out — which is due for final release in early January, 2013. (The current scheduled release date is January 1st, but that will probably be delayed slightly because New Year’s Day is not a good day for a release!)

Bug Counts

Here are the current bug counts.

  • P1: 21 (-1/+0)
  • P2: 89 (-5/+4)
  • P3: 100 (-3/+7)
  • Unprioritized: 3 (-2/+3)
Categories
add-ons Firefox Memory consumption MemShrink

MemShrink progress, week 63–64

Add-ons

The big news this week was the release of Firefox 15, which prevents most add-on memory leaks.  As a consequence, we were able to close open bug reports for several add-ons that no longer leak:  Firebug (yay!), Enter Selects, LinkResolve, We-Care Reminder, Restartless Restart + SmartSearch (the leak happened only when both were installed).

Although Firefox 15 prevents most zombie compartment leaks, some remain.

  • Scriptish still leaks.  Scriptish is a GreaseMonkey fork.  Fortunately it has many fewer users than GreaseMonkey.
  • Speed Dial creates a zombie compartment when adding a new page to the speed dial.  This was only just reported, so we don’t yet know if it pre-dated Firefox 15 or not.

I haven’t heard much feedback about the release from actual users. This is probably a good thing, as users are much more likely to notice and report problems than improvements.  One thing that has cropped up is that a small number of add-ons have had their functionality adversely affected by the change, i.e. they were accessing compartments for a page after the page has been closed.

  • This caused certain GreaseMonkey scripts to leak badly.  This has now been fixed.
  • AutoPager’s main functionality is now broken.  On the upside, it no longer leaks.  AutoPager’s author hasn’t been responsive for the past five months, unfortunately.
  • TabMix Plus is popping up some error windows that it shouldn’t.
  • Two users with many add-ons installed have reported increased memory consumption.  The add-on(s) responsible haven’t been identified yet.

If you have any additional add-ons that you think have been adversely affected by Firefox 15, open the error console and use the “filter” search box in the top right-hand corner to look for a message that says “TypeError: can’t access dead object” — that’s the message that indicates an add-on is trying to access memory via a reference that Firefox 15 has pre-emptively cut.  Please report any problems in Bugzilla and put “[MemShrink]” in the whiteboard field.

On a related note, the discussion of Firefox 15’s release on various tech sites prompted me to debunk the common misconception that Mozilla claims “this is the release that fixes the memory leaks” on every release.

Other stuff

Andrew McCreight fixed a problem involving the cycle collector that could cause occasional leaks.

Brian Nicholson roughly halved the amount of memory used in Firefox Mobile’s page readability check.  (This wasn’t actually marked as a MemShrink bug;  I just chanced upon it today when looking at TBPL.)

Nick Cameron fixed a small, obscure leak.

Google Reader

For quite a while now we’ve had various people say that Google Reader creates lots of windows and/or compartments and causes Firefox’s memory consumption to gradually increase when it’s open for a long time.  This may only happen if you are signed into a Google+ account.  It feels like it’s a problem with Google Reader itself rather than Firefox, and a Google Reader engineer is CC’d on the bug report, but no progress has been made, and the reported symptoms are on the vague side.

If you have experienced this, we’d love to hear your feedback in the bug report.  In particular, as always, reliable steps to reproduce would make a big difference.

Bug Counts

Here are the current bug counts.

  • P1: 22 (-3/+1)
  • P2: 90 (-2/+3)
  • P3: 96 (-9/+7)
  • Unprioritized: 2 (-2/+2)

Forward progress!  Good to see.

Categories
Firefox Memory consumption MemShrink

Debunking A Misconception About Firefox Releases

There is a common misconception that every time a new release of Firefox comes out Mozilla claims “this is the one that fixes the memory consumption problems”.  I see this misconception in action all the time.

The Misconception in Action

Here are some recent examples.

Reddit example 1:

NEXT VERSION OF FIREFOX IMPROVES MEMORY USAGE

Holy crap!!!

Oh wait, I feel like I’ve heard this before. Oh yea, with ever. single. new firefox release in the last 3 years. Every one.

Reddit example 2:

“Firefox 14 fixes the memory leak problem!”

“Firefox 13 finally addresses the leaky memory issue!”

“Firefox 12 – better on memory. No more leaks!”

“Firefox 11 – finally solving the leaky memory problem.”

etc etc etc

I’ll believe it when I see it.

Reddit example 3:

Firefox has finally fixed the add-on memory leak for about 10 versions now.

Hacker News example 1:

I’m not sure when Firefox got so memory-hungry and leaky, but it’s the single reason I keep jumping around to Chromium and Opera. Really, really hoping that this time is for real. It’s not the first time a blog post like this has been posted by Mozilla.

Hacker New example 2:

How many releases of firefox have we had now that claim to have fixed its memory problems? I make this at least four, which is a few too many for me to believe it this time.

Ars Technica example:

“Firefox 15 introduces a new optimization that can radically reduce the browser’s memory footprint…”

Haven’t they been saying this since Firefox 11?

This drives me crazy, because it’s simply not true.

Debunking the misconception

I looked at the announcements on the official Mozilla Blog for all the releases between Firefox 4 (March 2011) to Firefox 15 (today):  4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15.  Only three of them even mentioned the word “memory”.

  • Firefox 7.  The headline says “Mozilla Firefox Significantly Reduces Memory Use to Make Web Browsing Faster”.  The text includes: “Firefox manages memory more efficiently to deliver a nimble Web browsing experience. Users will notice Firefox is faster at opening new tabs, clicking on menu items and buttons on websites. Heavy Internet users will enjoy enhanced performance when lots of tabs are open and during long Web browsing sessions that last hours or even days.”
  • Firefox 13. The text includes: “Firefox loads tabs on demand when restoring a browsing session to more quickly get you to Web pages. Firefox first loads the tab you are currently viewing, then loads background tabs when you click them. It’s an improvement that makes Firefox start faster and use less memory.”
  • Firefox 15. The headline includes: “Firefox Now Uses Less Memory to Make Browsing Faster”.  The text says: “Firefox makes your Web experience faster by reducing memory usage when browsing with certain add-ons. The improvements make browsing smoother and more responsive.”

That’s two major mentions of memory consumption, and one minor mention, in twelve release announcements.  The major mentions were warranted — Firefox 7 greatly reduced memory consumption for Firefox itself, and Firefox 15 greatly reduced memory consumption in many cases for users with add-ons.  And the claims about improvements are clearly qualified to indicate in which circumstances they will be noticed.

But what about the release notes?  After all, although they are less prominent than the announcements on the Mozilla Blog, they’re arguably a more official description of the changes in each release.  Of the twelve releases since Firefox 4, only four of them had release notes that mentioned the word “memory”.

  • Firefox 15: “Optimized memory usage for add-ons”.
  • Firefox 8/8.0.1: “Improved performance and memory handling when using <audio> and <video> elements”.
  • Firefox 7/7.0.1: “Drastically improved memory handling for certain use cases”.
  • Firefox 5: “Improved canvas, JavaScript, memory, and networking performance”.

The Firefox 7 and 15 mentions match the release announcements.  The Firefox 5 and 8 mentions are minor.

At this point it should be clear that this really is a misconception, with no basis in fact.

What Causes the Misconception?

My best guess is that Chris Peterson nailed it with this comment.

I think the press (overly) publicized the add-on leak fix as it progressed through Firefox’s 6-week release pipeline (Nightly -> Aurora -> Beta -> Release).

In other words, it’s caused by the combination of Firefox’s rapid release schedule and the current intense interest in browser development in the tech press.

For example, a random tech press reader may have heard about the Firefox 15 add-on leak fix multiple times on different sites:  on May 8 shortly after it first landed, then again on July 19 when it entered Beta, and then again on August 29 when it was released.  (These articles correspond to increasingly prominent blog posts from Mozilla employees and Mozilla itself, such as Kyle Huey’s personal blog, the Mozilla Web Developer Blog, and the official Mozilla Blog.)  If that reader wasn’t paying close attention, it’s easy to see how they could end up with this misconception.

It’s an interesting and difficult problem.  I think it’s reasonable for Mozilla employees and Mozilla to announce important changes multiple times, at different stages of development, on different communication channels.  I also think it’s reasonable for tech press sites to report important changes at different stages of development (especially when you consider that each individual site might only mention a change once or twice).  And I don’t think it’s realistic to expect readers to remember which in-development version of Firefox it was that contained some change that they read about two or three months ago.

My only idea for a solution is ad hoc education.  So, if you see someone holding this misconception, please point them at this article!  Even better, if you can determine how they came to believe it, please let me know.

Categories
add-ons Firefox Memory consumption MemShrink

Update to GreaseMonkey 1.0 to avoid leaks in Firefox 15

Firefox 15 will be released tomorrow, and it features a fantastic change that prevents most memory leaks in add-ons, which have been a big problem for a long time.

However, recently we discovered that the change is causing some GreaseMonkey scripts to leak badly.  The scripts we know that leak are “YousableTubeFix” and “Textarea backup with expiry”, but others might have the same problem.  Fortunately, Anthony Lieuallen and Kyle Huey worked together to fix the problem, and version 1.0 of GreaseMonkey contains the fix.  If you have GreaseMonkey installed you can open the Add-ons Manager to see which version you have.  If it’s older than 1.0 (e.g. 0.9.22), you can update by visiting the GreaseMonkey page and clicking on the big green “Add to Firefox” button.

This is the only add-on we know that is adversely affected by the change in Firefox 15.  Hopefully we won’t find any more!

Categories
Benchmarks

Octane minus V8

The Google Chrome team recently extended their V8 benchmark suite with five new benchmarks, and renamed it “Octane“.  The descriptions page says the following about the new benchmarks.

  • pdf.js. Mozilla’s PDF Reader implemented in JavaScript. It measures decoding and interpretation time (33,056 lines).
  • Mandreel. Runs the 3D Bullet Physics Engine ported from C++ to JavaScript via Mandreel (277,377 lines).
  • GB Emulator. Emulate the portable console’s architecture and runs a demanding 3D simulation, all in JavaScript (11,097 lines).
  • Code loading. Measures how quickly a JavaScript engine can start executing code after loading a large JavaScript program, social widget being a common example. The source for test is derived from open source libraries (Closure, jQuery) (1,530 lines).
  • Box2DWeb. Based on Box2DWeb, the popular 2D physics engine originally written by Erin Catto, ported to JavaScript. (560 lines, 9000+ de-minified).

I haven’t looked closely at these benchmarks, but the descriptions are very promising.  Hennessy and Patterson’s classic Computer Architecture lists the following five categories of benchmarks, from best to worst.

  1. Real applications.
  2. Modified applications (e.g. with I/O removed to make it CPU-bound).
  3. Kernels (key fragments of real applications).
  4. Toy benchmarks (e.g. sieve of Erastosthenes).
  5. Synthetic benchmarks (code created artificially to fit a profile of particular operations, e.g. Dhrystone).

Four of the five new Octane benchmarks are category 1 or perhaps 2 (some have minor modifications to make them benchmarkable).  “Code loading” is the only exception;  it sounds like a kernel.  Furthermore, most of these benchmarks are large (look at those line counts!) and represent cutting-edge JavaScript code that real websites and browsers are using today (pdf.js!  jQuery!  Game engines!)

I’m not saying these benchmarks are perfect — for example, there’s arguably too much focus on games, and the use of the proprietary Mandreel instead of the open source Emscripten is unfortunate — but they certainly pass the initial “sniff test”.  [Update:  Alon Zakai has written a more detailed critique of the new benchmarks, particularly Mandreel and Box2DWeb.]  Much more so, in fact, than the existing eight benchmarks that have been carried over from V8.  I’ve listed their descriptions below;  my annotations are in square brackets.

  • Richards.  OS kernel simulation benchmark, originally written in BCPL by Martin Richards (539 lines).  [BCPL is a programming language that predates C.  Martin Richards is a former colleague of mine, and I remember him saying in 2004 that its main use these days is running the control systems for some ancient car factories in South America!]
  • Deltablue.  One-way constraint solver, originally written in Smalltalk by John Maloney and Mario Wolczko (880 lines).  [Ported SmallTalk code?!]
  • Raytrace. Ray tracer benchmark based on code by Adam Burmister (904 lines).
  • Regexp. Regular expression benchmark generated by extracting regular expression operations from 50 of the most popular web pages (1761 lines). [A kernel, but at least it comes from real websites.  However, the results of the regexp invocations are not used which makes it easy to game.]
  • NavierStokes. 2D NavierStokes equations solver, heavily manipulates double precision arrays. Based on Oliver Hunt’s code (387 lines).  [This was added to V8 only a few months ago.]
  • Crypto. Encryption and decryption benchmark based on code by Tom Wu (1698 lines).
  • Splay. Data manipulation benchmark that deals with splay trees and exercises the automatic memory management subsystem (394 lines).  [The data inserted into this splay tree is completely synthetic, which greatly limits it usefulness as a benchmark.]
  • EarleyBoyer.  Classic Scheme benchmarks, translated to JavaScript by Florian Loitsch’s Scheme2Js compiler (4684 lines).  [“Classic” here means “old”.  Also, auto-compiled Scheme code?!]

These are all much smaller.  Also, Regexp is the only one that is clearly based on code commonly run in web browsers.

In fact, these new benchmarks are so much better than the old benchmarks that I wish the Google Chrome team had instead released them as a separate benchmark suite.  That would have allowed the old benchmarks to gradually move into a well-earned retirement (along with the equally venerable and flawed SunSpider).  I guess there’s nothing stopping people from effectively doing this by running just the new benchmarks.  Perhaps this could be called the “Octane minus V8” benchmark suite…

Categories
add-ons Firefox Memory consumption MemShrink

MemShrink progress, week 61–62

It’s been a quiet fortnight for MemShrink.

The biggest news is that Kyle Huey made a change so that Firefox discards images that have been removed from the DOM.  This might sound boring, but it’s important because (among other things) it can greatly reduce the amount of memory used for photo slideshows on Facebook.  Kyle first started working on this patch nearly a year ago, and had to overcome numerous hurdles along the way.  This is a nice improvement to our foreground tab image handling, which is the #1 remaining MemShrink problem.  But there’s still lots of room to improve on that front.

The following add-ons had memory leaks fixed: 1Password, Web Developer, CoKnown Research & Webpage Clipping Toolbar, aaQQin.  The latter three were zombie compartments, a problem that Firefox 15 (due for release next week) should make impossible.  Still, it was nice of the authors to fix the problem early rather than waiting for it to be fixed for them!

Gian-Carlo Pascutto finished a huge overhaul of the SafeBrowsing implementation.  I won’t pretend to understand the changes, but it was marked as a MemShrink:P2 change and so hopefully reduced memory consumption in some notable fashion 🙂

Here are the current bug counts.

  • P1: 24 (-0/+1)
  • P2: 89 (-3/+3)
  • P3: 98 (-8/+1)
  • Unprioritized: 2 (-1/+2)

A small reduction.

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.