{"id":2554,"date":"2013-04-03T15:49:57","date_gmt":"2013-04-03T04:49:57","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=2554"},"modified":"2013-04-10T07:19:54","modified_gmt":"2013-04-09T20:19:54","slug":"memshrink-progress-week-93-94","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2013\/04\/03\/memshrink-progress-week-93-94\/","title":{"rendered":"MemShrink progress, week 93–94"},"content":{"rendered":"

After lots of activity in the previous month, the past two weeks have been fairly quiet for MemShrink.<\/p>\n

AWSY<\/h3>\n

areweslimyet.com has been proving its worth.<\/p>\n

Jonathan Kew reduced the amount of memory taken by fonts on Fennec at start-up<\/a>, which was detected by AWSY\/mobile.\u00a0 Jonathan also reverted a change that AWSY detected as increasing Fennec memory consumption<\/a>, and filed a follow-up<\/a> to investigate further.<\/p>\n

Joe Drew fixed a bad regression on AWSY relating to image decoding<\/a>.\u00a0 It’s not clear to me if this was a genuine regression that users would have seen, or if it was an artifact of the way AWSY does its measurements.\u00a0 Either way, it’s good that it was fixed, and props to Joe for doing it so quickly.<\/p>\n

Finally, we closed bug 833518<\/a>, which was for an AWSY regression caused by the new DOM bindings.\u00a0 This was previously improved by an Aurora-only hack, but enough cases have been translated to the new bindings that we’re naturally down almost to where we were.<\/p>\n

Miscellaneous<\/h3>\n

The mobile team abandoned their goal of making Fennec work on phones with only 256 MiB of memory<\/a>.\u00a0 The rationale is that Android phones with only 256 MiB of RAM are uncommon, whereas low-end phones that meet the current minimum of 384 MiB are much more common.\u00a0 The mobile team will of course continue to look for ways to improve memory consumption in order to make life for users with 384 MiB phones.<\/p>\n

I modified the JS engine so that it doesn’t emit bytecode for asm.js functions in the normal case<\/a>.\u00a0 This reduced the memory consumption of the Unreal 3 demo used at GDC by about 100 MiB. \u00a0I also added a memory reporter for array buffers used by asm.js<\/a>, which are often quite large and weren’t being measured on 64-bit platforms.<\/p>\n

Alexandre Poirot fixed a leak relating to dev tools<\/a>.<\/p>\n

Randell Jesup fixed a small leak in WebRTC<\/a>.<\/p>\n

Help Needed<\/h3>\n

I’m working on adding a button to about:memory trigger the dumping of memory reporter data to file<\/a>.\u00a0 I have a patch awaiting review, but I’m getting a test failure on Windows.\u00a0 The test saves gzipped memory reports to file, and then immediately loads that saved file (and uncompresses it) and checks the data looks as expected.\u00a0 This works fine on Mac and Linux, but on Windows I’m sometimes getting incomplete data in the load step.\u00a0 The file is quite short (just 253 bytes compressed, and 620 bytes uncompressed) and the truncation point varies between runs;\u00a0 in the most severe occurrence only 9 bytes of uncompressed data were loaded, though the cut-off point seems to vary randomly.<\/p>\n

I suspect there’s a file synchronization problem between the save and the load, even though gzclose() is called on the save file before the loading occurs.\u00a0 If anyone has ideas about what the problem might be, I’d love to hear them.<\/p>\n

Update: Nils Maier and an anonymous commenter pointed out the problem — I was using “r” instead of “rb” for the file mode.\u00a0 On Windows, this causes mangling of EOL chars<\/a>.<\/strong><\/p>\n

Also, we’re seeing some strange behaviour on Mac OS X where memory managed by jemalloc doesn’t appear to be released back to the OS as it should<\/a>.\u00a0 This is both alarming and hard to understand, which is not a good combination.<\/p>\n

Good First Bugs<\/h3>\n

I have two easy bugs assigned to me that I probably won’t get around to for some time.\u00a0 Both of them would be good first (or second, or third…) bugs.<\/p>\n