Memory	  Management	  Fundamentals	             for	  Android	  apps	  
Agenda	  1.  Memory	  usage	  model	     –  Constraints	  	     –  Zygote,	  Dalvik	  and	  GC	  2.  Tools	  for	  memory	...
We’ve	  grown	  bigger	  and	  stronger	                                    12x	  RAM	  	   T-­‐Mobile	  G1	  (2008)	     ...
So	  why	  should	  we	  care	  about	  the	                       memory?	  •  Heap	  size	  is	  limited	  and	  device	...
Dalvik	  VM	  
Dalvik	  VM	  .dex	  format	  
Respect	  the	  balance!	                                                                 Cache	  as	                     ...
Mark-­‐and-­‐sweep	  GC	  Larger	  heap	  =	  larger	  pause	  @me	  =	  poor	  performance	  
Mark-­‐and-­‐sweep	  GC	                                      GC	                                     Roots	  Phase	  1	  ...
Mark-­‐and-­‐sweep	  GC	                                                                                              GC	 ...
Mark-­‐and-­‐sweep	  GC	                                                                                            GC	  P...
GC	  Improvements	            Before	                                       Aber	                                   Garbag...
GC	  Improvements	                                                           Aber	              Before	  •  Stop-­‐the-­‐w...
Healthy	  memory	  usage	  paWern	                                                                                        ...
Edge	  case	                                                                                                             M...
Are	  we	  leaking	  memory?	                                                                                             ...
Maximum	  heap	  size	                  So	  how	  much	  memory	  can	  we	  actually	  use?	                            ...
Memory	  intensive	  apps	  What	  if	  it	  is	  not	  enough?	  Image	  editor?	  Video	  editor?	  3D	  game?	  	  <app...
We	  are	  armed	  
Target	  –	  Honeycomb	  Gallery	  App	     YOUR_SDK_LOCATIONsamplesandroid-­‐XXHoneycombGallery	  
Tools	  to	  diagnose	  memory	  usage	  1.  adb	  shell	  procrank	  2.  java.lang.Run@me	  3.  Log	  messages	  4.  Allo...
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.).	  	  a...
Java.lang.Run@me	  methods	  •  freeMemory()	  •  totalMemory()	   Applica4on:	  	   •  observing	  general	  applica@on	 ...
 	  	  	  	  	  	  Observing	  memory	  state	  changes	                                        in	  LogCat	  new Thread(n...
 Gives	  a	  general	  idea	  about	  memory	                changes	  at	  run@me	   RAM	  USAGE	  free:	  1.96MB,	  tota...
Interpre@ng	  LogCat	  messages	  02-­‐25	  11:12:59.321:	  D/dalvikvm(7757):	  GC_CONCURRENT	  freed	  1536K,	  17%	  fre...
General	  informa@on	   02-­‐25	  11:12:59.321:	  D/dalvikvm(7757):	   GC_CONCURRENT	  freed	  1536K,	  17%	  free	  10790...
Reason	  for	  GC	  Run	  02-­‐25	  11:12:59.321:	  D/dalvikvm(7757):	  GC_CONCURRENT	  freed	                            ...
 	  	  	  	  	  	  	  	  	  	  	  	  Amount	  of	  memory	  reclaimed	     02-­‐25	  11:12:59.321:	  D/dalvikvm(7757):	  G...
Bitmaps	  –	  what	  has	  changed?	                            Before	  Honeycomb	                                       ...
Bitmaps	  –	  what	  has	  changed?	              Aber	  Honeycomb	                    Pixel	  Data	                      ...
Bitmaps	  –	  what	  has	  changed?	                     Before	                                                    Aber	 ...
Profit?	  •  When	  pixel	  data	  is	  stored	  in	  Dalvik	  heap	     it	  is	  much	  easier	  to	  debug	  memory	  us...
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	  ...
Object	  size	  •  Shallow	  size	  of	  an	  object	  –	  amount	  of	  memory	     allocated	  to	  store	  the	  object...
Shallow	  object	  size	  -­‐	  example	  public	  final	  class	  String	  {	  //	  8	  Bytes	  header	         	  privat...
Retained	  set	  •  Retained	  set	  of	  object	  X	                                                         Object	     ...
Genera@ng	  a	  heap	  dump	  file	    •  Dump	  HPROF	  file	  (DDMS	  or	  programma@cally)*	    •  Convert	  	  (Not	  ne...
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	                         N...
Dominator	  tree	  example	  An	  object	  A	  dominates	  on	  an	  object	  B	  if	  all	  the	  paths	  to	  object	  B...
Dominator	  tree	  view	  List	  of	  objects	  by	  their	  retained	  heap	  
Memory	  Leak	  Demo	  
Ques@ons?	                  Taras	  Leskiv	        	        
Upcoming SlideShare
Loading in...5

Android memory fundamentals


Published on

Presentation for GDG Workshop, 3 April 2013. A few words about memory management in Android Applications.

Published in: Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Android memory fundamentals

  1. 1. Memory  Management  Fundamentals   for  Android  apps  
  2. 2. 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    
  3. 3. We’ve  grown  bigger  and  stronger   12x  RAM     T-­‐Mobile  G1  (2008)   Nexus  4   (2012)  192  MB   2  GB  
  4. 4. 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  
  5. 5. Dalvik  VM  
  6. 6. Dalvik  VM  .dex  format  
  7. 7. Respect  the  balance!   Cache  as   much  useful   Use  as  liWle   data  as  you   memory  as   can   you  can   Why?   Why?   I  can  do  I  will  kill  your  process  as   mul@tasking  and  I   soon  as  I  don’t  have   want  smooth  UX   memory  for  other  apps  and  your  app  uses  lots  of   when  switching   memory   between  apps  
  8. 8. Mark-­‐and-­‐sweep  GC  Larger  heap  =  larger  pause  @me  =  poor  performance  
  9. 9. Mark-­‐and-­‐sweep  GC   GC   Roots  Phase  1  Before  GC  
  10. 10. Mark-­‐and-­‐sweep  GC   GC   Phase  2   Roots   Marking  complete     -­‐  Marked  object   -­‐  Garbage  Mark:  star@ng  from  roots,  mark  all  reachable  objects  by  using  a  depth-­‐first-­‐search  pointer  traversal  
  11. 11. Mark-­‐and-­‐sweep  GC   GC  Phase  3   Roots  Sweep  complete     -­‐  Marked  object  Sweep:  scan  the  heap  from  the  beginning  to  the  end  and  reclaim  the  unmarked  objects  (and  unmark  the  marked  objects).  
  12. 12. GC  Improvements   Before   Aber   Garbage  collector  •  Stop-­‐the-­‐world   •  Advantage  of  mul@core  support  •  Full  heap  collec@on   •  Mostly  concurrent  •  Large  pause  @mes   •  Par@al  collec@ons   •  Smaller  pause  @mes  
  13. 13. GC  Improvements   Aber   Before  •  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  
  14. 14. Healthy  memory  usage  paWern   Maximum   heap*  size  Allocated     GC  Run  memory   Garbage   Memory   Usage   Time  *  Maximum  amount  of  memory  our  app  is  allowed  to  use  
  15. 15. Edge  case   Maximum   heap*  size   OutOfMemoryError  Allocated     GC  Run  memory   Garbage   Memory   Usage   Time  *  Maximum  amount  of  memory  our  app  is  allowed  to  use  
  16. 16. Are  we  leaking  memory?   Maximum  heap*  size   Allocated     GC  Run   memory   Garbage   Amount  of  memory   leaking   Memory   Usage   Memory  leak   Time  *  Maximum  amount  of  memory  our  app  is  allowed  to  use  
  17. 17. 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    
  18. 18. 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()    
  19. 19. We  are  armed  
  20. 20. Target  –  Honeycomb  Gallery  App   YOUR_SDK_LOCATIONsamplesandroid-­‐XXHoneycombGallery  
  21. 21. 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)  
  22. 22. procrank  u@lity  Applica4on:  answers  a  ques@on  how  much  memory  are  we  actually  using.  
  23. 23. 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.  
  24. 24. 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  
  25. 25.              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();  
  26. 26.  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    
  27. 27. 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  
  28. 28. General  informa@on   02-­‐25  11:12:59.321:  D/dalvikvm(7757):   GC_CONCURRENT  freed  1536K,  17%  free  10790K/ 12856K,  paused  3ms+3ms,  total  21ms  •  Timestamp  •  Logging  level  •  Log  tag  •  Process  id  
  29. 29. Reason  for  GC  Run  02-­‐25  11:12:59.321:  D/dalvikvm(7757):  GC_CONCURRENT  freed   GC_CONCURRENT  1536K,  17%  free  10790K/12856K,  paused  3ms+3ms,  total  21ms  Possible  reasons:  •  GC_CONCURRENT  •  GC_FOR_MALLOC/GC_FOR_ALLOC  •  GC_EXTERNAL_ALLOC  •  GC_HPROF_DUMP_HEAP  •  GC_EXPLICIT  
  30. 30.                          Amount  of  memory  reclaimed   02-­‐25  11:12:59.321:  D/dalvikvm(7757):  GC_CONCURRENT  freed   freed   1536K,  17%  free  10790K/12856K,  paused  3ms+3ms,  total  21ms   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  
  31. 31. Bitmaps  –  what  has  changed?   Before  Honeycomb   Dalvik  Heap   Na@ve   Memory   Pixel  Data  
  32. 32. Bitmaps  –  what  has  changed?   Aber  Honeycomb   Pixel  Data   Dalvik  Heap   Na@ve   Memory  
  33. 33. Bitmaps  –  what  has  changed?   Before   Aber   Bitmap  pixel  data  storage  Na@ve  memory  •  Freed  via  –recycle  or  finalizer   Dalvik  Heap   •  Freed  synchronously  by  GC  •  Hard  to  debug  •  Full  GC  (stop-­‐the-­‐world)   •  Easy  to  debug   •  Concurrent  and  par@al  GCs  
  34. 34. 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  
  35. 35. Alloca@on  tracker  (Monitor)  •  Info  about    object  alloca@ons  in  a  specific  @me  period    
  36. 36. Eclipse  Memory  Analyzer  Tool  
  37. 37. 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.)  
  38. 38. 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)   Shallow  size   String  1   String  2  
  39. 39. 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)    
  40. 40. Retained  set  •  Retained  set  of  object  X   Object   X   –  The  set  of  objects  that  would  be   garbage  collected,  if  object  X  is   deleted   –  The  retained  size  of  an  object  X   Retained  set  of  X   is  equal  to  the  shallow  size  of   the  “Retained  sets”  of  X  
  41. 41. 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)  
  42. 42. Ini@al  pie  chart  view  •  Shows  the  biggest  objects  be  their  retained   size  
  43. 43. Histogram  view  Number  of  instances  of  each  class  and  their  shallow  size  
  44. 44. 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?  
  45. 45. 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.  
  46. 46. Dominator  tree  view  List  of  objects  by  their  retained  heap  
  47. 47. Memory  Leak  Demo  
  48. 48. Ques@ons?   Taras  Leskiv  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.