| || |
== Dalvik Heap ==
== Dalvik Heap ==
[how to show dalvik heap info?]
how to show dalvik heap info?]
| || |
Revision as of 11:18, 16 July 2010
The memory of an Android system is managed by several different allocators, in several different pools.
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:
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.
You can see an individual process' memory usage by examining /proc/<pid>/status
Details about memory usage are in
The 'top' command will show VSS and RSS.
Also, see ddms info above.
You can see very detailed per-process or systemwide memory information with smem.
See Using smem on Android
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:
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?]
- ↑ [comment Jan 2009 to Blog article Dalvik vs. Mono