B2G!\u00a0 Fennec!\u00a0 Social API!\u00a0 They’re all happening, and memory consumption is a big deal for all of them.\u00a0 Time for a MemShrink report.<\/p>\n
Lots of B2G work is happening, unsurprisingly.\u00a0 All of these changes have been backported to the Aurora channel.<\/p>\n
Kyle Huey landed an important patch that merges system compartments together<\/a>.\u00a0 This avoids wasted space caused by having 100s of small compartments.\u00a0 As Chris Jones said:<\/a> “It’s a completely different phone with these patches.”\u00a0 Unfortunately, the preference controlling this behaviour is currently turned off on B2G, because it’s causing some Marionette test failures.\u00a0 Hopefully they’ll be dealt with soon.\u00a0 Note that this preference won’t be turned on in desktop builds, and there’s a medium-term plan<\/a> to avoid this wasted space in a less hacky fashion.<\/p>\n Marco Bonardo disabled Places in B2G<\/a>, saving about 300 KiB in the main process.<\/p>\n Justin Lebar added code to trigger memory pressure events when lowmemkiller notifications occur.<\/p>\n Justin also tweaked things so that the garbage collector is more likely to run when screenshots are taken<\/a>.<\/p>\n Jeff Muizelaar fixed a graphics bug<\/a> that I don’t understand but apparently avoids allocating lots of memory on the B2G unlock screen.<\/p>\n Chris Jones ensured that\u00a0remote content drop their buffers when they’re hidden<\/a>.<\/p>\n I tweaked the size of the arena chunks used by XPT<\/a>, which saved about 120 KiB per process on 64-bit builds, and a bit less on 32-bit builds.<\/p>\n I also shrunk the initial size of the SPS hash table<\/a>, which saves 48 KiB per process on 64-bit builds and 24 KiB on 32-bit builds.<\/p>\n Lots of work happened on the memory reporting front.\u00a0 This was inspired by\u00a0 “heap-unclassified” typically being much higher on B2G than on desktop.\u00a0 Desktop Firefox uses a single process and its memory consumption is usually measured in the 100s of MiBs or more.\u00a0 In contrast, B2G uses one “main” process and then one process per running app, and the smaller ones are typically around 10 MiB.\u00a0 As a result, the sundry small per-process things that don’t matter much for desktop loom larger on B2G.\u00a0 (For the same reason, changes that reduce per-process memory by smallish amounts have outsize value on B2G.)\u00a0 Most of the following changes have also been backported to the Aurora channel.<\/p>\n Nick Hurley added a “explicit\/network\/disk-cache” memory reporter<\/a>.\u00a0 It typically measures 100s of KiBs in desktop Firefox.\u00a0 (It doesn’t get used on B2G.)<\/p>\n I added memory reporters “explicit\/xpcom\/component-manager” and “explicit\/xpcom\/category-manager”<\/a>.\u00a0 Together they measure about 280 KiB per process on 64-bit builds, and a bit less on 32-bit builds.<\/p>\n I added a memory reporter “explicit\/script-namespace-manager”<\/a>.\u00a0 It measures just over 150 KiB per process on 64-bit builds, and a bit less on 32-bit builds.<\/p>\n I added a memory reporter “explicit\/xpcom\/effective-TLD-service”<\/a>.\u00a0 It measures about 128 KiB per process on 64-bit builds, and a bit less on 32-bit builds.<\/p>\n I added some detail to the JS object memory reporters<\/a>.\u00a0 This gives slightly more insight into where this memory is going, but the extra memory measured as a result is usually pretty small.<\/p>\n I fixed the “explicit\/atom-tables” memory reporter<\/a>, which was erroneously always reporting 0 bytes.\u00a0 It now measures anywhere from a few 100 KiBs to several MiBs of memory.\u00a0 This was a frustrating bug to find.\u00a0 DMD<\/a> exists to check that memory reporters are measuring memory properly, and the reporter was doing its measurements just fine.\u00a0 But DMD cannot check that the measured amounts are added correctly, and that’s what was going wrong here — a line that should have been this:<\/p>\n instead was this:<\/p>\n In other words, the code I had written was doing the difficult part correctly, but botched the trivial part.\u00a0 How annoying.<\/p>\n Felipe Gomes fixed a document leak<\/a> that occurred when the social sidebar was hidden, and disappeared only when it was unhidden.<\/p>\n Felipe also added code to clear the previous profile when Social is toggled off<\/a>, which prevents a leak.<\/p>\n The social API still has some\u00a0significant unresolved memory consumption issues<\/a>, which are a concern.<\/p>\n Kartikaya Gupta (a.k.a. Kats) turned on tab expiration<\/a> for Fennec.\u00a0 What this means is that Fennec will now unload the contents of background tabs in certain circumstances — when memory is low, and in some cases when a tab hasn’t been viewed for over an hour — and then reload them when they are brought back into the foreground.\u00a0 Read Kats’ blog post<\/a> for more details.<\/p>\n (This change was prompted by Project 256meg<\/a>, which aims to make Fennec usable on phones with only 256 MiB of RAM.\u00a0 (Fennec currently requires 512 MiB, according to the official specs<\/a>.)\u00a0 Kats has just got to the point where Fennec can actually start<\/a> on 256 MiB devices.\u00a0 Although Fennec only uses a single process, there is obviously significant overlap between this goal and B2G’s memory reduction goals.)<\/p>\n An obvious follow-up idea is to add tab expiration to desktop Firefox.\u00a0 But the bug tracking that idea<\/a> has seen more heated discussion.\u00a0 The reason is that tab expiration might cause data loss in some cases.\u00a0 This is less of a problem on Fennec because (as far as I can tell) there is less of an expectation that in-flight data will be saved on mobile devices.\u00a0 For example, having processes killed due to memory constraints on mobile is much more common than on desktop.\u00a0 Still, I expect plenty more arguing before this issue is resolved one way or the other.\u00a0 One option is to allow it on desktop but have it disabled by default.<\/p>\n Michel Gutierrez fixed a zombie compartment in Video DownloadHelper<\/a>, which is the 2nd most popular add-on at AMO. \u00a0 Version 4.9.11 has the fix.<\/p>\n We hit a notable milestone on the add-on front this fortnight:\u00a0 on November 1st hit bug for tracking known leaks in add-ons<\/a> — filed 16 months ago — had zero blockers.\u00a0 In other words, we reached the point where no add-ons were known to leak!\u00a0 Unfortunately this didn’t last long, and at the time of writing the tracking bug has three blocking bugs.\u00a0 Still, it’s confirmation that what used to be our biggest memory consumption problem is well under control.<\/p>\n Here are the current bug counts.<\/p>\nMemory Reporting<\/h3>\n
return n;<\/code><\/pre>\nreturn 0;<\/code><\/pre>\nSocial API<\/h3>\n
Fennec<\/h3>\n
Add-ons<\/h3>\n
Bug Counts<\/h3>\n