(In reply to Kev Needham [:kev] from comment #7)
Thanks for the additional info. The utility and value is understood, and to confirm:
- this change is not extension-specific; while there is a tab unload function, the specific request here is to enable auto-unloading and letting it ride to release
- has been in beta for some time and is considered release ready
Could you confirm?
Yes, I've compared the same beta releases for 66.0 and 67.0 to compare the OOM crash rate and on 67 it's roughty 10% lower. When we enabled it on nightly the effect was also visible as a marked reduction in OOM crash pings:
On beta I hoped to be able to calculate the number of OOM crashes per kusage hours which is a better proxy of the actual crash rate. I had an old query that did that but the dataset has been since removed and I wasn't able to update it. I can also confirm that this has been in beta since mid-March and it doesn't seem to have caused any regressions or other user-facing problems.
My main concern is around a lack of clarity with what kind of feedback we've been getting from users directly, whether there are any common cases we should be aware of that may impact users negatively, and how many users this is likely to potentially affect (e.g. what percentage of profiles do we see that we think will hit the low memory condition). I'd also like to understand if we know the potential impact; you mention that we reduced OOM crashes by 10%, and I was hoping you could point me at what that means in terms of absolute sessions or installs.
From a user standpoint this isn't very visible unless their Firefox was crashing all the time because of lack of memory in which case it should be crashing less often. The only thing they'll notice is that going back to a tab might cause it to be reloaded if it was unloaded to "save" Firefox from crashing. Since this is integrated with session restore and the mechanism has already been tested in extensions I don't expect any "surprising" behavior.
The worst case I can think of is unloading a tab that has some important data that session restore can't handle (e.g. dynamic forms, maybe session data). That data will be lost, but it would be lost anyway if we crashed so it shouldn't be worse. On this topic I'd like to stress that this mechanism kicks in only when we're left with a really small amount of free memory; it will not be a common occurrence. OOM crashes represent only ~10% of all crashes.