Tuesday, June 3rd, 2008

SquirrelFish: Details on the new

Category: JavaScript, Performance, WebKit

We posted about the new WebKit JavaScript engine SquirrelFish, and now we have an official announcement that goes into fantastic detail on the beast:

What is SquirrelFish

SquirrelFish is a register-based, direct-threaded, high-level bytecode engine, with a sliding register window calling convention. It lazily generates bytecodes from a syntax tree, using a simple one-pass compiler with built-in copy propagation.

SquirrelFish owes a lot of its design to some of the latest research in the field of efficient virtual machines, including research done by Professor M. Anton Ertl, et al, Professor David Gregg, et al, and the developers of the Lua programming language.

The post then goes into detail on why it is so much faster:

SquirrelFish’s bytecode engine elegantly eliminates almost all of the overhead of a tree-walking interpreter. First, a bytecode stream exactly describes the operations needed to execute a program. Compiling to bytecode implicitly strips away irrelevant grammatical structure. Second, a bytecode dispatch is a single direct memory read, followed by a single indirect branch. Therefore, executing a bytecode instruction is much faster than visiting a syntax tree node. Third, with the syntax tree gone, the interpreter no longer needs to propagate execution state between syntax tree nodes.

The bytecode’s register representation and calling convention work together to produce other speedups, as well. For example, jumping to the first instruction in a JavaScript function, which used to require two C++ function calls, one of them virtual, now requires just a single bytecode dispatch. At the same time, the bytecode compiler, which knows how to strip away many forms of intermediate copying, can often arrange to pass arguments to a JavaScript function without any copying.

And finishes by promising that this is just the beginning, and that we are going to see even faster:

In a typical compiler, conversion to bytecode is just a means to an end, not an end in itself. The purpose of the conversion is to “lower” an abstract tree of grammatical constructs to a concrete vector of execution primitives, the latter form being more amenable to well-known optimization techniques.

Therefore, though we’re very happy with SquirrelFish’s current performance, we also believe that it’s just the beginning. Some of the compile-time optimizations we’re looking at, now that we have a bytecode representation, include:

  • constant folding
  • more aggressive copy propagation
  • type inference—both exact and speculative
  • specialization based on expression context—especially void and boolean context
  • peephole optimization
  • escape analysis

This is an interesting problem space. Since many scripts on the web are executed once and then thrown away, we need to invent versions of these optimizations that are simple and efficient. Moreover, since JavaScript is such a dynamic language, we also need to invent versions of these optimizations that are resilient in the context of an unknown environment.

We’re also looking at further optimizing the virtual machine, including:

  • constant pool instructions
  • superinstructions
  • instructions with implicit register operands
  • advanced dispatch techniques, like instruction duplication and context threading
  • getting computed goto working on Windows

Performance on Windows has extra room to grow because the interpreter on Windows is not direct-threaded yet. In place of computed goto, it uses a switch statement inside a loop.

Not only is SquirrelFish exciting, but the post itself shows that they get that this is aimed at developers. Great job.

Posted by Dion Almaer at 9:21 am

4.3 rating from 36 votes


Comments feed TrackBack URI

Does this turn up the flame on the Firefox team to get their long-awaited Tamarin-tracing JavaScript into the browser? Last I heard, that was still going to be a while.

Comment by Nosredna — June 3, 2008

It would be kinf of neat to see javascript distributed as bytecode in the future, which would mean faster & smaller scripts and applications.

The downside being the source won’t be as easy to read, but then, since we minify/compress most of our javascript these days anyway, it wouldn’t be such a loss.

Comment by Anonymouse — June 3, 2008

That’s a really ugly fish by the way. It looks drunk.

Comment by Jeria — June 3, 2008

Nosredna, Tamarin will only appear on Firefox 4, I don’t think there’s any way around that. And the tracing branch is still on its early stages, but I believe there’s plenty of time for it to mature until Fx 4 is out.

Comment by Danie Luz — June 3, 2008

AIR uses Webkit, no? Perhaps this will make the JavaScript half of AIR as fast as the ActionScript half of AIR.

Or does AIR use the rendering part of Webkit only?

Comment by Nosredna — June 3, 2008

All js in a web view in AIR uses JavaScriptCore. The problem facing AIR devs is how long Adobe will take to update the Webkit core in AIR. It’s currently shipping with a version significantly older than Safari 3.0’s core.

Comment by eyelidlessness — June 3, 2008

Dave Mandelin’s followup: http://blog.mozilla.com/dmandelin/2008/06/03/squirrelfish/

Comment by TNO — June 4, 2008

Leave a comment

You must be logged in to post a comment.