Firefox MemShrink

MemShrink progress, week 121–124

It’s been a quiet but steady four weeks for MemShrink with 19 bugs fixed, including several leaks.

The only fix that I feel is worth highlighting is bug 918207, in which I added support for fast, coarse-grained measurement of a tab’s memory consumption.  The implemented machinery isn’t currently exposed through the UI, though there are two bugs open that will use it:  a simple one that will implement a command for the developer toolbar, and a more complex one that will implement a constantly-updating memory monitor widget for the devtools pane.

See you next time!

7 replies on “MemShrink progress, week 121–124”

Any updates on the state of GGC? AWFY shows performance is on par with the old mark&sweep, but there’s probably a lot more to it than getting performance parity before it goes gold.

Interesting work. However, there is one particular setting
that I was looking at recently:
But, looks like it works on only Windows and its memory saving
dubious. Something similar would be nice; my workflow (and may
be of others) goes something like this:

I usually keep >=2 windows open, one window is for what I am doing
currently, the other is more like for leisure reading or any other
future consideration. So, any tabs on main window that I deem fit for a
long read I move it to other window (with a custom js in pentadactyl).
This other window is usually kept hidden (through XMonad’s Boring
Windows), but it mimics minimize (but has more functionality than that).
So, it would be nice if firefox can detect the particular window is
minimized/hidden and reduce/release memory on that (may be use a timer
to prevent short term release/acquire issues). I understand that
GC runs periodically but it would be better if for the unexposed
window, more memory is released than through GC (so something
between GC and a complete reload of all resources of a tab when

Comments are closed.