[webkit-dev] interested in js speed-up

[Geoffrey Garen]

Hi Akos.

Any help speeding up JavaScriptCore is welcome.

The current plan is:
1. Convert from an AST execution engine to a custom bytecode engine
2. Perform low-cost optimizations on the custom bytecode (e.g., simple  
type inference, peephole optimization, constant folding, copy  
propagation, hoisting constants out of loops)
3. JIT from custom bytecode to machine code at function granularity
4. Optimize other parts of the JS runtime, like the garbage collector  
and the regular expression engine

We plan to finish stage 1 of this plan, which will be pretty  
disruptive, by the end of the month.

> We have compiled a small list of enhancement possibilities, see below.
> Please consider it as the view of an outsider.
>
> ---
> 1) Optimizing the AST
>  a) either during AST building
>  b) or the already built, complete AST, possibly in a background  
> thread.

We already perform a number of optimizations on the AST. Are there any  
specific additions you would recommend / like to work on?

> Comment: The execution model of the JS engine is quite simple. It  
> simply
> builds an AST from the source and executes it. Thus, there are no CFG,
> basic blocks, use-definition chains, etc., which are common in
> traditional optimizing compilers. This either makes the possible
> optimizations less powerful or requires significan effort to implement
> such analysis techniques.

Indeed, those kinds of analysis tools could be very helpful. They  
could guide optimization, but they could also help us move from a  
function-granularity JIT to a tracing JIT.

As we make the parser / compiler more intelligent, the key challenge  
we face is ensuring that it's still very fast -- ensuring that we can  
still render web pages in less than 200ms (and sometimes, less than  
10ms!).

> 2) Optimizing the AST execution.
>
> Comment: Not enough knowledge on the internals.

Since we plan to move away from AST execution soon, I don't think  
optimizing AST execution would be very valuable.

> 3) JIT compiling the AST to another language.
>  a) JIT compilation to native code.
>
> Comment: Furthermore, the engine is currently platform independent.  
> This
> would require platform-specific code on a per platform basis.

Yes.

>  b) JIT compilation to Java bytecode or ActionScript bytecode.
>
> Comment: Huge work. Currently available compiler implementations do  
> not
> fit to the architecture of the JS engine.

Right. We're also reluctant to rely on code that we don't own. We've  
seen very large performance wins from tightly integrating and  
customizing all the components of the web stack. We also need the  
freedom to fix crashes and compatibility problems on very short notice  
(for example, 12 hours before a keynote address).

>  c) JIT compilation to a new intermediate language.
>
> Comment: Is it a good idea to come up with yet-another-bytecode?
> Interesting: According to the homepage, there are plans to use a
> bytecode interpreter in the JS engine. However, it is not specified  
> what
> kind of bytecode is meant: Java, ActionScript, or a new one?

A new one.

I suppose the world is not eager to see yet-another-bytecode, but, in  
prototyping, we've seen measurable performance wins from fine-tuning  
the bytecode to match JavaScript idioms.

> So, this is our view. But before starting any work, we would like to
> hear the opinion of the developers. What do you think of the above?  
> Did
> we left out something important? Do you think that we can contribute
> somehow?

I definitely think you can contribute. We could really use the help of  
some compiler experts!

If you're interested in writing optimization passes for the bytecode,  
that's great. If you're interested in experimenting with translating  
JavaScriptCore's emitted instructions into a lower level, more  
established bytecode (for example, the Tamarin engine translates many  
instructions to Forth), that's great, too. There's really no limit to  
what you can contribute.

Since many of us working on the project are not compiler experts, the  
best contribution you can make might be something we haven't thought  
of yet.

I encourage you to dive into the code now, to gain a greater  
understanding of its internals. Feel free to ask question on IRC  
(#webkit on irc.freenode.net). The bytecode changes in the short term  
will be pretty disruptive to the execution engine, but the AST and the  
rest of the runtime should remain intact.

If you have an optimization idea you want to discuss, this is a great  
forum. But you should also feel free just to write up a patch and post  
it in bugzilla for comment.

Cheers,
Geoff