{"id":1687,"date":"2012-02-01T16:35:58","date_gmt":"2012-02-01T05:35:58","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=1687"},"modified":"2012-02-01T16:35:58","modified_gmt":"2012-02-01T05:35:58","slug":"memshrink-progress-week-33","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2012\/02\/01\/memshrink-progress-week-33\/","title":{"rendered":"MemShrink progress, week 33"},"content":{"rendered":"

about:memory<\/h3>\n

Up until this week, about:memory was a static pages;\u00a0 once generated, it couldn’t change.\u00a0 This week, I landed a patch that makes every sub-tree expandable and collapsible<\/a>.\u00a0 \u00a0 This can be quite useful, because it gives you fine control over what details to ignore. \u00a0The following screenshot shows an example where all the level 1 sub-trees in the “explicit” tree are collapsed except for “startup-cache”.\u00a0 (++<\/code> indicates sub-trees that can be expanded, --<\/code> indicates sub-trees that can be collapsed, and the remaining nodes (such as “heap-unclassified”) are leaf nodes).<\/p>\n

\"a<\/a><\/p>\n

I also changed about:memory so that obviously bogus values (e.g. negative values, percentages greater than 100%) are highlighted<\/a>.\u00a0 These indicate bugs in memory reporters, and so we want to know about them.<\/p>\n

Memory Reporters<\/h3>\n

I added new memory reporters for style sheets<\/a>.\u00a0 This was the single biggest remaining chunk of dark matter.\u00a0 On a 64-bit Linux build, this reduces the “heap-unclassified” count when I have Gmail and TechCrunch open from ~23% to ~15%.\u00a0 The counts mostly show up under the “explicit\/dom+style” sub-tree, in “style-sheets” leaf nodes.<\/p>\n

I also simplified the writing of memory reporters by removing the need for the computedSize<\/code> argument when measuring the size of a heap block<\/a>.<\/p>\n

Finally, if you create a sandbox with Components.utils.Sandbox<\/code>, you can specify a name and about:memory will use that name to identify the sandbox’s compartment.\u00a0 Sander van Veen made it so that sandboxes that aren’t given a name will use the\u00a0 their callers’ filename as a name<\/a>.\u00a0 In other words, all sandboxes should now be identifiable in about:memory.<\/p>\n

leaks<\/h3>\n

Brian Hackett fixed a leak in JaegerMonkey<\/a>.<\/p>\n

Andrew McCreight fixed a leak caused by watchpoints<\/a>, which are used when debugging JavaScript code.<\/p>\n

A leak related to JavaScript sharps<\/a> (a non-standard, SpiderMonkey-only feature) was fixed by Jeff Walden when he removed support for sharps<\/a> \ud83d\ude42<\/p>\n

Add-ons<\/h3>\n

I mentioned last week that I think leaky add-ons are the #1 problem for Firefox’s memory consumption, and mentioned the idea of telling users when they have an add-on installed that is known to have performance problems.\u00a0 Bug 720856<\/a> is open for this.\u00a0 Asa Dotzler, Firefox Product Manager, said<\/a>:<\/p>\n

\n

I will secure Firefox client developer resources for this feature where I have some input into resourcing. If this plan is deemed appropriate, I will work with Justin to secure AMO side resources as well and we can nail this problem.<\/p>\n

We can’t keep going back and forth on this while our users suffer. We must act now. I understand that defining “bad add-ons” will be contentious but so long as the technical approach is righteous we can sort out how heavy handed we want to be on policy at a later time and move forward implementing this today.<\/p><\/blockquote>\n

There was already a feature page<\/a> covering this basic idea, and Asa updated it. This feature would be a huge help to users.\u00a0 Fingers crossed we’ll see some progress soon!<\/p>\n

Henrik Skupin has started working on an add-on called MemChaser<\/a> (download it here<\/a>) which is aimed at helping detect problems relating to memory consumption.\u00a0 Currently it just shows some stats in the add-on bar — resident memory consumption (updated every two seconds), how long the last garbage collection took, and how long the last cycle collection took — but Henrik has many<\/a> ideas <\/a>for the future.\u00a0 Worth watching!<\/p>\n

Bug Counts<\/h3>\n

Here are this week\u2019s bug counts.<\/p>\n

    \n
  • P1: 22 (-0\/+2)<\/li>\n
  • P2: 130 (-3\/+2)<\/li>\n
  • P3: 74 (-2\/+2)<\/li>\n
  • Unprioritized: 3 (-4\/+3)<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

    about:memory Up until this week, about:memory was a static pages;\u00a0 once generated, it couldn’t change.\u00a0 This week, I landed a patch that makes every sub-tree expandable and collapsible.\u00a0 \u00a0 This can be quite useful, because it gives you fine control over what details to ignore. \u00a0The following screenshot shows an example where all the level […]<\/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\/1687"}],"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=1687"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/1687\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=1687"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=1687"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=1687"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}