Vivisecting Media

Update to Part 3 and Part 4 of Flash Internals…

December 10th, 2007 Posted in ActionScript, Flash Player, Rich Internet Applications

Rick Reitmaier, Senior Computer Scientist at Adobe, took a few minutes of his time to review my writeup on the JIT engine within the Flash/Tamarin VM. Rick was part of the team that helped design and build the AVM+. I got to know Rick back when I worked on the Flex Builder team and I would like to thank him for his input. I am providing his comments in this post and linking back to the sections he was referring to. I have indented my writing and all first person references from here on out are the comments directly from Rick.

Rick’s comments to Part Three: The ActionScript Virtual Machine

“AVM+ is due to the radically different design, there was no way it could be backward compatible”

Not quite true, we could make it backward compatible and considered doing it, but it would have taken too long.

Also regarding file size increase, I’d say you’ll want to look at the file size of fp8 and fp9 and see that its not too bad; ‘dramatically’ in my mind means orders of magnitude.

Strictly speaking we are somewhat compliant with a draft of the ECMAScript spec, the spec has not been finalized as you correctly point out in a later paragraph.

Rick’s Comments on Part Four: Just-in-time (JIT) compilation

“Typically, the AS3 byte code is handed one by one to the VM which then leverages the specific platforms interpreter (aka Flash Player) to compile the passed data to the proper machine code. Byte Code is optimized for performance, but you still have to compile each one at a time as they are passed into the interpreter. This becomes a performance bottleneck if your code makes a call to a previously referred Byte Code (ala function). If this is the case (and it happens ALL the time) the same Byte Code has to be e-complied when it is queued up. Not exactly fast nor efficient.”

If what you mean is that the interpreter operates on a byte code by byte code basis then its correct (ed. note: it was what I meant). Each byte code is decoded and then a corresponding action is performed on it. Think of big switch statement like:

while(1) {
switch(ip) {
    case PUSH:
    // code that pushes something on the stack


case POP:
// code that pops something from the stack


}
ip = ip + 1;  // move on to next bytecode.
}

Copy and constant propagation do not deal with conditional branches. An example of copy prop would be y = x z = y <= here we’d replace y with x to get z = x Constant prop. is the same algorithm but using constants

Also regarding MIR. Our unit of compilation is a method. So, the bytecodes for an entire method are transformed into MIR and its easier to think of MIR as just a slightly more verbose version of the bytecode, not as some fundamentally different data structure.

---

Thank you again Rick for you candid and insightful update!