• Save
link to ppt
Upcoming SlideShare
Loading in...5
×
 

link to ppt

on

  • 440 views

 

Statistics

Views

Total Views
440
Views on SlideShare
440
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

link to ppt link to ppt Presentation Transcript

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