OSNews

Webkit doesn't use an interpreter at all, it uses a compiler. A "just in time" compiler, to be accurate.

Because it involves an extra "compile step" (beyond the syntax parsing step) a compiler is actually slower than an interpreter for code that runs through just once. OTOH, because it does compile native code, a JIT compiler is much faster than an interpreter for any code that loops.

Mozilla's current Javascript accelerator, called Tracemonkey, is an interpreter with optimization via code tracing.

http://blog.mozilla.com/dmandelin/2010/02/26/starting-jagermonkey/
"About 2 months ago, we started work on JägerMonkey, a new “baseline” method JIT compiler for SpiderMonkey (and Firefox). The reason we’re doing this is that TraceMonkey is very fast for code that traces well, but for code that doesn’t trace, we’re stuck with the interpreter, which is not fast."

The concept for JägerMonkey is to use Apple's Nitro Assembler to generate efficient native code (i.e. use the same JIT compiler method as webkit), but also implement the benefits of Tracemonkey where it applies.

"The JägerMonkey method JIT will provide a much better performance baseline, and tracing will continue to speed us up on code where it applies."

The idea is to get the best of both approaches. In other words, this is fine example of the open-source "meritocracy" approach at work.

If it works, of course. If Mozilla run into snags, it might not work ... in which case the "meritocracy" approach would be to just drop it. In open source development, there is no point on hanging on to something just because it is your product. A "NIH" attitude doesn't really apply, or at least it shouldn't.

If Mozilla can pull this off, it has the potential to put Firefox back in the lead in the browser speed stakes.

Edited 2010-03-10 10:40 UTC

Hahaha. The best joke for a long time.

>>Webkit doesn't use an interpreter at all, it uses a compiler. A "just in time" compiler, to be accurate.

Perhaps you do not realize this, but most JIT compilers augment an interpreter. Take a class written in Java or C# for example, if there is a method that gets called one or a few times, it is not compiled to native code, it is interpreted. Another method called a few hundred times will be compiled to native code.

Why you ask? Take any large managed code application, lets use Netbeans. Instruct the VM for the language (in this case the JVM) to compile *every* method before use. You will find for the first 10-60 minutes (depending on your machine) the software is unusably slow.

I don't know the details of the webkit JIT but it probably does the same thing. Then again, becuase the volume of code on a website is so small compared to an application, perhaps I am mistaken and it does not.

This is not totally accurate. They are using a "tracing" JIT, which does some code analysis and will compile the bits that make sense. What you are talking about is a static JIT, which is how googles V8 engine works.