while poking around about:memory I had an idea which might be worth
implementing to reduce the footprint of our content processes:
periodically shrinking them if they're idle. The idea is to detect when
a content process isn't doing anything useful (e.g. the user hasn't
interacted with the tabs it owns for a while) and send it an artificial
"memory-pressure" event with a "low-memory" reason .
I tested this on my regular browsing session on Windows and the event
tends to shrink a content process footprint by ~10% (saving roughly
20-30 MiB). The procedure doesn't seem to take more than 10ms to execute
so it should be imperceptible to the user. The reduction in memory
consumption is largely down to the JS GC heaps being shrunk and the
sqlite caches being purged. I assumed that the image cache would also
shrink but it doesn't seem to be the case, we're probably using it more
efficiently than we did in the past.
The two downsides of this are that once the user switches back to one of
the tabs owned by the process its response should be slower (though how
much?). On machines with little memory it might also cause swapping
which would obviously be bad.
I'm throwing the idea around because I'd love to investigate this
further but I don't have time right now.
And BTW if somebody has some spare cycles it might also be worth trying
to get actual low memory notifications working properly on Windows.
While we have code for that, it has significant flaws which makes it
almost useless. I'd be glad to walk you through what needs to be done,
some info is already available in bug 1308118 .
 Note that this is different compared to what we do when we minimize
memory usage from about:memory, the reason used for that event is
"heap-minimize" instead of "low-memory" and it's rather brutal (e.g. it
runs the GC/CC three times in a row).
 Implement a floating threshold to send low memory notifications on