Bardbarian on Steam - coming s…
A Meandering Path to an Evolvi…Quick as a FlashThings Every ActionScript Deve…Making Money with Adobe AIRUsing Flash for 3D Game MMO UIUtilizing Flash for Game UI De…Why I (Still) Love FlashMy Favourite Things
Posted on June 19, 2006 by Grant Skinner
I’ve been playing around with AS3 for a while now, and am really excited by its capabilities. The raw execution speed by itself will create so many possibilities. Toss in E4X, Sockets, ByteArrays, new display list model, RegEx, a formalized event and error model, and a few dozen other features for flavour, and you have a pretty heady brew.
With great power comes great responsibility, and this will be very true for AS3. A side effect of all this new control is that the Garbage Collector is no longer able to make as many assumptions about what it should tidy up automatically for you. This means that Flash developers moving to AS3 will need to develop a very strong understanding of how the GC operates, and how to work with it effectively. Building even seemingly simple games or applications without this knowledge can easily result in SWFs that can leak like a sieve, hogging all of a system’s resources (CPU/RAM), and causing the user’s system to hang (potentially even forcing them to hard reboot their computer).
Over the next few weeks (or even months), I will be writing a series of articles on this topic. I will look at the underlying mechanics of the Garbage Collector, discuss the issues you are likely to face, examine the new tools available to you for handling resource management in AS3, and offer solutions/code to help you circumvent many of the common problems you will face.
I’ll begin at the beginning, and look at the Garbage Collector in the Flash 9 player.
About the Garbage Collector
If I were to delete “b” as well in the example above, it would leave my object with no active references and free it for garbage collection. The AS3 GC uses two methods for locating objects with no active references: Reference counting and mark sweeping.
Reference counting is simple, doesn’t carry a huge CPU overhead, and works well in most situations. Unfortunately it really falls down when it comes to circular referencing. This is when objects cross-reference each other (directly, or indirectly via other objects). Even if the application is no longer actively using the objects, their reference counts remain above zero, so they are never removed. Here’s a quick demo:
In the above example, both of my active application references have been deleted. I no longer have any way of accessing the two objects from my application, but their reference counts are both 1 because they reference each other. This can also be much more complex (a references c which references b which references a, etc), and is hard to deal with in code. Flash player 6 and 7 suffered from problems related to circular referencing in XML objects – each XML node referenced both its children and its parent, so they were never deallocated. Fortunately, player 8 added a new GC technique called mark sweeping.
Mark sweeping is very accurate, but because it has to traverse your entire object structure, it is also costly in terms of CPU usage. Flash player 9 reduces this cost by carrying out iterative mark sweeping (ie. it occurs over a number of frames, instead of all at once), and by only having it run occasionally.
Deferred GC and Indeterminacy
It’s very important to remember that you have no control over when your objects will be deallocated, so you must make them as inert as possible when you are finished with them. Strategies to manage this will be the focus for a future article.
Follow @gskinner on Twitter for more news and views on interactive media.