Understanding Memory Leaks in ActionScript (Adobe Flex)

 

Thanks go to Danny of TheGoldHold.com for a bunch of this information!

In ActionScript, there is no method to manually completely remove an object from memory. That task is soley the responsibility of the Flash Player's garbage collector (GC). The GC operates autonomously, and beyond the "Force GC" button in the Flex Builder memory profiler, there is no method to cause the GC to run. Therefore, memory leaks in Flex can be hard to understand and debug.

I have created a MemoryLeakTest project in Flex Builder that show examples that are and are not memory leaks. The project contains three applications, two with memory leaks and one with out. Each sample application adds and removes a single sub-component 100 times per second. This forces the garbage collector to run, and easily shows when a memory leak occurs. The source code contains comments that explain the memory leaks, and how to avoid them, but I'll go over them briefly here as well.

Flash Player Memory Allocation

Memory allocation speed inside the Flash player runtime is limited by the browser. Therefore, instead of making a large number of small requests for memory, flash player makes a small number of requests for large chunks of memory. Memory deallocation is also a slow process, so flash player is reluctant to give up memory; though it will do so as necessary.

Garbage Collector Specifics

Objects are garbage collected only when they have no other objects that contain strong references. Flash Player's runtime keeps a reference table that is updated each time a reference is made between two objects. The Garbage Collector simply uses that table to determine which objects are completely de-referenced.

The Garbage Collector (GC) runs directly before additional memory is requested. This way flash player can gain the memory resources used by garbage objects, and can re-evalute the need to allocate additional memory; possibly saving time. It is important to note that GC does not run immediately when an object is completely de-referenced. So, even though you've completely de-referenced an object it can and probably will stay in memory.

Identifying Memory Leaks

Flex Builder 3 Pro includes a "Profiler" tool that can be used to identify memory leaks. In that tool is a "Force Garbage Collection" button. When your application is being profiled, simply click that button and monitor the "Live Objects" list. If you believe you have complete removed and dereferenced an object, its number of "instances" should have be reduced.

Use the "Cumulative Instances" to determine how many instances of that object were ever created, and the "Instances" column to determine how many of those instances still exist. If after creating and removing an object, then running "Force GC", those numbers are still the same, you probably have a memory leak.

The "Memory Usage" chart is another way to determine whether a memory leak exists; but only for small applications. The red line represents the maximum memory use, and the blue line represents the current memory use. If the blue line and red line never separate, you have a memory leak.

Bad Memory Usage

Good Memory Usage

Memory Leaks by Reference

Because the garbage collector determines which objects to free by their references, it is important for the developer to keep up with what references they have created. A very simple example of this is creating a reference from a parent object to a child object.

In the following example, a childObject is created, and then a second reference is made to that childObject. Because that second reference still exists at the end of this code, that childObject will never be freed; unless the parent object is garbage collected.

    private var childObject:Object = {test: 'test'};

    private var secondReference:Object = childObject;

    childObject = null;

Memory Leaks by Event Listeners

Incorrect use of EventListners are the number one cause of memory leaks in ActionScript. EventListeners push references of the callback object into an array on the target object. That reference keeps the Garbage Collector from destroying the call back object. There are a few exceptions to this rule. These do not block garbage collection:

1. Weak References
2. Self References
3. References to Child Objects

Weak references are created by setting fifth argument of "addEventListner" to "true". By default, eventListeners use strong references. Note that using a weak referenced eventlistner, and then having no other reference to an object means that object will be garbage collected, so be careful!

An example of a weak reference event listener.

   someObject.addEventListener(MouseClick.CLICK, handlerFunction, false, 0, true);

Self references are simply references by an object to itself. A common example is adding an eventListener to a component, and handling it inside of that component.

An example of a self reference event listener.

    this.addEventListener(MouseClick.CLICK, handlerFunction);

Child references are references to a child object. When a parent object is garbage collected, that destroys the references to the child object. So usually, this means the child object will also be garbage collected (unless outside references to that child object exist). Therefore, it is safe to add eventListeners to an immediate child object and not worry about memory leaks. You should note that the child object will not be freed until the parent object is freed!

An example of a childObject event listener:

     private var childObject:UIComponent = new UIComponent;

     addChild(childObject);

     childObject.addEventListener(MouseEvent.CLICK, clickHandler);