Garbage Collection Alex Harui Flex SDK Adobe Systems , Inc.
Garbage Collection: Atomic Model <ul><li>By “Atomic Model” I mean that this is a model of how garbage collection works in ...
Flash Player Memory Management <ul><li>Many Flash memory allocations are small and of common sizes </li></ul><ul><ul><li>L...
Flash Player Memory Management <ul><li>After a pool is used up, another large chunk is allocated from the OS </li></ul>Use...
Garbage Collection Does Not Run Constantly <ul><li>“ The garbage man only comes Friday morning” </li></ul><ul><li>When som...
Garbage Collection Does Not Run Constantly <ul><li>Assume that a Foo instance is 512 bytes. </li></ul><ul><li>When allocat...
Garbage Collection Does Not Run Constantly <ul><li>When “freed”, it is not marked unused, only GC will mark it unused. </l...
Garbage Collection Does Not Run Constantly <ul><li>When another Foo is allocated, it might take a new block from the pool ...
Garbage Collection Is Only Triggered By Allocations <ul><li>When a pool starts to fill up, there will be an attempt to col...
Garbage Collection Is Only Triggered By Allocations <ul><li>Since GC is only triggered by allocations, it means that you c...
Garbage Collection Does Not Run Completely <ul><li>The collector is not guaranteed to find all collectible blocks in one p...
Garbage Collection Does Not Run Completely <ul><li>The collector is not guaranteed to find all collectible blocks in one p...
Garbage Collection Does Not Always Free OS Memory <ul><li>The collector will attempt to move blocks from one large chunk t...
Garbage Collection Does Not Always Free OS Memory <ul><li>The collector will attempt to move blocks from one large chunk t...
Garbage Collection Is Not Predictable <ul><li>Since GC is not predictable, it means that cannot scientifically prove your ...
Detecting Memory Leaks <ul><li>Even small changes like the timing or location of mouse and keyboard events can affect tota...
Detecting Memory Leaks <ul><li>The next release of Flex should have memory leak diagnostics. </li></ul><ul><li>Until then:...
Detecting Memory Leaks <ul><li>private function doit():void { // call this on some interval </li></ul><ul><li>  var m:Mous...
Where To Find Memory Leaks <ul><li>For a repeatable sequence, properties referencing objects cannot be the cause of a leak...
How Garbage Collection Works <ul><li>Start at known tops of Object trees.  </li></ul><ul><li>Mark them and any objects the...
How Garbage Collection Works <ul><li>Stage </li></ul><ul><ul><li>Starting from Stage you can follow arrows to all blue box...
How Garbage Collection Works <ul><li>ApplicationDomainClass Definitions </li></ul><ul><ul><li>Only static variables matter...
How Garbage Collection Works <ul><li>Stack/Local Variables </li></ul><ul><li>PopUpManager.createPopUp(Dialog, this);  clas...
Removing EventListeners <ul><li>Listeners on child objects generally do not cause memory leaks. </li></ul><ul><li>Removing...
Removing EventListeners <ul><li>The child’s list of listeners gets a reference to the parent’s method </li></ul><ul><li>Af...
Removing EventListeners <ul><li>Listening to parent objects does cause memory leaks. </li></ul><ul><li>Removing the follow...
Removing EventListeners <ul><li>Use of weak reference listeners may be easier here. </li></ul><ul><ul><li>Otherwise you ha...
Summary <ul><li>Garbage Collection is triggered by allocation not deletion </li></ul><ul><li>Garbage Collection is not pre...
Upcoming SlideShare
Loading in …5
×

Gc Atomic

536 views
498 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
536
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Gc Atomic

  1. 1. Garbage Collection Alex Harui Flex SDK Adobe Systems , Inc.
  2. 2. Garbage Collection: Atomic Model <ul><li>By “Atomic Model” I mean that this is a model of how garbage collection works in the player, not a technical, exact description. That’s because: </li></ul><ul><ul><li>The actual behavior is complex and difficult to describe (just like we don’t really know what atoms are made of, we just have a model which works for us). </li></ul></ul><ul><ul><li>The player may change it at some point </li></ul></ul><ul><ul><li>This model has worked for me so far. </li></ul></ul>
  3. 3. Flash Player Memory Management <ul><li>Many Flash memory allocations are small and of common sizes </li></ul><ul><ul><li>Lots of small, frequent OS memory allocations can be slow </li></ul></ul><ul><li>Flash grabs large chunks of memory from the OS less often </li></ul><ul><li>A single large chunk is carved into a pool of small blocks of a fixed size </li></ul><ul><li>Big chunks for Bitmaps, Files, etc are not pooled </li></ul>256 bytes 256 bytes 256 bytes 256 bytes 256 bytes 256 bytes 256 bytes 256 bytes 256 bytes … 256 bytes 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  4. 4. Flash Player Memory Management <ul><li>After a pool is used up, another large chunk is allocated from the OS </li></ul>Used Unused 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes … 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  5. 5. Garbage Collection Does Not Run Constantly <ul><li>“ The garbage man only comes Friday morning” </li></ul><ul><li>When something is freed, its block will not always be re-used by the next allocation. </li></ul><ul><li>Assume that we have use 100000 bytes so far. </li></ul>Used Unused System.totalMemory = 100000 bytes 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  6. 6. Garbage Collection Does Not Run Constantly <ul><li>Assume that a Foo instance is 512 bytes. </li></ul><ul><li>When allocated, another 512 bytes is used from the pool </li></ul>Used Unused System.totalMemory = 100512 bytes foo = new Foo() 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  7. 7. Garbage Collection Does Not Run Constantly <ul><li>When “freed”, it is not marked unused, only GC will mark it unused. </li></ul><ul><li>Memory stays at 100512 bytes. </li></ul><ul><li>“ Putting it in the trash can doesn’t cause the can to be emptied” </li></ul>Used Unused System.totalMemory = 100512 bytes foo = new Foo(); foo = null; Unused But not GC’d 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  8. 8. Garbage Collection Does Not Run Constantly <ul><li>When another Foo is allocated, it might take a new block from the pool </li></ul><ul><li>Memory now is 101024 bytes. </li></ul>Used Unused System.totalMemory = 101024 bytes foo = new Foo(); foo = null; foo = new Foo(); Unused But not GC’d 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  9. 9. Garbage Collection Is Only Triggered By Allocations <ul><li>When a pool starts to fill up, there will be an attempt to collect before allocating from the OS. </li></ul><ul><li>“ When renting videos, they don’t go through the recently returned videos unless all the ones on the shelf are gone” </li></ul>Used Unused Unused But not GC’d Almost out!, Run GC! 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  10. 10. Garbage Collection Is Only Triggered By Allocations <ul><li>Since GC is only triggered by allocations, it means that you can watch an idle application forever and its memory usage will not change </li></ul>
  11. 11. Garbage Collection Does Not Run Completely <ul><li>The collector is not guaranteed to find all collectible blocks in one pass </li></ul><ul><ul><li>Don’t want to interfere with rendering and interaction </li></ul></ul><ul><li>Thus memory may never return to the initial point </li></ul>Used Unused Unused But not GC’d Before 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes … 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  12. 12. Garbage Collection Does Not Run Completely <ul><li>The collector is not guaranteed to find all collectible blocks in one pass </li></ul><ul><ul><li>Don’t want to interfere with rendering and interaction </li></ul></ul><ul><li>Thus memory may never return to the initial point </li></ul>Used Unused Unused But not GC’d After 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes … 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  13. 13. Garbage Collection Does Not Always Free OS Memory <ul><li>The collector will attempt to move blocks from one large chunk to another to free an entire chunk to the OS </li></ul><ul><ul><li>Won’t always be able to accomplish that in one pass </li></ul></ul><ul><li>Thus memory may never return to the initial point </li></ul>Used Unused Unused But not GC’d Before 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes … 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  14. 14. Garbage Collection Does Not Always Free OS Memory <ul><li>The collector will attempt to move blocks from one large chunk to another to free an entire chunk to the OS </li></ul><ul><ul><li>Won’t always be able to accomplish that in one pass </li></ul></ul><ul><li>Thus memory may never return to the initial point </li></ul>Used Unused Unused But not GC’d After Eligible for Release to OS 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes … 512 bytes 512 bytes 512 bytes 512 bytes 512 bytes …
  15. 15. Garbage Collection Is Not Predictable <ul><li>Since GC is not predictable, it means that cannot scientifically prove your application is not leaking memory </li></ul><ul><li>But you can get a sense empirically </li></ul>
  16. 16. Detecting Memory Leaks <ul><li>Even small changes like the timing or location of mouse and keyboard events can affect totalMemory </li></ul><ul><ul><li>Therefore, human interaction is not a good test. </li></ul></ul><ul><li>You are generally only concerned about repeatable sequences </li></ul><ul><ul><li>Popup dialogs coming and going </li></ul></ul><ul><ul><li>Modules loading and unloading </li></ul></ul><ul><li>If you repeat these sequences often over a long period of time, the amount of totalMemory will hit some maximum value and stay at or below it if you are not leaking memory. </li></ul>
  17. 17. Detecting Memory Leaks <ul><li>The next release of Flex should have memory leak diagnostics. </li></ul><ul><li>Until then: </li></ul><ul><ul><li>Automate the sequence in ActionScript so it runs w/o human intervention. </li></ul></ul><ul><ul><li>One technique is to use switch statements and faked mouse or keyboard events. </li></ul></ul>
  18. 18. Detecting Memory Leaks <ul><li>private function doit():void { // call this on some interval </li></ul><ul><li> var m:MouseEvent; </li></ul><ul><li> switch (currentStep) </li></ul><ul><li> { </li></ul><ul><li> case 0: </li></ul><ul><li>m = new MouseEvent(MouseEvent.CLICK); </li></ul><ul><li>b.dispatchEvent(m); // click app button to open dialog </li></ul><ul><li>break; </li></ul><ul><li> case 1: </li></ul><ul><li> case 2: </li></ul><ul><li>// wait for dialog to appear </li></ul><ul><li>break; </li></ul><ul><li> case 3: </li></ul><ul><li>m = new MouseEvent(MouseEvent.CLICK); </li></ul><ul><li>var o:Object = loginDialog; </li></ul><ul><li>o.b.dispatchEvent(m); // click dialog button to close dialog </li></ul><ul><li> case 4: </li></ul><ul><li> case 5: </li></ul><ul><li>break; </li></ul><ul><li> default: </li></ul><ul><li>currentStep = -1; // start over again </li></ul><ul><li>break; </li></ul><ul><li> } </li></ul><ul><li> currentStep++; </li></ul><ul><li>} </li></ul>
  19. 19. Where To Find Memory Leaks <ul><li>For a repeatable sequence, properties referencing objects cannot be the cause of a leak. </li></ul><ul><ul><li>They will get reassigned every time through the sequence so they will drop their reference to the previous object </li></ul></ul><ul><li>Arrays, Objects used as Maps, Dictionary are common causes </li></ul><ul><ul><li>Run the sequence once, see how many things are in the arrays and object maps </li></ul></ul><ul><ul><li>Run it several more times, are there more things? </li></ul></ul><ul><li>Failure to remove event listeners </li></ul>
  20. 20. How Garbage Collection Works <ul><li>Start at known tops of Object trees. </li></ul><ul><li>Mark them and any objects they reference </li></ul><ul><li>Go through the heap and free anything that isn’t marked. </li></ul><ul><li>Three tops of Object trees: </li></ul><ul><ul><li>Stage </li></ul></ul><ul><ul><li>ApplicationDomain/Class definitions </li></ul></ul><ul><ul><li>Stack/Local Variables </li></ul></ul>
  21. 21. How Garbage Collection Works <ul><li>Stage </li></ul><ul><ul><li>Starting from Stage you can follow arrows to all blue boxes </li></ul></ul><ul><li><mx:Application … > <mx:Model id=“Model” /> <mx:VBox> <mx:Button /> </li></ul>Used Unused Unused But not GC’d .root .application Application Stage SystemManager Model Removed Popup VBox Popup’s Button Button
  22. 22. How Garbage Collection Works <ul><li>ApplicationDomainClass Definitions </li></ul><ul><ul><li>Only static variables matter here. </li></ul></ul><ul><li>public class Application { public static var application:Object; public var layoutType:String; </li></ul>Used Unused Unused But not GC’d .application Application ApplicationDomain mx.core.Application Model Removed Popup VBox Popup’s Button Button
  23. 23. How Garbage Collection Works <ul><li>Stack/Local Variables </li></ul><ul><li>PopUpManager.createPopUp(Dialog, this); class PopUpManager { public static function createPopUp(popUpClass:Class,…) { var popUp = new popUpClass(); </li></ul>Used Unused Unused But not GC’d Stack Dialog instance Application instance ApplicationDomain class Dialog popUp return address Dialog this
  24. 24. Removing EventListeners <ul><li>Listeners on child objects generally do not cause memory leaks. </li></ul><ul><li>Removing the following addEventListener isn’t required (but good practice) </li></ul><ul><li>override protected function createChildren():void { child = new ChildComponent(); addChild(child); child.addEventListener(“click”, clickHandler); </li></ul>Used Unused Unused But not GC’d .root .application .child Application clickHandler Stage SystemManager ChildComponent clickListeners
  25. 25. Removing EventListeners <ul><li>The child’s list of listeners gets a reference to the parent’s method </li></ul><ul><li>After removing the child, there is no path from Stage to the child. </li></ul>Used Unused Unused But not GC’d .root .application Application clickHandler Stage SystemManager ChildComponent clickListeners
  26. 26. Removing EventListeners <ul><li>Listening to parent objects does cause memory leaks. </li></ul><ul><li>Removing the following addEventListener is required </li></ul><ul><ul><li>There are two paths to the PopUp </li></ul></ul><ul><li>override protected function mouseDownHandler(…):void { systemManager.addEventListener(“mouseUp”, mouseUpHandler); </li></ul>Used Unused Unused But not GC’d .root .popupChildren PopUp mouseUpHandler Stage SystemManager mouseUpListeners
  27. 27. Removing EventListeners <ul><li>Use of weak reference listeners may be easier here. </li></ul><ul><ul><li>Otherwise you have to check to see if you OR your parents have been removed from the display list. </li></ul></ul><ul><li>Removing the following addEventListener is not required </li></ul><ul><li>override protected function mouseDownHandler(…):void { systemManager.addEventListener(“mouseUp”, mouseUpHandler, false, 0, true); </li></ul>Used Unused Unused But not GC’d .root .popupChildren weak ref PopUp mouseUpHandler Stage SystemManager mouseUpListeners
  28. 28. Summary <ul><li>Garbage Collection is triggered by allocation not deletion </li></ul><ul><li>Garbage Collection is not predictable </li></ul><ul><li>Next Release should have memory diagnostic tools </li></ul><ul><li>Until then, automate repeatable sequences </li></ul><ul><ul><li>totalMemory should reach a maximum value over time </li></ul></ul><ul><li>Event Listeners cause references in the opposite direction than you may think. </li></ul><ul><ul><li>The dispatcher references the listener. </li></ul></ul>

×