Dear John, How do I unload Flex modules?

Question asked by Joshua.

Unloading modules is a difficult thing to do, and is near to impossible in Flash Player 9. Originally this article clued my into what was going on: http://www.gskinner.com/blog/archives/2008/04/failure_to_unlo.html. Essentially to get modules to truly unload you have to get rid of all the references to them, and be using the "Copied Domain Method." The copied domain method is described here in detail, along with its effects on memory: http://jvalentino.blogspot.com/2009/06/flex-memory-issue-4-modules-and.html.

Assuming you are using the Copied Domain Method, you then have to deal with the following areas of leakage as mentioned in the originating article:

• State and AddChild – This can cause a leak, sort of, see http://www.nbilyk.com/flex-states-memory-leak
• Bindings – Bindings can sometime leak, see http://bugs.adobe.com/jira/browse/SDK-14875
• Forcing Garbage Collection – You have to force GC most of the time to get modules to move along, see http://jvalentino.blogspot.com/2009/05/flex-memory-issue-3-garbage-collection.html
• Listeners – You have to remove listeners when you are done with them.
• Using the Current Domain Method – prevents modules from truly unloading, see http://jvalentino.blogspot.com/2009/06/flex-memory-issue-4-modules-and.html
• Effects – Effects in a module will cause it to leak, see http://jvalentino.blogspot.com/2009/05/flex-memory-issue-2-component-effects.html

I essentially handled these area of leakages by iterating recursively through every component within a module class after unloading, removing state, removing bindings, removing common listeners, reseting the EffectManager, and then forcing garbage collection using what is called the local connection hack.

The problem with this though is that there will always be memory accumulation even if references are removed. This is due to a largely unknown and undocumented issue known as "Rendering memory fragmentation." I have discussed this issue with several engineers at Adobe through a client which I cannot name, and they are at least passively aware of it but it is an issue with the Flash Player itself. The article at http://www.craftymind.com/2008/04/09/kick-starting-the-garbage-collector-in-actionscript-3-with-air/ hinted at what was going on, which lead me into a full investigation to verify the problem.

Basically the Flash Player operates on what is called an Elastic Racetrack (http://www.onflex.org/ted/2005/07/flash-player-mental-model-elastic.php), which ends up with the memory used of AS3 object allocation and the memory used for rendering getting on the same page in memory. When the garbage collection runs the allocation space is not cleaned because the blocks contain active rendering memory and vice versa. This makes it to where the garbage collector fails to clean things, which causes leaks. Since the issue is rendering related it is more prevalent in application that are graphically intense and run at large resolutions, like kiosks. It is for these reasons that I recommend that most applications pool modules, so that the rendering and object instantiations through allocations are minimal.

In the end it will depend on how many "modules" are in your application, how big they are, and if they are really modules. It is quite common for application to incorrectly use modules because they followed the examples released by Adobe, which cause the module definitions themselves to be compiled into both the module SWF and the main application SWF. Flex operates on a compile by reference basis, so if your application has direct reference to a module class that module class gets compiled into both the module SWF and the main application SWF.