Weak Activation Object

It appears either A) The Activation Object in ActionScript 3 is dumber than it’s predecessor, or B) the new Garbage Collector implemented in Flash Player 8 is more aggressive, or C) I’ve never had this use case. Naturally, I’d like to believe that it’s A, but I have a sinking suspicion it’s a combination of B & C.

I read this post by Matthew Tretter describing how reference-less objects such as Tweens and URLLoader’s won’t work consistently when there are no references to them.  This is because they have no references, and when the Garbage Collector comes around, he sees this, and destroys the mofo’s. This is in direct violation of how a lot of us have coded in the past since Flash Player 6 implemented dynamic MovieClip methods like onPress, and onRelease. Using anonymous functions with anonymous variables was just the lay of the land:

my_mc.onPress = function()
{
    var my_xml = new XML();
    my_xml.ignoreWhite = true;
    my_xml.onLoad = function(success)
    {
       trace("success!, parse this.");
    };
}

In the above example, my_xml is a local variable. In ActionScript 1 and 2, no one has a reference to it. Thus, at the end of onPress, it’ll die… or, so it would appear. However, Garbage Collection first has to activate to kill it; theoretically GC only runs every 60 seconds, or when memory increases 20% in 1 frame. The GC will kill it if no one has a reference to it. However, the Activation Object does. For both XML and LoadVars, I and thousands of other Flash Developers have used this technique with a variety of ways to handle scope as well.

You’ll notice, however, that this code isn’t very memory intensive, thus I guess staying under the radar of GC. It merely makes an XML object, gets the XML, parses it, and that’s it, done. When AS2 came out, I started keeping class references to these variables for ease of writing code, and confirmation I was in fact deleting them later when I was done. Therefore, my guess as to why I’ve never seen the problem Matthew talks about is that I’ve never created extremely memory intensive applications pre-AS2 that used of asynchronous operations created via local variables. Seems plausible.

So, I told him he was wrong and moved on. He tracked my ass down to Flashmedia to politely plead his case. Turns out I was wrong… and extremely lazy. I didn’t do diligence and actually test his code. Upon testing his code (1000 creations vs. my 1), and his problem was easily reproducible. He’s created some classes that help encapsulate this so you don’t have to worry about it.

For example, Robert Penner’s original Tween classes actually kept a global reference of all crated Tween instances in a static array, so there was always at least 1 reference. I had just always assumed that the Activation Object knew of asynchronous objects, and thus released the lock (killed the reference) on it after their asynchronous operation had completed such as onData, or onLoad for LoadVars/XML.

I often create local variables for loading such as Loader or URLoader for generic loading code, so I was horrified that this scenario was this predictable. I’m not sure how to best resolve this yet since I’ve been doing this for years and it’ll really be a pain in the ass to start either keeping class references for these things or using a wrapper class. I only load 1 or 3 of these at any one time, not 1000 so maybe I’ve just gotten lucky all of these years. Maybe a beer will help… yeah… a beer…

Anyway, I apologize Matthew for saying you were wrong without due diligence on my part; I was wrong and could of at least had the common courtesy to actually test your provided code before making judgments based on long held assumptions.