Signin
Flex Diaper

I ran a smack into possibly serious problem with AIR on Sunday. The problem was that a closed Window (mx.core.Window) was not GCing because there were about 100 references (according to Flex Builder 3 even after forced GC) to the window instance after it closed, none explicitly by my code btw. There were all references from within (children of or owned by the window) or bindings from parts of the window (all too easy to do with MXML magic like an online jailbait dating service) to my model layer.

Looking at Window.close method, all it does is tell its native window to close and remove itself from the system manager it belongs to. Hmm. Supposedly, child controls are smart enough to recognize when it's taken off the 'stage' and removing references but, apparently, it's not happening. And looking at binding implementation and generated glue code, I don't see how anyone can avoid memory leak problems with even moderately complex application lifecycle scenarios.

But then, by the time you find yourself in serious need of a diaper, you would have invested enough time to write a small mound of code and paid $700 (for FB3) to see a nice table of leaks. Gosh, all this is making me happy enough to wet my pants. What a Sunday.

Comments
You need web2.0 branded diapers. http://www.whynot.net/ideas/41
I thought AIR was supposed to make distributed, cross-platform "rich" application development a pleasant and enrichening experience compared to the utter and complete mess that HTML+CSS+Ajax is supposed to be? I guess there's (still) no silver bullet, then.
Well. I think Adobe will eventually start moving their focus away from Flex to Flash/AIR/WebKit combo.

Once cast, application framework is a notoriously difficult house to clean and keep from bloating. All frameworks starts off looking sweet but as more engineers are thrown into it, code gets sloppier, workarounds turn into vine-like conventions and, in the end, not a fun place to be working at the basement of. Situation gets worse over time when there is are build-time tools in the mix.

I don't know if anyone still remember the MacApp framework but MacApp is the hell Flex is heading toward IMHO.

Frankly, what Flex guys have done with binding support is delightful stuff that can handle even twisted initialization situations with ease. But whole Flex team has put too much focus on just one part of application life cycle and not enough on the rest while they added and expanded features like binding. Flex's smart collections feature is great too except I think cost and side-effects will make it a feature one should avoid.
ea, men, MacApp is the hell Flex, you'r right
mike chambers   at 2007/10/28 12:45:31 PM
Don,

fyi,

This is a known issue with the beta and something we are looking at internally.

mike chambers

mesh@adobe.com
Jurriaan Ruitenberg   at 2008/06/03 09:42:53 AM
This seems to be a problem still? even though its far out of beta now. Even in sample applications, every window opened is added to the system memory the application consumes and is never released again, even if i clear any ref. to the window, or listeners on it's children. For a window with an htmlloader in it, this means an extra 4Mb for me, everytime the user clicks on it. This is a serious problem for apps that need to run a long time.
Your Identicon:
Name: * required
Email:
Website URL:
 
Comment:
HTML not supported