Bug 822325 will add the simplest possible LRU implementation, but we'd like to do better than that. We can fix bug 822325 independently of this since it's higher priority. If you run b2g for a while, you'll notice that "skinny" processes tend to accumulate in the background and prevent more-recently-used less-skinny processes from staying alive. While the SMS app might use a bit more memory than the calculator, if I used the SMS app in the last 5 minutes, but last used the calculator last week, I'd rather have the calculator gunned down first under memory pressure. We'll want to avoid considering "services" in LRU computation, since the user doesn't launch them explicitly. E.g. cost control / calendar. We need to understand the android prior art for implementing this. I don't know offhand how LRU works with lmk, beyond the LAST_PROCESS hack.
Once we have this infrastructure in place, the next step would "frecency"-derived process priorities. I may have used the calculator 5 minutes ago and the SMS app 10 minutes ago, AND calculator may be skinnier, but if I launch SMS 100 times a day and calculator once a week, we should prefer keeping SMS alive.
Adding to perf team triage queue for perceived perf bucket.
You need to log in before you can comment on or make changes to this bug.