{"id":2417,"date":"2013-01-23T15:58:05","date_gmt":"2013-01-23T04:58:05","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=2417"},"modified":"2013-02-06T10:41:37","modified_gmt":"2013-02-05T23:41:37","slug":"memshrink-progress-week-83-84","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2013\/01\/23\/memshrink-progress-week-83-84\/","title":{"rendered":"MemShrink progress, week 83–84"},"content":{"rendered":"

Fixed<\/h3>\n

Justin Lebar made it so that memory reports could be collected on production B2G phones<\/a> (i.e. not just developer phones with root access).\u00a0 This was a MemShrink:P1, because getting these reports is crucial.<\/p>\n

Gregor Wagner tuned the GC heuristics used by workers<\/a>.\u00a0 This is important for B2G, which uses workers extensively.<\/p>\n

Andrew McCreight fixed a leak involving audio contexts<\/a>.<\/p>\n

I added a memory reporter for event targets, which includes XHRs<\/a>.\u00a0 This can measure multiple MiB of memory when running Gmail.<\/p>\n

I added a memory reporter for data held by the JS engine’s regexp JIT compiler<\/a>.\u00a0 It usually measures insignificant amounts.<\/p>\n

I fixed an inaccuracy in the “resident” memory report tree<\/a>, which is visible in about:memory when running on Linux, which was caused by a change in recent kernels.<\/p>\n

AWSY<\/h3>\n

The recent results on AWSY<\/a> have been ugly.\u00a0 There were two bad regressions in December, as the following graph makes clear.<\/p>\n

\"areweslimyet.com,<\/a><\/p>\n

John Schoenick did some work to improve AWSY to make regression hunting easier, and as a result we finally know which changes caused these regressions.<\/p>\n