Firefox OS/Performance/Memory/Transients

Background

This page will attempt to outline our current tools and methods for dealing with transient memory issues. These are defined as large increases in memory that may only last for a short period of time.

Historically our tools have focused on controlling the stable steady-state memory usage of the platform. Since desktop systems have greater memory resources with disk-based swap, transient memory spikes have only become an issue when very extreme. Many transient memory increases could simply be absorbed by the system. The user was only really impacted by steady-state memory.

On memory constrained devices, however, transient memory increases can become a bigger problem. For example, temporary memory usage could cause background apps to be OOM killed losing user state when at steady-state there is enough memory to support both apps.

Since the majority of our tools are focused on steady-state memory, transient memory spikes can be difficult to diagnose.

Instrumentation

Currently one of the best ways to investigate a transient memory problem is to use manual instrumentation of the affected gecko code. Yes, this can be quite tedious.

You can log the current memory usage by calling nsMemoryReporterManager::ResidentFast(). So your instrumentation will look something like this:

#include "nsMemoryReporterManager.h"

printf_stderr("Before the problem, RSS:%lld\n", nsMemoryReporterManager::ResidentFast())

/* problem code... */

printf_stderr("After the problem, RSS:%lld\n", nsMemoryReporterManager::ResidentFast())

Note, you will likely need to add /xpcom/base to LOCAL_INCLUDES in the associated moz.build file.

SPS Profiler and Cleopatra (FUTURE)

In the future we plan to add memory usage to the SPS profiler. See bug 988332. This will allow the investigation of transient memory usage as long as the target process is not OOM killed.