|
|
| Line 4: |
Line 4: |
|
| |
|
| ---- | | ---- |
|
| |
| = Understanding B2G OOMs =
| |
|
| |
| B2G runs on severely memory-constrained devices, and it's easy for apps to exhaust the memory available on the system. When a process exhausts the memory available on the system, the kernel must kill some process in order to free up memory. When the kernel choses to kill the foreground process, this manifests as an apparent crash of the app you're using.
| |
|
| |
| This document describes how B2G's multiprocess architecture affects what the phone does when we run out of memory, and how to understand and debug OOM crashes.
| |
|
| |
| == Process priorities ==
| |
|
| |
| B2G uses multiple processes when it runs on a phone. It has one "main process" and potentially many "child processes". Every app runs in its own child process, with one exception: The browser app runs in the main process, while the tabs inside the browser app each run in their own child process.
| |
|
| |
| The process we kill when we run out of memory isn't necessarily the one that "caused" the out-of-memory condition. B2G assigns priorities to each process based on how important it thinks the process is, and when the system runs out of memory, it kills process strictly in order of priority.
| |
|
| |
| A process's priority is known as its "oom_adj". Smaller oom_adj values correspond to higher priority processes.
| |
|
| |
| Killing the main process kills all child processes and effectively reboots the phone, so we never want to kill the main process. Therefore, the main process runs with oom_adj 0.
| |
|
| |
| Most child processes run with oom_adj 2 while they're in the foreground. Child processes in the background run with oom_adj between 3 and 6 (inclusive). Exactly what oom_adj a child process while in the background gets depends on a number of factors, such as whether it's playing sound, whether it's the homescreen app, and so on.
| |