Looking at the world of media: from music to RIA.

Flash Internals: The ActionScript Virtual Machine (part three)

November 7th, 2007 Posted in ActionScript, Flash Player, Flex Development, max 2007

rune_flash.gifDuring the Adobe Max Conference I had the chance to sit in on “Flash Player Internals” session put on by Jim Corbett and Lee Thomason. Of all the sessions I attended at Max, this was by far the best and most informative for me. It was deep, fast and packed with little nuggets that I had heard in passing but never had fully explained. I am going to try and recap the session as best as I can and if you see any incorrect data please let me know!

Read Part One: Motto’s and Percentages. Read Part Two: Byte Code, Control Tags, Renderers… oh my!

Size Was King

Prior to Flash Player 9, one of the complaints from the Flash development community was the overall performance of the ActionScript language. Performance not only for animation but also for manipulation of large data sets. This issue was most apparent with Flex 1 and 1.5, which were developed on ActionScript 2. The challenge the Player team was facing with ActionScript was that the ActionScript Virtual Machine (AVM) had reached its performance limit.

Until Flash Player 9, size was always the most important factor for the development team. These were the days when modems still ruled the earth and ATM to the door was a fantasy dream utopia. To help facilitate adoption, the Flash Player had to be small and compact so that users wouldn’t flinch when it was time to install or upgrade. During my stint at the company, I remember hearing of huge battles for just adding 10k to the player size.

With Flash Player 9, the landscape had changed a lot. High Speed Internet was more of a reality and therefore size became less of the driving factor and more of an desirable goal. Performance was now the new king. At the time, Macromedia decided to start the process from moving the Flash Player from a plugin and into the realm of a platform. In our planning meetings we started to talk about the Flash Platform and what it could achieve. To make this a reality the player had to speed up and handle large data sets with grace and ease. With this goal; in stepped AVM+.

My Two AVMs

AVM+ was the new ActionScript Virtual Machine. It was designed from the ground up for screaming performance. The goal was an overall 10x performance increase, which was a really serious task for the Player team. Not only was AVM+ about speed but it also opened the doors for new features such as Just In Time (JIT) compiling, cleaning up the existing and often confusing API set, updating the ActionScript language to a first class citizen and finally exposing granular control over how content is accessed and managed.

One of the drawbacks with AVM+ is due to the radically different design, there was no way it could be backward compatible. This meant that if the Player only had AVM+ then the team would not be honoring their motto of “Don’t break the web.”. To resolve this, Flash Player 9 contains AVM-, or the original AVM from Flash Player 8 (plus some fixes). Having two AVMs does a few things that are not beneficial:

  1. Dramatically increases the file size of the Flash Player.
  2. Means that mixed code, such as SWFs that use AS3 and SWFs that use AS2 in the same application, are not able to directly talk to each other because the code is being run in different sandboxed AVMs
There are ways around the second item, but that is beyond the scope of this article. I may return to that subject in a later post. So let’s delve a little deeper into the world of AVM+.

What did we get?

AVM+ created support for ActionScript 3, the first implementation of the ECMA 4 Spec. ECMA is the standard that JavaScript is based on and ECMA 4 is the basis for the new JavaScript 2. Right now there is a tremendous amount of fighting going on about ECMA 4, JS 2 and Browser support. The Ajax community is all aflutter right now but one of the benefits is that when JS 2 is finally approved and in the wild, AS3 developers will have a good leg up on the language and its structure.

At the release of Flash Player 9, ECMA 4 was still very much in draft form and meant that the Player team had to solve language issues without the guidence or approval of the ECMA board. The issue with this is that when the language format is finalized new syntax will need to be added to ActionScript. My guess is that AS4 is not that far away… mmm “let is the new var”.

As an old school Flash developer, one of the coolest additions to the AVM+ is the ability to directly access and manipulate the display list. In previous versions of Flash if we wanted to dynamically add content we need to either load it into a MovieClip using the old attachMovie(), or create an empty MovieClip to shove things into. Now that the display list is accessible developers can spawn new instances of objects and attach them directly to the display list. The display list is a tree based on a parent/child hierarchy that enables branches to be moved around while maintaing their structures. This is great for when you want to build a specific layout, pop it off of one part of the display list and then add it somewhere else. Again, this is a deep topic that I may write a whole article about.

Debugging an application has become a lot easier with AVM+ because a robust Exception handling system has been put into place. This is great for building apps because its now possible to catch the exception or see the full call stack when the exception is thrown. One of the challenges with exception handling is that if you don’t catch the error and your user is running a debug player then they will see the exception. Right now uncaught exceptions are a big problem with Flex apps.

AVM+ now supports Loading classes, which may not seem a big deal but it offers a lot of flexibility. In the previous players, when you loaded content the item that was loading the content was removed and replaced by the loaded content. Now a loader class can be used to pull in assets and then either displayed via the loader or the content can be referenced and used elsewhere. This also means that if the data is graphical (PNG, GIF, JPEG, Video, etc.) and coming from a crossdomain supported location you can use the bitmap clone() feature and then clone Bitmaps from a single loaded item and use it in multiple places. This is pretty powerful stuff if used correctly.

Finally, for this post at least, we come to the open source aspect of the AVM. Adobe did a very interesting, and personally brilliant, move. They open sourced the AVM+ to the Mozilla foundation. As I mentioned earlier, the AVM+ is for ActionScript 3 which is an ECMA 4 language, just the same as JavaScript 2. Mozilla is now using AVM+ aka “Tamarin” as their core VM for JavaScript 2. As Tamarin is updated by Mozilla, Adobe pulls in the new build of the VM and uses it in the Flash Player. If Adobe makes a fix to the VM, they submit it back to Mozilla. This helps keep the languages (ActionScript and JavaScript) in sync with the ECMA standard and opens the door so developers can truly see what is going on under the VM hood.

Enough for now… next time I will dig into the world of JIT and Garbage Collection.

Update: Read Part Four: Just-in-time (JIT) compilation