Multi-Process RAM usage analysis on Android

Overview

Measuring RAM usage of a program should take in account not only memory heap, but also other memory, such as memory-mapped files or memory shared among the processes. There is a built-in Android debug tool procrank that displays one useful number for a process: "Uss" (Unique Set Size), rough amount of private memory (such as C++/V8/Dalvik heaps). Procrank also reports "Pss" (Proportional Set Size) that takes into account shared memory, but it is hard to make any conclusions based on this number. Chrome on Android is a multi-process application where browser process shares quite a lot of memory with the renderer processes (for example, read-only code).

The new set of tools in the chromium tree estimate the overall RAM usage of all processes (browser and renderers), as well as provides more fine-grained analysis for the running browser by type or memory mapping: private, shared read-only, shared read-write, etc. The HOWTO below briefly describes the steps to use the tools.

HOWTO

Step 1: build the memdump tool and deploy it on the device. The tools will be used to analyse memory mappings by looking at /proc/PID/pagemap, /proc/PID/maps for given process IDs, and also /proc/kpagecount.

adb remount

adb root

ninja -C out/Release memdump

adb push out/Release/memdump /data/local/tmp/

Step 2: Build the browser with the 'dlmalloc hack' (https://codereview.chromium.org/16514009). It is the allocator used in Android by default, except it is modified to perform all internal mappings using ashmem, which makes it easier to distinguish the heap memory from other mappings.

Given a checkout of chromium sources patch them with the hack, enable the build flag and build the browser:

git cl patch 16514009

GYP_DEFINES="android_use_dlmalloc=1 $GYP_DEFINES" gclient runhooks

# Build and deploy the browser apk as usual.

Steps 1 and 2 should be performed only once for a browser build.

Step 3: when the browser is started, use a little shell scripting to select the PIDs of all processes belonging to the browser (kill all other browser instances prior to this step), feed the memdump report to the analyser:

Only information about the pages resident in memory is printed. The "Process 1" is typically the browser process, others are renderer processes. For example, the value in bold shows that the browser process has allocated ~4.5 MB heap memory. The browser also has loaded almost 4MB of executable code during execution.