MemShrink progress, week 87–88

SpiderMonkey

Till Schneidereit implemented sharing of bytecode and related script data.  This can result in significant savings, especially if you have multiple tabs open from the same site.  For example, with 10 articles open from theage.com.au I saw an 11.6 MiB saving.  This was a MemShrink:P1, and its fix completes half of the “Better Script Handling” item from the MemShrink big ticket items list.

Terrence Cole fixed a bad regression that was causing multi-GiB memory spikes when using certain regular expressions.  He landed this fix on the Nightly, Aurora and Beta channels.

I reduced the overhead of small compartments a little.  This reduced the size of an unloaded tab from 222 KiB to 192 KiB on 64-bit platforms.

Jason Orendorff removed some source notes that are no longer required now that SpiderMonkey’s decompiler has been removed.  This slightly reduces the size of the “script-data” entries in about:memory.

I modified js::Vector so that it doesn’t waste space when its elements have a size that is not a power of two.

B2G

Chris Jones fixed a bad leak in the IPC code.  This is a big deal because B2G testing has found several cases of steadily growing memory consumption that lead to the devices becoming unusable, and there’s a good chance that this leak was responsible for some of them.  More testing is needed to determine exactly how many problems this has fixed.

It’s not surprising that IPC code is causing B2G problems, because that is code that desktop Firefox uses only lightly (for out-of-process plug-ins), whereas B2G uses it very heavily.  There’s a bug open for detecting such leaks that should be fairly easy to implement, and potentially could lead to big fixes, which is currently looking for an owner.

Miscellaneous

Timothy Nikkel reduced the memory consumed by display:none elements.  This was a tricky bug that was landed and then backed out multiple times due to subtle test failures.  And while this bug has benefits of its own, it is most notable for the fact that it was blocking bug 689623, which is the key bug that will help us start to fix Firefox’s problems with image-heavy pages.  (And 689623 itself is close to landing now, with 13 r+’d patches.)

Matthew Gregan fixed a bug, present only in Firefox 17 ESR, that was causing HTML5 videos to consume multiple GiBs of memory.

Alexandre Poirot fixed another leak in the Add-on SDK.

Jonathan Kew reduced the amount of memory consumed by textruns when Facebook Messenger is enabled.

David Keeler fixed a leak relating to IndexedDatabaseManager.

Bug Counts

Here are the current bug counts.

  • P1: 17 (-7/+8)
  • P2: 128 (-10/+19)
  • P3: 117 (-2/+15)
  • Unprioritized: 2 (-22/+2)

Lots of movement there.  The -7 P1s is mostly due to a number of bugs being downgraded;  these were bugs that seems important previously but now seem less important.  (For those who are interested, the bug numbers were: 679942, 763252, 764220, 770612, 819839, 829417, 833518.)

7 Responses to MemShrink progress, week 87–88

  1. Very excited about 689623 progress. Tumblr, Facebook… With all the infinite scrolling, image-heavy sites cropping up nowadays, it’s going to be huge.

  2. Sorry Nick, I did a few search and nothing useful came up. I remembered you briefly explain the problem. Assuming I Load up 100 Sites, after 20 min I close down to 20 . The Memory consuming was 800MB in about:memory, even after i press the minimize memory usage a few times.

    Now I restarted the browser, reload all the tabs, let it sit there for 10 min and it is only about 600MB.

    Where did that 200MB went?

    And if there are any tools to check what Firefox is using my CPU usage for? Even after those sites finish loading and settle down the Firefox CPU resources tend to spike a lot. ( I know this is properly not your/memshrink area but I though the spike may have to do with GC? )

  3. What an exciting post.
    Kudos and good job to everyone who’s worked on these bugs!

  4. Hello. It’s “Alexandre Poirot”, not “Alexander”. bye. ;)

  5. Is there any reason why “sharing of bytecode and related script data” is domain specific? Since the bug started out as not.