Memory management and garbage collection

[Ondina]

Memory management and garbage collection - the big deficiency of the FlashPlayer

It seems that many of us are struggling with this issue, so I thought it would be good to share my findings after  my  (desperate) research into this subject.

Here some links to articles, that I found to be somehow useful, even if none of them is giving the ultimate answer to (Flex and AIR) developers' prayers:

1
http://gskinner.com/talks/resource-management/
http://www.gskinner.com/blog/archives/2006/06/as3_resource_ma.html
http://www.adobe.com/devnet/flashplayer/articles/garbage_collection.html

2
http://office.realeyesmedia.com/blogs/jun/?p=61
http://office.realeyesmedia.com/blogs/jun/samples/360Flex/360_Slides/index.htm

3
http://blogs.adobe.com/aharui/2007/03/garbage_collection_and_memory.html
http://blogs.adobe.com/aharui/2008/09/using_the_flex_builder_3x_prof.html

4
http://blog.flexmonkeypatches.com/2007/03/28/flash-player-memory-management-and-garbage-collection-redux-2/

5
http://www.insideria.com/2008/03/flex-performance-memory-manage.html


6
http://www.craftymind.com/2008/04/09/kick-starting-the-garbage-collector-in-actionscript-3-with-air/

7
http://elromdesign.com/blog/2008/03/15/boost-flex-performance-with-object-pooling-manager-api/

8
http://flex.sourceforge.net/manual/The-Default-Memory-Management.html#The-Default-Memory-Management

9
http://roshantitus.blogspot.com/2008/11/flex-memory-management.html

10
http://www.nutrixinteractive.com/blog/?p=132

11  Flash Player Mental Model - The Elastic Racetrack <-interesting
http://www.onflex.org/ted/2005/07/flash-player-mental-model-elastic.php

Does anyone know of any other articles on that subject?

Ondina

[Jason MacDonald]

The thing I still struggle with, and can't seem to find really solid info on, is the proper use of the Profiler in Flash/Flex Builder. Sure, I know the basics, but I constantly feel like I'm missing something important about how to properly read all that info. I wish I could find that one article (or series) that gives me an "aha!" moment with regards to the Profiler.

[puremvc]

@Jason, re the profiler, it's not terribly complicated really.

A graph shows memory usage over time, so each time you instantiate a new module or component, you'll see that jump up a bit. The goal is that when you dispose of a module or component, that line should jump back down accordingly.

The next thing to be concerned with is instances and cumulative instances columns of the grid. Lets say you load a module and MyModuleFacade is one of the objects created. When you get rid of the module, on the MyModuleFacade row, you'll see in the instances column how many there are right now, which should be zero since you did a removeCore. Cumulative instances will show 1. Create it again and then dispose of it and again, instances should be 0, but now cumulative will be 2, the total number that have been created irrespective of whether they're still alive.

Sorting on memory and instances gives you an idea of what's chewing up memory and object space right now.

-=Cliff>

[Jason MacDonald]

Yeah, I'm more referring to wierd obscure things like, for instance, 150 instances of Class, 780 instance of Function, and 1052 instances of Object that all refer to ApplicationDomain. All the path info says is:

:

[newclass]()
    global$init:global$init()
    flash.system:ApplicationDomain:flash.system:ApplicationDomain()

I have no clue how to use this little bit of useless info to determine why I have so many ApplicationDomain instances... should I even worry?

There's very little info out there about how we should treat these items (Object, Class, String, Function). Should I worry about increasing instances of these base types? It doesn't seem to push my memory up much but the instances DO keep increasing as I click around in my app.

PS: This is more to do with a Replace Current scenario then a Create and Destroy one. See http://blogs.adobe.com/aharui/profiler/ProfilerScenarios.swf

[Ondina]

The FlexProfiler gives me an  “ouch” moment , when I discover that there are Classes inside my code I didn't know about.

I have run a test once on 2 applications, one is a Flex app, the other an AIR app, with nothing else inside but the <mx:Application> tag
The Profiler info for both of them:
An empty Flex Application
Class: ModuleManagerImpl Package:ModuleManger.as Cumulative Instances:5(6.49%)
Instances:1(1.25%)  Cumulative Memory:180(4.01%) Memory:52(2.19%)

An empty Air Application
Class: ModuleManagerImpl Package:ModuleManger.as Cumulative Instances:5(4.9%)
Instances:1(12.5%)  Cumulative Memory::188(3.71%) Memory:60(2.44%)

Scary! Because there aren't any modules in those applications. There are no components, not a single line of as3 code, no external libraries and no modules!

Then in a complex AIR application with lots of components(no modules though) I get 1 Instance of the ModuleManagerImpl , about 7456 Cumulative Instances of the Class, Memory: 60, and  Cumulative Memory : 231772!

Where does the ModuleManagerImpl Class come from?
From Application.as, which imports  mx.managers.SystemManager;, which imports mx.core.IFlexModuleFactory; ?¿

Is that happening only to me?
Is there something in the FlexBuilder Properties that I should change?
Actually I just ran a short test in Gumbo too, with original settings, and I'm getting the same info as in FlexBuilder3.

[puremvc]

Welcome to the wacky world of Flex internals. It is a little scary, particularly when you start trying to dispose of Modules and realizing there are all these classes that probably have references you didn't make that are causing your module to hang around. I'm seeing this with modules instantiated via MXML and later trying to replace them with new ones.

-=Cliff>

[Ondina]

I was looking at my other bookmarked links ( referring  to modular applications) and I found this :
http://ultra-web.co.uk/?tag=as3-memory

The author says:
“After reading through most of the module classes in the SDK I found some issues that would not allow a module to fully unload, one being several event listeners in the FlexModuleFactory that never get removed and the other issue being that if you use a component in your module that shares a style with the main application you are royally screwed! “

That was kind of an “aha” moment for me (  paraphrasing Jason again ).
I don't know if the workaround presented in the article is practicable, but at least the info can save you some time while looking for what you did wrong in your code. It's not you, it's Adobe.

[puremvc]

An excellent resource!

Thanks, Ondina.