{"id":2623,"date":"2013-06-15T01:03:31","date_gmt":"2013-06-14T14:03:31","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=2623"},"modified":"2013-06-15T01:03:31","modified_gmt":"2013-06-14T14:03:31","slug":"memshrinks-2nd-birthday","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2013\/06\/15\/memshrinks-2nd-birthday\/","title":{"rendered":"MemShrink&#8217;s 2nd Birthday"},"content":{"rendered":"<p>June 14, 2013 is the second anniversary of the first MemShrink meeting.\u00a0 This time last year I took the opportunity to write about <a href=\"https:\/\/blog.mozilla.org\/nnethercote\/2012\/06\/15\/memshrinks-1st-birthday\/\">the major achievements from MemShrink&#8217;s first year<\/a>.\u00a0 Unsurprisingly, since then we&#8217;ve been picking fruit from higher in the tree, so the advances have been less dramatic.\u00a0 But it&#8217;s been 11 months since I last update the <a href=\"https:\/\/blog.mozilla.org\/nnethercote\/2012\/07\/11\/memshrink-progress-week-55-56\/\">&#8220;big ticket items&#8221; list<\/a>, so I will take this opportunity to do so, providing a partial summary of the past year at the same time.<\/p>\n<h3>The Old Big Ticket Items List<\/h3>\n<h4>#5: Better Script Handling<\/h4>\n<p>This had two parts.\u00a0 The first part was the <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=679942\">sharing of immutable parts of scripts<\/a>, which Till Schneidereit implemented.\u00a0 It can save multiple MiBs of memory, particular if you have numerous tabs open from the same website.<\/p>\n<p>The second part is <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=678037\">lazy bytecode generation<\/a>, which Brian Hackett has implemented and landed, though it hasn&#8217;t yet enabled.\u00a0 Brian is working out the remaining kinks and hopes to land by the end of the current (v24) cycle.\u00a0\u00a0\u00a0 Hopefully he will, because measurements have shown that it can reduce Firefox&#8217;s memory consumption by 5% or more on common workloads!\u00a0 That&#8217;s a huge, general improvement.\u00a0 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&#8217;ll have bad GC behaviour (e.g. pauses, or too much memory consumption) in cases where the GC heuristics aren&#8217;t optimal.<\/p>\n<p>So the first part is done and the second is imminent, which is enough to cross this item off the list.\u00a0 [Update:\u00a0 Brian <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=678037#c93\">just enabled lazy bytecode on trunk<\/a>!]<\/p>\n<h4>#4: Regain compartment-per-global losses<\/h4>\n<p>Bill McCloskey implemented <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=759585\">zones<\/a>, which restructured the heap to allow a certain amount of sharing between zones. This greatly reduced wasted space and reduced memory consumption in common cases by ~5%.<\/p>\n<p>Some more could still be done for this issue.\u00a0 In particular, it&#8217;s not clear if things have improved enough that many small JSMs can be used without wasting memory.\u00a0 Nonetheless, things have improved enough that I&#8217;m happy to take this item off the list.<\/p>\n<h4>#3: Boot2Gecko<\/h4>\n<p>This item was about getting about:memory (or something similar) working on B2G, and using it to optimize memory.\u00a0 This was done some time ago and the memory reporters (plus DMD) were enormously helpful in improving memory consumption.\u00a0 Many of the fixes fell under the umbrella of <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=797189\">Operation Slim Fast<\/a>.<\/p>\n<p>So I will remove this particular item from the list, but memory optimizations for B2G are far from over, as we&#8217;ll see below.<\/p>\n<h4>#2: Compacting Generational GC<\/h4>\n<p>See below.<\/p>\n<h4>#1: Better Foreground Tab Image Handling<\/h4>\n<p>See below.<\/p>\n<h3>The New Big Ticket Items List<\/h3>\n<h4>#5: pdf.js<\/h4>\n<p>pdf.js was recently made the default way of opening PDFs in Firefox, replacing plug-ins such as Adobe Reader.\u00a0 While this is great in a number of respects, such as security, it&#8217;s not as good for memory consumption, because <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=881974\">pdf.js can use a lot of memory<\/a> in at least some cases.\u00a0 We need to investigate the known cases and improve things.<\/p>\n<h4>#4: Dev tools<\/h4>\n<p>While we&#8217;ve made great progress with memory profiling tools that help Firefox developers, the situation is not nearly as good for web developers.\u00a0 Google Chrome has heap profiling tools for web developers, and Firefox should too.\u00a0 (The design space for heap profilers is quite large and so Firefox shouldn&#8217;t just copy Chrome&#8217;s tools.)\u00a0 Alexandre Poirot has started work on a <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=863228\">promising prototype<\/a>, though there is a lot of work remaining before any such prototype can make it into a release.<\/p>\n<h4>#3: B2G Nuwa<\/h4>\n<p>Cervantes Yu and Thinker Li have been working on <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=771765\">Nuwa<\/a>, which aims to give B2G a pre-initialized template process from which every subsequent process will be forked.\u00a0 This might sound esoteric, but the important part is that it greatly increases the ability for B2G processes to share unchanging data.\u00a0 In <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=771765#c29\">one test run<\/a>, this increased the number of apps that could be run simultaneously from five to <em>nine<\/em>, which is obviously a big deal.\u00a0 The downside is that getting it to work requires some extremely hairy fiddling with low-level code.\u00a0 Fingers crossed it can be made to work reliably!<\/p>\n<p>Beyond Nuwa, there is still plenty of other ways that B2G can have its memory consumption optimized, as you&#8217;d expect in an immature mobile OS.\u00a0 Although I won&#8217;t list anything else in the big ticket items list, work will continue here, as per <a href=\"https:\/\/wiki.mozilla.org\/Performance\/MemShrink\">MemShrink&#8217;s primary aim:<\/a> &#8220;MemShrink is a project that aims to reduce the memory consumption of Firefox (on desktop and mobile) and Firefox OS.&#8221;<\/p>\n<h4>#2: Compacting Generational GC<\/h4>\n<p>Generational GC will reduce fragmentation, reduce the working set size, and speed up collections.\u00a0 Great progress has been made here &#8212; the enormous task of <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=753203\">exactly rooting<\/a> the JS engine and the browser is basically finished, helped along greatly by a static analysis implemented by Brian Hackett.\u00a0 And Terrence Cole and others are well into converting the collector to be generational.\u00a0 So we&#8217;re a lot closer than we were, but there is still some way to go.\u00a0 So this item is steady at #2.<\/p>\n<h4>#1: Better Foreground Tab Image Handling<\/h4>\n<p>Firefox still uses much more memory than other browsers on image-heavy pages.\u00a0 Fortunately, a great deal of progress has been made here.\u00a0 Timothy Nikkel <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=689623\">fixed things<\/a> so that memory usage when scrolling through image-heavy pages is greatly reduced.\u00a0 However, this change caused some <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=845147\">jank on pages with lots of small images<\/a>, so it&#8217;s currently disabled on the non-trunk branches.\u00a0 Also, there is still a memory spike when\u00a0<a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=847223\">memory-heavy pages are first loaded<\/a>, which needs to be fixed before this item can be considered done.\u00a0 So this item remains at #1.<\/p>\n<h4>Summary<\/h4>\n<p>Three items from the old list (#3, #4, #5) have been ticked off.\u00a0 Two items remain (#1, #2) &#8212; albeit with good progress having been made &#8212; and keep their positions on the list.\u00a0 Three items have been added to the new list (#3, #4, #5).<br \/>\nLet me know if I&#8217;ve omitted anything important!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>June 14, 2013 is the second anniversary of the first MemShrink meeting.\u00a0 This time last year I took the opportunity to write about the major achievements from MemShrink&#8217;s first year.\u00a0 Unsurprisingly, since then we&#8217;ve been picking fruit from higher in the tree, so the advances have been less dramatic.\u00a0 But it&#8217;s been 11 months since [&hellip;]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4261,30,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/2623"}],"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=2623"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/2623\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=2623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=2623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=2623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}