Android Memory Usage

From eLinux.org
Revision as of 11:23, 16 July 2010 by Tim Bird (talk | contribs) (Dalvik Heap: add borstein quote about heap sharing)
Jump to: navigation, search

The memory of an Android system is managed by several different allocators, in several different pools.

System Memory

You can examine the system's view of the memory on the machine, by examining /proc/meminfo.

If you use 'ddms', you can see a summary of the memory used on the machine, by the system and by the different executing processes. Click on the SysInfo tab, and select "Memory Usage" in the box on the upper left of the pane.

Here's a screenshot:

Android memory usage on an OMAP EVM platform, running eclair, as shown by ddms

Note that you can get the numbers for each process by hovering your mouse over a particular pie slice. Numbers are shown in K and percentages.

Process Memory

You can see an individual process' memory usage by examining /proc/<pid>/status

Details about memory usage are in

  • /proc/<pid>/statm
  • /proc/<pid>/maps
  • /proc/<pid>/smaps

The 'top' command will show VSS and RSS.

Also, see ddms info above.

smem tool

You can see very detailed per-process or systemwide memory information with smem.

See Using smem on Android

Dalvik Heap

The Dalvik heap is preloaded with classes and data by zygote (loading over 1900 classes as of Android version 2.2). When zygote forks to start an android application, the new application gets a copy-on-write mapping of this heap. As Dan Borstein says below, this helps with memory reduction as well as application startup time.

Dalvik, like virtual machines for many other languages, does garbage collection on the heap. There appears to be a separate thread (called the HeapWorker) in each VM process that performs the garbage collection actions. (See toolbox ps -t) [need more notes on the garbage collection]

Dan Borstein said this about heap sharing[1]:

It's used in Android to amortize the RAM footprint of the large amount of effectively-read-only data (technically writable but rarely actually written) associated with common library classes across all active VM processes. 1000+ classes get preloaded by the system at boot time, and each class consumes at least a little heap for itself, including often pointing off to a constellation of other objects. The heap created by the preloading process gets shared copy-on-write with each spawned VM process (but again doesn't in practice get written much). This saves hundreds of kB of dirty unpageable RAM per process and also helps speed up process startup.

[INFO NEEDED: how to show dalvik heap info?]

References

  1. comment by Dan Borstein, Jan 2009 to blog article Dalvik vs. Mono