Hi Geoff - It sounds as though you looked at adopting Tamarin and decided against it. Can you flesh out what you came up with as the pros and cons of using Tamarin vs. writing a new engine from scratch? Did you have discussions with the folks involved in Tamarin regarding adapting it to your needs? As I'm sure you know, writing a world class VM and moving it forward is hard and expensive. I hate to our see efforts being split across multiple JS implementations, which dilutes all of our time for moving the web forward.
Ed Rowe Adobe Systems -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey Garen Sent: Tuesday, March 04, 2008 12:01 PM To: Akos Kiss Cc: [email protected] Subject: Re: [webkit-dev] interested in js speed-up 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
