Mhh. LuaJit has quite shown that TraceJit can be awesome for dynamic languages. Sure JS has less potential to be optimized then lua (see in this http://lambda-the-ultimate.org/node/3851 LtU thread somewhere and read the rest anyway if your intressted in JITs) but the genarall aprouch could still be used.
LuaJit does it by using a very fast interpreter and a tracecompiler. The secret souce seams to be a SSA based bytecode. Im not sure how the Mozilla interpreter works but since its a relice I doute that its a bytecode optimized for interpreting and compilling. If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise.
If the language is to hart to interpret one could write a simple first stage method-jit and a trace-jit behind it. Exiting times in JIT-Land spezially for dynamic languages. Lets see who comes out with the best implementation in the long run.
The article already explains this, doesn't it? The code had both a Trace-JIT and a Method-JIT [1], but that switching between the two to use the fastest is problematic and that its apparently easier to get the Method-JIT to incorporate more advanced optimization and outperform the Trace-JIT in the end.
If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise.
I'm not an expert but the existence of "SpiderMonkey" "TraceMonkey" "JeagerMonkey" and "IonMonkey" (which can apparently be disabled independently) seems to suggest they have no problems with that.
[1] I presume there is always a fallback interpreter as well.
The method I talked about would work diffrent let me expand a little. I can imagen that jumping between two jits is problematic spezially if there is an interpreter throwen in. The method I talk about would use a simple method jit that generates assembly and the code to enable tracing. This compiler would not optimize anything only get rid of the interpreter overhead. Then the trace jit would jump in if it finds a worthy trace. There would be no switching between the two only from one to the other. In the LtU thread they talk about this too.
I don't read anywhere that the method-jit is better in optimizing, i only that the trace-jit dosn't find enought stuff to win. Once you have a good trace you can optimize it like crazy.
Mozilla seams to move in this direction, they have thrown out Tracemonky but in the longrun add one again and as far as I know the want to throw out spidermonky too. The diffrence would be that they would have more power in the method jit and less in the trace jit.
The reason I said that they would have reimplemented alot is that for the intepreter/simple-jit method and trace-jit to work well you need a nicly designed bytecode and I'm not sure they have one atm (I don't really know). There existing implmentation would have to be reworked to use a new bytecode.
Part of the reason is also that Mike Pall is actually a hyper-advanced cyborg from the future.
In case you're not sure what I'm talking about, read through the LuaJIT source code at some point. It's a thing of beauty - he's handcrafted assembly to make everything run as fast as possible, on all of x86, x64, PowerPC and now ARM.
The article says the tracing JIT can be faster for tight, non-branchy code. I imagine that Lua programs would be tighter and less branchy than JavaScript, which has many small callback functions invoked by native code.
I would rather say that article says that the trace jit they build is only faster for tight, non-branchy code. I would say that the generall JS programmen has this property but Mike Pall has showed that in the end trace-jit are better. He wrote LuaJit 1 witch is a method jit and LuaJit 2 witch is a trace-jit and his conclution with luajit one was that he hit a performance wall.
Its not diffrent. I was discribing what was happening.
Well I think the evidence is not fully in on that jet. Method Jits are much older and there is a alot of reserach done in it spezially the old Self papers. Almost everything done in JS has allready been used in Self. Even some of the same people work on the JS implmentation.
Tracing jit are relativly reason and LuaJit shows how it can work out. It could well be in the end a compination of both is best.
LuaJit does it by using a very fast interpreter and a tracecompiler. The secret souce seams to be a SSA based bytecode. Im not sure how the Mozilla interpreter works but since its a relice I doute that its a bytecode optimized for interpreting and compilling. If Mozilla would adopt the same method LuaJit uses they would have to reimplment everything from ground up. Witch probebly wouldn't be a smart move buisnesswise.
If the language is to hart to interpret one could write a simple first stage method-jit and a trace-jit behind it. Exiting times in JIT-Land spezially for dynamic languages. Lets see who comes out with the best implementation in the long run.