Upload
taras-leskiv
View
71.417
Download
2
Embed Size (px)
DESCRIPTION
Presentation for GDG Workshop, 3 April 2013. A few words about memory management in Android Applications.
Citation preview
Memory Management Fundamentals for Android apps
Agenda
1. Memory usage model – Constraints – Zygote, Dalvik and GC
2. Tools for memory diagnos@cs – adb shell procrank – lava.lang.Run@me – Log messages – Alloca@on tracker – Eclipse MAT
T-‐Mobile G1 (2008)
192 MB Nexus 4 (2012)
2 GB
We’ve grown bigger and stronger
12x RAM
So why should we care about the memory?
• Heap size is limited and device dependent • Screen size has grown drama@cally -‐ Bitmaps • System libraries occupy significant amount of storage
• The more memory we use, the more work GC has, the more work GC has the bigger pause @me will be.
• BaWery life
Dalvik VM
Dalvik VM .dex format
Respect the balance! Cache as
much useful data as you
can
Use as liWle memory as you can
Why?
I will kill your process as soon as I don’t have
memory for other apps and your app uses lots of
memory
Why?
I can do mul@tasking and I want smooth UX when switching between apps
Mark-‐and-‐sweep GC
Larger heap = larger pause @me = poor performance
Mark-‐and-‐sweep GC
Phase 1 Before GC
GC Roots
Mark-‐and-‐sweep GC
GC Roots Phase 2
Marking complete
-‐ Marked object
Mark: star@ng from roots, mark all reachable objects by using a depth-‐first-‐search pointer traversal
-‐ Garbage
Mark-‐and-‐sweep GC
GC Roots Phase 3
Sweep complete
-‐ Marked object
Sweep: scan the heap from the beginning to the end and reclaim the unmarked objects (and unmark the marked objects).
GC Improvements
Before Aber Garbage collector
• Advantage of mul@core support • Mostly concurrent • Par@al collec@ons • Smaller pause @mes
• Stop-‐the-‐world • Full heap collec@on • Large pause @mes
GC Improvements Before Aber
• Stop-‐the-‐world – all app threads are stopped
• Full heap collec@on • Large pause @mes
oben > 100ms
• Ini4al mark -‐ stop-‐the-‐world • Mark -‐ concurrent • Remark – stop-‐the-‐world • Sweep -‐ concurrent
Healthy memory usage paWern
Time
Allocated memory
Maximum heap* size
GC Run
Memory Usage
Garbage
* Maximum amount of memory our app is allowed to use
Edge case
Time
Allocated memory
Maximum heap* size
Memory Usage
Garbage
GC Run
OutOfMemoryError
* Maximum amount of memory our app is allowed to use
Are we leaking memory?
Time
Allocated memory
Maximum heap* size
Memory Usage
Garbage
GC Run
Amount of memory leaking
Memory leak * Maximum amount of memory our app is allowed to use
Maximum heap size So how much memory can we actually use?
1. ActivityManager.getMemoryClass() – device dependent – always constant 2. Runtime.getRuntime().maxMemory() – can be changed on rooted devices, is slightly larger
T-‐Mobile G1 – 16 MB Nexus One – 32 MB Nexus 7 – 64 MB
Memory intensive apps
What if it is not enough? Image editor? Video editor? 3D game? <application
android:largeHeap=“true” </application>
Use only if you are sure you need this extra memory. ActivityManager.getLargeMemoryClass()
We are armed
Target – Honeycomb Gallery App
YOUR_SDK_LOCATION\samples\android-‐XX\HoneycombGallery
Tools to diagnose memory usage
1. adb shell procrank 2. java.lang.Run@me 3. Log messages 4. Alloca@on tracker and heap updates 5. Heap dumps and Eclipse Memory Analyzer
Tool (MAT)
procrank u@lity
Applica4on: answers a ques@on how much memory are we actually using.
procrank
Lists of all processes on the device and memory they are using (sorted desc.). adb shell procrank (requires root access) Uss – Unique set size – rough memory amount the system would reclaim if it kills the process.
Java.lang.Run@me methods
• freeMemory() • totalMemory()
Applica4on: • observing general applica@on memory usage
paWern at run@me • provides basic understanding of memory usage
behavior
Observing memory state changes in LogCat
new Thread(new Runnable() { @Override public void run() { while (true) { try { Thread.sleep(5000); } catch (InterruptedException e) { // do nothing } reportMemoryUsage(); } } }, “MemoryUsageReporter").start();
Gives a general idea about memory
changes at run@me RAM USAGE free: 1.96MB, total: 14.68MB, max : 64.00 RAM USAGE free: 1.95MB, total: 14.68MB, max : 64.00 RAM USAGE free: 1.71MB, total: 14.68MB, max : 64.00 RAM USAGE free: 1.71MB, total: 14.68MB, max : 64.00 RAM USAGE free: 4.62MB, total: 17.35MB, max : 64.00 RAM USAGE free: 4.62MB, total: 17.35MB, max : 64.00 RAM USAGE free: 1.95MB, total: 14.68MB, max : 64.00 RAM USAGE free: 1.95MB, total: 14.68MB, max : 64.00 RAM USAGE free: 1.95MB, total: 14.68MB, max : 64.00
Interpre@ng LogCat messages
02-‐25 11:12:59.321: D/dalvikvm(7757): GC_CONCURRENT freed 1536K, 17% free 10790K/12856K, paused 3ms+3ms, total 21ms
General informa@on
• Timestamp • Logging level • Log tag • Process id
02-‐25 11:12:59.321: D/dalvikvm(7757): GC_CONCURRENT freed 1536K, 17% free 10790K/12856K, paused 3ms+3ms, total 21ms
Reason for GC Run
Possible reasons: • GC_CONCURRENT • GC_FOR_MALLOC/GC_FOR_ALLOC • GC_EXTERNAL_ALLOC • GC_HPROF_DUMP_HEAP • GC_EXPLICIT
02-‐25 11:12:59.321: D/dalvikvm(7757): GC_CONCURRENT freed 1536K, 17% free 10790K/12856K, paused 3ms+3ms, total 21ms
GC_CONCURRENT
Amount of memory reclaimed 02-‐25 11:12:59.321: D/dalvikvm(7757): GC_CONCURRENT freed 1536K, 17% free 10790K/12856K, paused 3ms+3ms, total 21ms
freed 1536K,
Heap sta@s@cs 02-‐25 11:12:59.321: D/dalvikvm(7757): GC_CONCURRENT freed 1536K, 17% free 10790K/12856K, paused 3ms+3ms, total 21ms 17% free 10790K/12856K
• Percentage of free heap memory aber the GC run • Size of objects alive/Total heap size
Pause @me 02-‐25 11:12:59.321: D/dalvikvm(7757): GC_CONCURRENT freed 1536K, 17% free 10790K/12856K, paused 3ms+3ms, total 21ms paused 3ms+3ms, total 21ms
Bitmaps – what has changed? Before Honeycomb
Dalvik Heap
Na@ve Memory
Pixel Data
Bitmaps – what has changed? Aber Honeycomb
Dalvik Heap
Na@ve Memory
Pixel Data
Bitmaps – what has changed?
Before Aber
Bitmap pixel data storage
Na@ve memory • Freed via –recycle or finalizer • Hard to debug • Full GC (stop-‐the-‐world)
Dalvik Heap • Freed synchronously by GC • Easy to debug • Concurrent and par@al GCs
Profit?
• When pixel data is stored in Dalvik heap it is much easier to debug memory usage as everything is in one place • Pixel data in pre-‐Honeycomb was freed by recycle() or finalizer, now freed syncronously by GC • GCs of pixel data are now concurrent and par4al – pause 4mes are smaller
Alloca@on tracker (Monitor)
• Info about object alloca@ons in a specific @me period
Eclipse Memory Analyzer Tool
Heap Dump
• Is a snapshot of all “living” objects at a given point in @me
• Contains info about which objects are GC roots (will not be reclaimed if there are no refs to them).
• Does not contain info about na@ve objects (pre-‐Honeycomb Bitmaps e.g.)
Object size
• Shallow size of an object – amount of memory allocated to store the object itself, not taking into account the referenced object. (Sum of size of the object header and the fields)
String 1 String 2
Shallow size
Shallow object size -‐ example public final class String { // 8 Bytes header
private char value[]; // 4 Bytes private int offset; // 4 Bytes private int count; // 4 Bytes private int hash = 0; // 4 Bytes
…} “Shallow size” of a String == 24 Bytes (32 bit Sun JDK)
Retained set
• Retained set of object X – The set of objects that would be
garbage collected, if object X is deleted
– The retained size of an object X is equal to the shallow size of the “Retained sets” of X
Object X
Retained set of X
Genera@ng a heap dump file
• Dump HPROF file (DDMS or programma@cally)* • Convert (Not needed in Eclipse DDMS) hprof-‐conv dump.hprof dump-‐conv.hprof • Open the file with Eclipse MAT
*android.os.dumpHprofData(String filename)
Ini@al pie chart view
• Shows the biggest objects be their retained size
Histogram view Number of instances of each class and their shallow size
Histogram view Oben not very useful. Why?
Class name Number of objects Shallow size in bytes
char[] 9 597 555 496
Java.lang.String 10 799 259 176
How many char[] are caused by String instances?
Dominator tree example
An object A dominates on an object B if all the paths to object B pass through object A.
1. Note that A, B and C are dominated by a "virtual" root object. 2. Note that the dominator rela@onship is transi4ve; C dominates E which dominates G therefore C also dominates G.
Dominator tree view List of objects by their retained heap
Memory Leak Demo
Ques@ons?
Taras Leskiv [email protected] linkedin.com/in/tarasleskiv