We currently hardcode our bfcache to 1 page (for each tab I think?) [1]. We could lower it on low memory devices. The dynamic calculation in Firefox guesses about 4MB per entry [2], so it could be a 4MB per tab win. Alternatively, we could fix the dynamic calculation to be a bit more conservative and turn it on everywhere. [1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/app/mobile.js#109 [2] http://mxr.mozilla.org/mozilla-central/source/docshell/shistory/src/nsSHistory.cpp#272

I'd like to better understand the difference between "max_entries" and "max_total_viewers". Reducing "max_total_viewers" means setting it to zero, which means turning it off. How does that affect bfcache? Would reducing "max_entries" be a simpler change that does not completely turn off bfcache? How much memory is reduced by changing "max_entries" ?

Can we get someone to make some settings changes, then run about:memory (or dump it using the intent) to compare the differences? If we can see some noticeable wins, these would be easy preferences to adjust dynamically in response to memory limits. Wesj - Maybe ckitching would be able to do this?

Argh. Forgot this. If a volunteer wants to look at about:memory a bit, I'd be happy to help you.

Updating the links a bit: The auto-calculate code where the 4MB estimate is shown: http://hg.mozilla.org/mozilla-central/diff/9b2a99adc05e/docshell/shistory/src/nsSHistory.cpp We already have code to evict all content viewers on a memory-pressure: http://hg.mozilla.org/mozilla-central/diff/051b3d8ed545/docshell/shistory/src/nsSHistory.cpp Let's use this bug to just set the pref to 0 for low memory devices, so they have less chances of OOMs.

Simple fix adds a session-default pref on low memory trigger.