Why TraceMonkey is maybe the wrong way

With Firefox 3.5 finally out the door and in use I thought it was time to write something about it that’s been bugging me for a while. TraceMonkey (the new FF JavaScript engine) employs a semi-Hotspot approach to JavaScript compilation. Although the approach is quite different under-the-hood, the basic principal is the same: interpret the code until you know what to optimize. This makes abundant sense to me: why go through the expense of native compiling a method that only ever gets run once? However: there is a hidden expense to doing things this way: your compilation unit is often much smaller. Smaller compilation-units means more compiled code that needs to go back and forth to interpreted code. It also means you can’t optimize as heavily (although that optimization has it’s own massive expense).

Where am I heading with this? I think the TraceMonkey approach adds huge value to a language like Java where an application consists of hundreds and / or thousands of classes (both those in the application and all of it’s dependent APIs), in this case: you’re loading time would be abysmal if you pre-loaded all the possibly used code and native compiled it on start-up. However in the JavaScript world we are limited by the connection, and JavaScript applications (even really huge ones like those written with GWT) are relatively small. In this case it makes more sense to me to either compile everything up front; or run everything interpreted and run a massive compilation in the background (hot-swapping the implementations when you’re finished the compile).

It’s just a thought. Maybe FF should adopt v8 and see what happens?


3 Responses to “Why TraceMonkey is maybe the wrong way”

  1. Luis González Says:

    You’re probably right, and so far, v8 seems to perform much better than tracemonkey (at least in object intensive applications), although tracemonkey performs better in compute intensive mathematical code.
    But I wonder if we are comparing oranges to apples…
    Perhaps v8’s pproach makes sense for applications such as gmail (lots of objects), but is this the typical kind of applications for a dynamic language?

    By the way, I don’t quite understand how does v8 compile everything upfront…
    Dynamic languages lack enough information (such as types) , so if v8 doesn’t interpret the code first, how does it figure out the types to compile upfront??

    • Jason Says:

      Actually dynamic language applications tend to produce far more objects than traditional languages. Particularly in JS, where numbers typed as constants are still objects. This is in fact what makes JS so difficult to compile, everything needs to be treated as though it’s a Map of Strings to objects (even Functions).

      On your second point: compiling everything upfront is actually pretty easy. Rhino (the pure-Java JS engine) also compiles all the JS into Java bytecode upfront. In a way, JS has no types, in another way it has one: “object”. Baring in mind that by carefully reading the code of a Function (or other object declaration), you can often determine 90%-100% of the fields it has, especially after some simple code normalization. The other 10% of the fields (those thrown in from the outside) can be handled by attaching a lazy-initialized Map of Strings to Objects to each object (it could be as easy as allocating an extra field slot).

      So basically: because everything in JS is eventually an object, all of your field slots are actually references, so you don’t need the type information at compile-time. To deal with the lack of staticly-coded fields, you try and figure out which fields there are as best you can, and for those that get added later you do it that standard JS way: a hashtable.

  2. Luis González Says:

    I see, but I still find confussing how the task of infering types is performed. In tracemonkey, it is handled by the interpreter. But if there is no interpreter, all this logic has to be included into the compiled code. Isn’t it?
    So if it can be done this way, why do we need interpreters in the first place?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: