Thou shalt not kill

The recent beta release of Chrome on Android marks a great time to look at what happens when web applications consume too much memory: something gets killed.

Previously I've blogged about the importance for web developers to mind their memory usage. On powerful desktop machines enjoyed by many developers, this can seem like an academic concern. But on mobile devices the limitation is all too real. Case in point: I compile with 24G of RAM and deploy to a Nexus S with 512M, and of that, only two-thirds (about 342M) is available for the system to use.

Here's what happens as a web app approaches that 342M limit.

1. Android apps are killed

The Android system has a wonderful design in which the user doesn't need to be concerned with which apps are open at any given time. The system has the prerogative to pause and resume background apps based on available resources. So, the first thing that happens as a web app's memory usage grows is that background applications are gracefully paused and killed. This is normal operation which happens constantly, however, it does mean that users wait longer when switching to paused apps as they have to be restarted and resumed.

2. Chrome tabs are killed

Once the system has given Chrome as much memory as it can afford, it sends notifications as usage approaches the limit. When Chrome notices it is using too much memory or receives one of these notifications, it has no choice but to kill background tabs. This is a little less transparent to users because when the user switches back to a killed tab, instead of the usual near instantaneous switch, the page must be reloaded from cache or network.

3. Caches are cleared

Up until this point, memory pressure has caused some performance problems for the user, but the foreground content hasn't suffered much. However, after all background tabs have been killed, Chrome's only remaining recourse is to clear memory caches and perform additional V8 garbage collections. This begins to cut into the application's interactive performance (scrolling, animations, JavaScript responsiveness, etc). It is often a short lived fix as these caches can quickly refill. A high performing web application should never allow memory usage get this high.

4. Suicide

Finally, when the system can allocate memory no more, it kills Chrome's renderer process in which the web page lives. Many mobile browsers would crash entirely, but due to Chrome's unique multiprocess architecture, the browser keeps running and displays the "Aw, Snap!" page. The user, left frustrated, is free to quickly move on to a better performing web page.

Living a long life

Possibly my favorite feature of Chrome on Android is that the entire developer tools suite works through remote debugging. This makes it easy to keep an eye on memory usage and diagnose memory leaks when they do occur.