Confirm
1,345
edits
Changes
no edit summary
MemShrink aims to reduce Firefox's memory consumption. There are three potential benefits:
# Speed: less cachepressure, and less paging. The latter is crucial, as it can destroy performance.
# Stability: fewer OOMs, whether due to address space exhaustion or otherwise. This results in fewer crashes (due to mishandling of OOM) or aborts.
# Perception: fewer people will complain about Firefox being a memory hog.
MemShrink is modelled on [[CrashKill]] and [[CritSmash]]. The most important thing is to have weekly meetings in which leak reports can be triaged and assigned to people. We have many leak reports and not many people looking into them.
== Tracking Current Leaks ==
We get lots of leak reports. Many of them are vague. It can be hard to tell when duplicates happen. So it's worthwhile tracking them on a per-release basis.
* {{bug|640457}} for other memory use reductions in Firefox 5
* {{bug|640791}} for improvements to memory profiling in Firefox 5
== The goal ==
To get the number of leaks reported against a single version of Firefox down to zero, and keep it there.
== Avoiding new leaks ==
There are two ways to avoid new leaks. The first is to
== areweslimyet.com ==
== Better Metrics ==
* Total "explicit" is the memory is only moderately relevant, because lots of mapped pages aren't touched and so don't cost anything. (Thread stacks are a good example -- they're 8MB each on 64-bit Linux.) The exception is on 32-bit machines where address space exhaustion is possible.* RSS (resident set size) is more relevant from a performance point of view. But it's controlled explicitly requested by some more-or-less opaque kernel page discard algorithm, and depends on the behaviour of all processes in the systembrowser, which isn't great. But if tests were always run on at the same machine and the browser was the only thing runningheap level (malloc, this might not be too bad. (No good for measuring once you get past peaknew, because jemalloc holds onto pages containing freed heap blocks? Not sure about that.etc)* We could do something like and the size of all heap allocations plus other notable non-heap allocations OS level (like code pages allocated by the JITsmmap, VirtualAlloc, etc). This requires some internal accounting and so The heap-level component is hard accurate thanks to compare against other browsers.* What do we do about multiple processes? jemalloc; Measure them all and sum the numbers?* There seems to be a lot of nonOS-determinism in browser memory usage, which makes pinpointing small regressions/improvements difficult.* Do we only measure peak usage? Or do we want to open and close lots of tabs to try to catch leaks?* jseward's [http://blog.mozilla.com/jseward/2011/01/27/profiling-the-browsers-virtual-memory-behaviour/ VM-sim extension to Cachegrind] takes a different tack; level component is an underestimate because it measures page faults relies on a quasi-idealized machine. It's slow, thoughhaving memory reporters in place.
== A Clear Goal ==
* Keep going until commenters on slashdot/Ars/reddit/etc stop complaining??
Just to get discussion going...
