Confirm
1,345
edits
Changes
no edit summary
# "Slimmer" memory usage, e.g. more space-efficient data structures.
# Avoiding "leaks". This loose use of the term (which is used throughout this document) includes both true :* True leaks (, where memory is lost forever) and "quasi-leaks" (.* Lifetime issues, where memory is not lost but held on for too long, reclaimed until you close the page/tab/window/process.* Collection heuristic issues (e.g. due to GC is too infrequent garbage collectionin certain cases).* Bad cache algorithms and poorly tuned caches.* Fragmentation.
Leaks are generally more important, as they are more likely to lead to horrible performance.
== Meetings ==
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.
Ideally, these weekly meetings would only be needed for a medium length of time, say 1 or 2 quarters. Hopefully after that, things will have improved enough that meetings could be less frequent (bi-weekly or monthly) or not needed at all.
== Tracking Current Leaks ==
We get lots of leak reports. Many of them are vague. It can be hard to tell when duplicates happen. They often aren't closed. This means that tracking them at a coarse granulatiry granularity (eg. the "mlk" keywordand "footprint" keywords) ends up being of little use. So it's worthwhile tracking them on a per-release basis.
* {{bug|659855}} is for leaks and quasi-leaks reported against Firefox 4 betas
