Garbage

Collection

Alex Harui
Flex SDK
Adobe Systems, Inc.

1
2005 Adobe Systems Incorporated. All Rights Reserved.
 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.

2
2005 Adobe Systems Incorporated. All Rights Reserved.
 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 256
for bytes
Bitmaps, Files, etc are not pooled
512 bytes
256 bytes
256 bytes
256 bytes 512 bytes
256 bytes
256 bytes 512 bytes
256 bytes
256 bytes 512 bytes
256 bytes
…
…
512 bytes
256 bytes

3
2005 Adobe Systems Incorporated. All Rights Reserved.
 Flash Player Memory Management

 After a pool is used up, another large chunk is allocated from

the OS

512 bytes 512 bytes

512 bytes 512 bytes

Used 512 bytes 512 bytes

Unused 512 bytes 512 bytes

… …

512 bytes 512 bytes

4
2005 Adobe Systems Incorporated. All Rights Reserved.
 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.

512 bytes

512 bytes

Used 512 bytes

System.totalMemory = 100000 bytes
Unused 512 bytes

512 bytes

5
2005 Adobe Systems Incorporated. All Rights Reserved.
 Garbage Collection Does Not Run Constantly

 Assume that a Foo instance is 512 bytes.

 When allocated, another 512 bytes is used from the pool

foo = new Foo()

512 bytes

512 bytes

Used 512 bytes

System.totalMemory = 100512 bytes
Unused 512 bytes

512 bytes

6
2005 Adobe Systems Incorporated. All Rights Reserved.
 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 thefoo
trash can
= new doesn’t cause the can to be
Foo();
emptied” foo = null;

512 bytes

512 bytes

Used 512 bytes

System.totalMemory = 100512 bytes
Unused 512 bytes
Unused …
But not
GC’d 512 bytes

7
2005 Adobe Systems Incorporated. All Rights Reserved.
 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.

foo = new Foo();

foo = null;
foo = new Foo();

512 bytes

512 bytes

Used 512 bytes

System.totalMemory = 101024 bytes
Unused 512 bytes
Unused …
But not
GC’d 512 bytes

8
2005 Adobe Systems Incorporated. All Rights Reserved.
 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”

512 bytes
Almost out!, Run GC!
512 bytes

Used 512 bytes

Unused 512 bytes
Unused …
But not
GC’d 512 bytes

9
2005 Adobe Systems Incorporated. All Rights Reserved.
 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

10
2005 Adobe Systems Incorporated. All Rights Reserved.
 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

Before

512 bytes 512 bytes

512 bytes 512 bytes

Used 512 bytes 512 bytes

Unused 512 bytes 512 bytes
Unused … …
But not
GC’d 512 bytes 512 bytes

11
2005 Adobe Systems Incorporated. All Rights Reserved.
 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

After

512 bytes 512 bytes

512 bytes 512 bytes

Used 512 bytes 512 bytes

Unused 512 bytes 512 bytes
Unused … …
But not
GC’d 512 bytes 512 bytes

12
2005 Adobe Systems Incorporated. All Rights Reserved.
 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

Before
512 bytes 512 bytes

512 bytes 512 bytes

Used 512 bytes 512 bytes

Unused 512 bytes 512 bytes
Unused … …
But not
GC’d 512 bytes 512 bytes

13
2005 Adobe Systems Incorporated. All Rights Reserved.
 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

After
512 bytes 512 bytes

512 bytes 512 bytes

Used Eligible for

512 bytes 512 bytes
Release to OS
Unused 512 bytes 512 bytes
Unused … …
But not
GC’d 512 bytes 512 bytes

14
2005 Adobe Systems Incorporated. All Rights Reserved.
 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

15
2005 Adobe Systems Incorporated. All Rights Reserved.
 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.

16
2005 Adobe Systems Incorporated. All Rights Reserved.
 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.

17
2005 Adobe Systems Incorporated. All Rights Reserved.
 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++;
}

18
2005 Adobe Systems Incorporated. All Rights Reserved.
 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

19
2005 Adobe Systems Incorporated. All Rights Reserved.
 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

20
2005 Adobe Systems Incorporated. All Rights Reserved.
 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 />

Application Model
.application

Used Removed Popup

Unused VBox
Unused SystemManager Button
.root

But not
GC’d Stage Popup’s Button

21
2005 Adobe Systems Incorporated. All Rights Reserved.
 How Garbage Collection Works

 ApplicationDomain\Class Definitions
 Only static variables matter here.

public class Application {

public static var application:Object;
public var layoutType:String;

Application Model
.application

Used Removed Popup

Unused VBox
Unused mx.core.Application Button
But not
GC’d ApplicationDomain Popup’s Button

22
2005 Adobe Systems Incorporated. All Rights Reserved.
 How Garbage Collection Works

 Stack/Local Variables
PopUpManager.createPopUp(Dialog, this);

class PopUpManager {
public static function createPopUp(popUpClass:Class,…) {
var popUp = new popUpClass();

Dialog instance

Used Application instance popUp

Stack
Unused return address
Unused class Dialog this
But not
GC’d ApplicationDomain Dialog

23
2005 Adobe Systems Incorporated. All Rights Reserved.
 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);

.child
Application ChildComponent
.application

Used clickHandler clickListeners

Unused

Unused SystemManager
.root

But not
GC’d Stage

24
2005 Adobe Systems Incorporated. All Rights Reserved.
 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.

Application ChildComponent
.application

Used clickHandler clickListeners

Unused

Unused SystemManager
.root

But not
GC’d Stage

25
2005 Adobe Systems Incorporated. All Rights Reserved.
 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);
.popupChildren

PopUp

Used mouseUpHandler mouseUpListeners

Unused

Unused SystemManager
.root

But not
GC’d Stage

26
2005 Adobe Systems Incorporated. All Rights Reserved.
 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);
.popupChildren

PopUp
weak ref
Used mouseUpHandler mouseUpListeners
Unused

Unused SystemManager
.root

But not
GC’d Stage

27
2005 Adobe Systems Incorporated. All Rights Reserved.
 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.

28
2005 Adobe Systems Incorporated. All Rights Reserved.