My blog post describing how we cut #Firefox out-of-memory crashes by more than 70% with one weird trick is out: https://hacks.mozilla.org/2022/11/improving-firefox-stability-with-this-one-weird-trick/
The title is not click-bait, I swear, it *is* one weird trick.
@gabrielesvelto How does this relate to unload-tabs-on-memory-pressure mechanism? (I would naively expect that to always run out of unloadable tabs first; is that the case?)
@gabrielesvelto Tangentially: I would really appreciate it if Firefox didn't look at how low the _system_ is on memory, but (on OSes where this is a thing) look at the cgroup/other resource allocation process group it's in. (e.g. I run Firefox in a cgroup with a memory limit, so that I can leave some memory aside for everything else in a guaranteed fashion.)
@robryk on Linux we don't look at system memory usage mostly because it's impossible to do in a reliable way. We're entirely in the hands of the OOM killer.
To be precise we tried detecting global low-memory situations... and failed. Going forward this detection will only be based on Firefox own processes' dying and thus necessarily local to whatever cgroup it's been assigned to.
@robryk that's a very good question! It provided small benefits compared to this, so we're repurposing it: we want to unload tabs when we're low on physical memory to preserve swapping. This way we'll have two distinct mechanisms, one to prevent crashes and one to improve responsiveness by avoiding swapping.