Comments on: Flash Internals: Just-in-time (JIT) compilation (part four)

By: Lorenzo

Lorenzo — Wed, 04 Nov 2009 15:25:34 +0000

Dear James,

thank you for your reply!

Frames can be a tricky topic! They are difficult to understand. I will do research on them!! Thank you again. Best Regards.

By: James Polanco

James Polanco — Tue, 03 Nov 2009 22:54:53 +0000

Lorenzo, From what I understand the concept of a SWF frame and a Player Frame are essentially the same. When using Flash Authoring to create animations you are telling the Player to render the changes defined for each frame. When the player runs the SWF, it will attempt to play each SWF frame as defined, i.e. render the content changes.

The core difference between the frame in the SWF vs. the player frame is how the frame is constructed. I recommend checking out Sean Christmann’s article on how frames are synthesized in the player. http://www.craftymind.com/2008/04/18/updated-elastic-racetrack-for-flash-9-and-avm2/

Even with this approach, the frames still logically map together from a conceptual perspective. For me, I look at them as one in the same… even though they maybe defined technically different under the hood.

By: Lorenzo

Lorenzo — Tue, 03 Nov 2009 22:38:08 +0000

Dear James,

I really appreciate your blog!!! I have a question for you. You talked about SWF Frame and Flash Player Frame. So, could you give me the definition for these terms? SWF Frames are contained into a swf file and are like a logical units that contain assets and as code. Instead, a Flash Player frame is the time period between two consecutive enterframe events (controlled by frame rate). So,what is the relationship between them? In particular, I would know if they are paired each other or not.

Thanks in advance. Best Regards.

By: Annie

Annie — Thu, 01 Oct 2009 02:30:40 +0000

Hi, I have a question. In AVM2, both of the interpreter and JIT can compile the AS code.But when to use interpreter,when to use JIt?

By: James

James — Mon, 11 May 2009 16:34:50 +0000

You where correct in calling the AS3 to ByteCode process, compilation. The issue semantical issue that we face is that there is technically two compilation passes in the new Flash Player world. The first compilation pass is creating the SWF (which wraps the ByteCode) the second is when the AVM+ takes the ByteCode and compiles it to machine code for the specific platform the Player is running on.

When the first SWF compilation is being run there are optimization being applied, but they are limited to what the ByteCode can represent. I don't know exactly what optimizations are being made during this phase, but essentially all the Classes, objects, functions, properties, etc are being boiled down into commands that are executed by the AVM at run-time. The AVM is then responsible for converting these commands into machine code (second compilation) that the specific OS can understand. The reason we use the ByteCode interim step is that we want the same SWF to run on multiple OSs. This is why the Flash Player is still considered an interpreter because the SWF is not an OS native compiled application.

I feel your description is really close, what you are describing is the benefit of sealed classes versus dynamic classes. MovieClip is marked as a dynamic class, which means that you can attach new properties to it at run-time. Looking back at your first example, _nestedMovieClip is not a defined property on the MovieClip class, you have added this property. To access this property the AVM has to lookup the property on the instance to first see if it exists and if so then it can access it. This process is similar to using "for in" on an object, you have to loop over all the properties trying to see if it has the one you want. This is a time consuming process as you have found out through your testing.

More then likely, you are seeing the performance benefit by making a reference to the property and then accessing the reference because the lookup no longer has to occur every time you access the property. This is the same principle of using a pre-calculated length value when looping over an array instead of accessing the ".length" property each time. The act of accessing the property, i.e. "myArray.length" requires the lookup and calculation of the length to occur every time we perform a loop. If we crate a variable before we start the loop and set it to "myArray.length" then the loop will no longer call the length getter during every pass, making our loop run a lot faster. If we apply this to your example, then we can avoid the lookup by storing the instance in a reference variable and therefore the AVM only has to lookup the value once, to set the reference and then can access it faster from there.

