This makes me believe that the memory problem is not so much with the language, but with the programmers. I guess AIR developers nowadays are just more aware of the memory management issues you described.

Still boggles me that a simple AIR app like the FriendFeed Notifier can use up to 230 MB of RAM for what little it does.

This is where I am hoping that the upcoming Silverlight 3 out-of-browser experience can deliver desktop-based apps with a much tighter memory footprint than comparable Adobe AIR apps.

There IS however an easy way around this, you can use weak references on your listeners. I’ve now gone to always using weak referenced event listeners unless I have a reason not to. The useWeakReference argument is the 5th argument on the the addEventListener method it’s a bool and defaults to false.

What I find confusing in Adobe’s decision is the choice to make this the 3rd OPTIONAL argument when creating an event listener AND on top of that to default it to false, it would have made far more sense I think to default it to true. As it is, to use it you have to provide the other arguments just to fill the positions.

Do check cyn.in Desktop (Adobe AIR) app. cyn.in is an open source group collaboration software for enterprise.

cyn.in desktop provides activity stream of main cyn.in system to users and enables them to view, comment or discuss the content or context right there without taking them to web browser. It also serves as enterprise micro-blogging or presence system. A must review for you.
cyn.in Desktop is available here:

http://cyn.in/get-cynin/download-cynin-desktop-client

Perhaps Adobe decided to make a trade-off – allowing advanced developers to better optimize and take control over their code, in exchange for lesser developers producing crappier, memory-bloated applications. It was a decision Adobe made,and we all live with it.

You would think though, more and more AS3 developers should be aware of the new garbage collection behavior and optimize their apps accordingly. However, you’ll be surprised how many search referrals I still get each day on this article for searches on terms like “Adobe”, “AIR”, “memory”, “bloat”, “problem”.

After proper reconstructing to my ActionScript code by keeping an eye on Flash Player memory usage and object listeners week references I finally have a more reliable version of my application that consumes ~50 mb at max.

I agree with Tom, it is definitely a matter of coding and development, the runtime has nothing to do with it. may be it is much harder for developer than the old days, but I think this is a very useful feature, it make a developer taking full control over his code and performance, nothing fancy behind the scenes done by the runtime and the developer doesn’t know or understand.

And to the credit of Twhirl’s developers, shortly after I posted this blog entry, they released version 0.8.2 of Twhirl, which uses significantly less memory than before.

I still maintain that memeory usage is rather high for more or less a single-purpose application, but now my Twhirl memory footprint stabilizes at around 150 MB or so, even left running for a week.

I ain’t no ActionScript guru, but I would be curious why Adobe chose to change the GC behavior for ActionScript 3 as you described, making life harder for developers.

Coming from a Java/J2EE background, I have to say that I feel one of the reasons why Java really took off was because the language made it easy for developers to just focus on implementing the functionality, and not need to worry about memory management and all of the other heavy lifting and plumbing that is necessary behind the scenes. So even lesser developers have a decent chance in being productive and generating acceptable quality code.