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