Bug 1472062 comment 28 has important data showing that we have a number of Firefox instances that spend minutes or hours in low memory situations before crashing with OOM. This matches my personal experience (or rather, the personal experience of friends & family with less beefy machines than mine.)

Not to put too fine a point on it: this sucks. The user experience here is often that their computer becomes basically unusable. They have to wait until the memory hog crashes.

With bug 1468207 (a great thing by itself) fixed, it sounds like that wait may have gotten substantially longer in many cases, since we try heroically to keep the process alive when near OOM.

I propose adding some sort of quality of service measurement. If it dips too low, crash out intentionally.

A strawman QoS metric: if it takes more than 5 minutes to respond to user input, crash. (Note that we would need to be able to ignore situations where the machine was suspended with an input even in the queue; it would suck to open up your laptop and have all Firefox content processes simultaneously commit seppuku.)

It would be nicer if we could try unloading some tabs first, and that's good too, but this bug is really intended for the ultimate fallback when things have gotten so bad that crashing is preferable to any solution the involves continuing to run.

Note that I also fixed bug 675539 in the meantime, so if we start running out of memory tabs will be automatically unloaded to free some. This should avoid the terrible scenarios where we hover for a long time below the threshold.

Moving this to Core :: Memory Allocator as it seems that would be where the initial work to allow Firefox to control this would need to go.

Seems more like something for nsMemoryImpl.