On memory-constrained devices, if the b2g process memory usage rises about 75-80MB USS or so, the device becomes basically unusable. Have to reboot. We of course want to fix the bugs causing these problems, but we always want to guard against unexpected problems in the field. We can do this by adding a memory watchdog that restarts userspace when a threshold is exceeded. It's not useful to gate on the b2g process usage directly, since the critical usage varies depending on memory available to the device. We also have friendly background processes like persona that keep themselves foreground. Other kinds of bugs can keep processes stuck fg. Instead, we should turn this around and measure *reclaimable* memory. I think we can make a guess at this with MemTotal - \sum_{gecko processes p with OOM class >= fg} USS_p Off-hand, I'm guessing the critical threshold is around 30-40MB, but we should measure. With this infrastructure in place, we can also consider aborting when we drop below a "good UX" threshold too, not just "usable at all". That gets a bit more dangerous though. Let's hope we never need to use this!

We can do these estimates by piggy-backing on memory pressure events, so there's no need to poll. A difficulty I just realized is that we might have an extremely fat foreground process launched by the user, say a big fat game. That game could take memory consumption above the critical threshold, but that's no cause for concern because the user can background the process, and it'll be gunned down the next time the user tries to launch an app. So we would need to distinguish between user-launched and system-launched processes, I think.

Gaia could add an attribute on mozbrowser frames to say whether or not they were launched because of user interaction.