Styles can pin an application or module in memory in 3.x versions of Flex but this has been fixed in Flex 4. There are other things that can cause memory leaks. Probably the easiest one to run into, especially with a shell application, are leaks caused by resource bundles.
If a sub-application or module uses components that use ResourceBundles that are not used by the main application, those resource bundles will get registered with the ResourceManager and pin the first instance of the application or module. You can use the -compiler.keep-generated-actionscript compiler option to see which resource bundles the module and main application are using. The resource bundles are listed in the "compiledResourceBundleNames" object of the info() function. You can force the main application to have those additional resource bundles by adding the resource bundle metadata to the main application. For example, to add the "controls" resource bundle, you would add to the main application MXML file: <mx:Metadata>[ResourceBundle("controls")]</mx:Metadata> If you are loading your resource bundles as modules, make sure the resource modules have completed loading before loading the module that is being pinned.
More information about leaks is available here: http://blogs.adobe.com/aharui/2009/08/what_we_know_about_unloading_m.html
"Styles can pin an application or module in memory in 3.x versions of Flex but this has been fixed in Flex 4"
As far as I can tell this has not been fixed in Flex 4. If I load and unload the most basic flex application possible it still leaves hanging references. The style mixins may have all been lumped into one mixin called '_Flex4Application_Styles' but this still creates a load of anonymous functions that get an unnecessary reference to the main application via the scope object (as explained in my post).
What is needed is a concerted effort to create an application.unload method that a Flex application can call when it is being unloaded (via the UNLOAD event perhaps) which should enable it to completely remove everything it to make every object it created eligible for garbage collection.
I really like the way that PureMVC segregates each separate core into its own object tree which can be dropped by one method Facade.removeCore(CORE_NAME). Maybe Flex could incorporate some sort of loaded application registry that can be used to removed the instances of manager classes specific to that application.
I am going to have to learn he source code :-)
Thanks Karl, but the problem is occurring with flash player 10 and using unloadAndStop.
>>As far as I can tell this has not been fixed in Flex 4. If I load and unload the most basic flex application possible it still leaves hanging references. The style mixins may have all been lumped into one mixin called '_Flex4Application_Styles' but this still creates a load of anonymous functions that get an unnecessary reference to the main application via the scope object (as explained in my post).
Yes there are anonymous functions but those references are contained within the application. When a sub-application is loaded all the anonymous references should point to objects within the sub-applciation and no references to the main application. I think you are missing the root cause of the leak. What resource bundles is your main application loading? What resource bundles is your sub-application loading?
Unfortunately our main shell app is currently not a flex application and so we can not add resource bundles to it using mxml etc...
Thanks for the suggestion about resource bundles: This is exactly my point about Flex memory management. It should not be necessary for a sub-application to rely on the behaviour of its container application in order to successfully release memory if given the chance. I will look into seeing what effect the resource bundle hack you mention has. However I will also see if it is possible for a sub-app to remove any resource bundles that it added, and nobody else was using - thats not a lot to ask is it?