FirefoxのJavaScriptのエンジンが作り直しだそうです！

(注)：以下、一部、推測で書いた部分が間違っていて、詳しくはコメント欄をご覧ください。詳細は、JaegerMonkey - MozillaWikiに書いてありました。

Mozillaのオフィシャルブログの記事、improving JavaScript performance with JägerMonkey – Mozilla Hacks – the Web developer blog、によると、Firefox のJavaScriptのエンジンをAppleのWebKitのJavaScriptのエンジンをベースに作り直すそうです。僕が英語を読み間違えていないことを強く祈ります。名称は、JägerMonkeyと言うそうです。

元々、JavaScriptのJITコンパイラによる高速化は、FirefoxのTraceMonkeyから始まりました。まず、インタープリタで走らせてから、型を推測し、JITコンパイルするというやり方です。それに対して、Google ChromeのV8などは、インタープリタなどを使わずに、最初からJITコンパイルしています。ただし、V8でも、実行時に型情報をキャッシュし、2回目はその情報を利用しています。

Firefoxがこのやり方になったのは、EcmaScript 4を作ろうと、Adobeと協力している時に、AdobeのNanojitを効果的に使うには、変数の型情報が必要で、それを、インタープリタで走らせてから決めるというやり方にしたのがきっかけだと思います。ただし、EcmaScript 4は政治的に決裂し、なくなってしまいましたし、WebKitのJavaScriptベースにするということは、Nanojitをやめるという意味なのかな？V8などは、そもそも、x86とARMにしか対応していなく、CPU命令を生成する部分はコードを共有することなく、それぞればらばらに作っています。それゆえ、x86はSSE命令を使っていますし、CPU固有の最適化が行えています。また、ばらばらに作ったところで、CPU命令を生成する部分は、コード量がメチャメチャ多いというわけではないので（数千行）、開発工数が激増するわけではありません。それに対して、Nanojitを使っているFirefoxはNanojit自体が持っているCPUを抽象化した（つまり共通部分を抜き出した）オペコードを使っているみたいなので、たぶん、CPU固有の最適化がやりにくいのじゃないかと推測しています。（ちゃんとソースを読んでいないので、適当なこと書いているかも）

また、インタプリタとJITコンパイラを併用するタイプのため、型の推測が外れるなど、何かのタイミングでインタプリタに戻ってしまうことも多く、これが、大きく速度を低下させることがあります。ラベル付きのbreakやcontinueなどもFirefox 3.6はJITが効きません。ブログの内容から察するに、JägerMonkeyは併用型はやめてJITコンパイラのみにするのだと思います。

いまや、FirefoxはIE以外では、最も遅いJavaScriptエンジンになってしまったので、JägerMonkeyには期待します！JägerMonkeyになっても、ループのボトルネックになっている部分は、特別な最適化をかけるようです。

楽しみ♪