{"id":2636,"date":"2013-07-10T16:22:53","date_gmt":"2013-07-10T05:22:53","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=2636"},"modified":"2013-07-10T17:51:08","modified_gmt":"2013-07-10T06:51:08","slug":"memshrink-progress-week-105-108","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2013\/07\/10\/memshrink-progress-week-105-108\/","title":{"rendered":"MemShrink progress, week 105–108"},"content":{"rendered":"

This is the first of the every-four-weeks MemShrink reports that I’m now doing.\u00a0 The 21 bugs<\/a> fixed in the past four weeks include 11 leak fixes, which is great, but I won’t bother describing them individually.\u00a0 Especially when I have several other particularly impressive fixes to describe…<\/p>\n

Image Handling<\/h3>\n

Back in March I described how Timothy Nikkel had greatly improved Firefox’s handling of image-heavy pages<\/a>.\u00a0 Unfortunately, the fix had to be disabled in Firefox 22 and Firefox 23 because it caused jerky scrolling on pages with lots of small images, such as Pinterest.<\/p>\n

Happily, Timothy has now fixed those problems<\/a>, and so his previous change has been re-enabled in Firefox 24.\u00a0 This takes a big chunk out of the #1 item on the MemShrink big ticket items list<\/a>.\u00a0 Fantastic news!<\/p>\n

Lazy Bytecode Generation<\/h3>\n

Brian Hackett finished implementing lazy bytecode generation<\/a>.\u00a0 This change means that JavaScript functions don’t have bytecode generated for them until they run.\u00a0 Because lots of websites use libraries like jQuery, in practice a lot of JS functions are never run, and we’ve found this can reduce Firefox\u2019s memory consumption by 5% or more on common workloads!\u00a0 That\u2019s a huge, general improvement.<\/p>\n

Furthermore, it significantly reduces the number of things that are allocated on the GC heap (i.e. scripts, strings, objects and shapes that are created when bytecode for a function is generated).\u00a0 This reduces pressure on the GC which makes it less likely we\u2019ll have bad GC behaviour (e.g. pauses, or too much memory consumption) in cases where the GC heuristics aren\u2019t optimal.<\/p>\n

The completion of this finished off item #5 on the old Memshrink big ticket items list<\/a>.\u00a0 Great stuff.\u00a0 This will be in Firefox 24.<\/p>\n

Add-on Memory Reporting<\/h3>\n

Nils Maier implemented add-on memory reporting in about:memory<\/a>.\u00a0 Here’s some example output from my current session.<\/p>\n

\u251c\u2500\u2500\u250033,345,136 B (05.08%) -- add-ons\r\n\u2502\u00a0\u00a0 \u251c\u2500\u250018,818,336 B (02.87%) ++ {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}\r\n\u2502\u00a0\u00a0 \u251c\u2500\u250011,830,424 B (01.80%) ++ {59c81df5-4b7a-477b-912d-4e0fdf64e5f2}\r\n\u2502\u00a0\u00a0 \u2514\u2500\u2500\u25002,696,376 B (00.41%) ++ treestyletab@piro.sakura.ne.jp\/js-non-window\/zones\/zone(0x7fbd7bf53800)<\/pre>\n
It’s obvious that Tree Style Tabs is taking up 2.7 MB.\u00a0 What about the other two entries?\u00a0 It’s not immediately obvious, but if I look in about:support at the “extensions” section I can see that they are AdBlock Plus and ChatZilla.<\/p>\n
If you’re wondering why those add-ons are reported as hex strings, it’s due to a combination of the packaging of each individual add-on, and the fact that the memory reporting code is C++ and the add-on identification code is JS and there aren’t yet good APIs to communicate between the two.\u00a0 (Yes, it’s not ideal and should be improved, but it’s a good start.)\u00a0 Also, not all add-on memory is reported, just that in JS compartments;\u00a0 old-style XUL add-ons in particular can have their memory consumption under-reported.<\/p>\n
Despite the shortcomings, this is a big deal.\u00a0 Users have been asking for this information for years<\/em>, and we’ve finally got it.\u00a0 (Admittedly, the fact that we’ve tamed add-on leaks makes it less important than it used to be, but it’s still cool.)\u00a0 This will also be in Firefox 24.<\/p>\n
b2g<\/h3>\n
Gregor Wagner has landed a nice<\/a> collection<\/a> of patches to help the Twitter and Notes+ apps on B2G.<\/p>\n
While on the topic of B2G, in today’s MemShrink meeting we discussed the ongoing problem of slow memory leaks in the main B2G process.\u00a0 Such leaks can cause the phone to crash or become flaky after its been running for hours or days or weeks, and they’re really painful to reproduce and diagnose.\u00a0 Our partners are finding these leaks when doing multi-hour stress tests as part of their QA processes.\u00a0 In contrast, Mozilla doesn’t really have any such testing, and as a result we are reacting, flat-footed, to external reports, rather than catching them early ourselves.\u00a0 This is a big problem because users will rightly expect to have their phones run for weeks (or even months) without rebooting.<\/p>\n
Those of us present at the meeting weren’t quite sure how we can improve our QA situation to look for these leaks.\u00a0 I’d be interested to hear any suggestions.\u00a0 Thanks!<\/p>\n","protected":false},"excerpt":{"rendered":"
This is the first of the every-four-weeks MemShrink reports that I’m now doing.\u00a0 The 21 bugs fixed in the past four weeks include 11 leak fixes, which is great, but I won’t bother describing them individually.\u00a0 Especially when I have several other particularly impressive fixes to describe… Image Handling Back in March I described how […]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4550,119,30,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/2636"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/users\/139"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/comments?post=2636"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/2636\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=2636"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=2636"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=2636"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}