We can actually take this one step further. If you read or see most peoples articles/presentations on Flash performance they always start with "use strong typing". The reason behind using strong typing is the same as making a reference, it helps mitigate AVM lookup time. If we take your BlueSquare example we want to make sure that BlueSquare has _nestedMovieClip declared as a property of the Class and that it is typed to MovieClip. By having this reference on the BlueSquare Class the AVM will not have to do full scanning lookup (ex: for in) on the BlueSquare instance to see if _nestedMoveiClip is both declared and has a value and that the value "x" also exists on the _nesteMovieClip instance.

By explicitly declaring _nestedMovieClip we have defined BlueSquare as a sealed class, which will give us a lot of performance gains at run-time. Dynamic Classes are great (Classes that can have properties added at runtime) but they come with a huge cost. I always recommend avoiding dynamic classes unless you absolutely have to and even then, try not to use them.

By: ultraky

ultraky — Sun, 10 May 2009 21:07:34 +0000

Thanks for taking the time to answer, I'm no engineer but trying hard to understand.

Before when I said 'Compiler' I was thinking of when Flash converts AS3 into Byte Code, but I was wrong to call it that. When that .swf is created, is it doing anything else besides just converting AS3 into Byte Code? I thought it was also pre-allocating and organizing 'stuff' for when that bytecode is loaded.

Reading your article again, I can now see there there is a 2nd compilation when the Byte Code is loaded into Virtual Machine, and the VM then allocates 'stuff'. After that does the JIT take over and task out commands? Am I close?

So far, it seems that the situation I referred to before is an area of interest to those who are looking to optimize. I have been doing lots of benchmarking using gSkinner's testing suite. So far my hypothesis has been correct, and I am seeing massive, massive performance gains when nested clips are declared before functions are performed on them. Also, the more objects that are inside that Movieclip ( either drawing objects, text fields, or symbols ) the more time it takes to access that specific object.

If I understand how the JIT works, this makes sense because the JIT doesn't know about that nested object before being told to manipulate it, it has to search for it. Does that make sense?

I will do a proper write up very shortly on my blog when I have really tested everything, when that happens I would love to hear your thoughts.

By: James

James — Fri, 08 May 2009 02:41:18 +0000

Alan,
I assume by "compile time" you mean the Flash Player's compilation of the byte code to machine code so that it can be executed, not the Flash compiler you use to create the SWF.

It depends upon when the construction of the nested clip occurs. By the time the Player gets to the your x value change the nested clip has had to be constructed and therefore the player will know about the instance.

The bigger question is if the method will be compiled by the JIT or not. JIT'ing doesn't occur on an Object or Class level, but on a bytecode level. Its possible that setting the x value may be JIT'ed but the MovieClip will not be compiled down entirely.

What is not clear to me, is when the actual JIT and MIR process is applied. Is it a look ahead process examines the entire app stack, or does it interpret every bytecode stack as its processed and on second execution does it apply the JIT? I have a feeling that the MIR is built on the first pass of the bytecode execution and the next time the code is called JIT is applied.

If that is the case, then your reference to the x value is not JIT'ed the first time you make the call, but the second time you do it will be JIT'ed. This is a really interesting topic, because at DevelopmentArc we have begun looking at performance increases around JIT optimization and knowing this could really help.

I hope this answered your question, or at least pointed you in the right direction.

J.

By: Alan

Alan — Fri, 08 May 2009 00:25:31 +0000

Wow this is incredible stuff. I just saw Jim talk at FITC in Toronto and I've been thirsting for more since.

I do have a question that maybe you can answer. Suppose I have a movieclip in my library set to export, lets call the class BlueSquare. In this example nothing is on the stage, and the library has a movieclip set to export. Nested in that class is another movieclip, and it has an instance name of nestedMovieClip.

Now somewhere in my code, I create an instance of that class BlueSquare:

var square:BlueSquare = new BlueSquare();

then I want to modify that nested movieclip:

square.nestedMovieClip.x = 100;

My question: At compile time, does the player know the existence of that nested movie clip, and therefore can the JIT create a reference to it on the first pass before it is used?

Whew.

Again, thanks for this article, I wish there was more stuff on this.