Peter Van der Beken fixed a leak caused by chrome code that injects a function into pages. This was a MemShrink P1 bug. The commentary in the bug is confusing, but this may have been affecting numerous add-ons including Firebug. (Bug 669730 is open for tracking leaks in Firebug; it hasn’t yet been confirmed whether this fix has helped Firebug.)
Andrew McCreight rewrote JS_DumpHeap so that it dumps the complete JS object graph. This was a MemShrink P1 bug because it’s an important piece of infrastructure for writing leak detection tools.
Brian Hackett tweaked the JS engine so that more method JIT code can be discarded periodically, particularly chrome code in system compartments.
Oleg Romashin avoided using transparent layers in Fennec remote offscreen viewports. This saves 5MB of memory in the active tab.
I added a memory reporter for the startup cache. This is often around 1MB of memory, but it’s allocated via mmap/VirtualAlloc and so doesn’t change the “heap-unclassified” number in about:memory.
Boris Zbarsky fixed a small leak involving CSS transforms.
The current bug counts are as follows.
- P1: 35 (-5, +3)
- P2: 113 (-3, +8)
- P3: 54 (-0, +1)
- Unprioritized: 4 (-5, +3)
I want to point out this bug, which presents an idea to help hunt down reproducible leaks that occur when users have multiple add-ons present. This is important because many of the leaks reported by users recently are due to add-ons, but often the reporter has many add-ons installed which makes finding the culprit painful. The goal is to write a Firefox add-on that selectively disables installed add-ons, so that a user can bisect them to discover which add-on is responsible for the leak. This bisecting process is something that people can do manually, but an add-on that automates the process would make things easier and less error-prone. Mercurial’s ‘hg bisect’ command would serve as a useful comparison. Ehsan Akhgari has volunteered to mentor anyone who would like to try to implement this.