IonMonkeyは、SpiderMonkey JavaScriptエンジンで新しく多くの最適化を実現することを目的とした、Mozillaの新しいJavascript JITの名称である。InfoQでは、主要開発者David Anderson氏に対し、この新しい開発によってFirefox、Thunderbird、Adobe Acrobat、MongoDB、そして他にもあるSpiderMonkeyエンジンを利用する製品にもたらされる大きな改善について、いくつかのQ&Aを行った。
この新しいJITインフラストラクチャは、型の特殊化、関数インライン化、線形走査レジスタ割付、デッドコード削除、ループ内不変値移動といった先進的な最適化を容易にするSSAコンパイラ中間表現を特徴とすることになるだろう。
主にIonMonkeyの開発を駆り立てる力は次のようなものだ：
- Trace JITやCrankshaftと速度において互角またはそれ以上のバックエンドを提供すること。副次的な目標として：
- 細かい粒度の特殊化（specialization）と非特殊化（de-specialization）。
- 型推論の統合。
- 明確で、教科書通りの中間表現により、最適化パスを分離し、よく知られたアルゴリズムでパイプライン化できること。
- 実装とその副作用が容易に理解できる十分な文書とコメント。
- 再コンパイル、デバッグ、ベイルアウトはすべて関係している - そして、事前に解決されるべきである。
- ピアレビューから始めるはじめてのSpiderMonkey JITであること！
- （実現可能性は不明だが）JM2を置き換える基準コンパイラとしての活動。
- x64でのレンジ問題を避けることも含め、メモリ管理をずっとよくすること。
InfoQは主要開発者David Anderson氏にIonMonkeyについていくつかのQ&Aを行った。
InfoQ： Javaのような言語のJITコンパイルについては数多く取り上げられていますが、JavaScriptのような動的言語のJITコンパイラを設計することの主な難しさは何でしょうか？
David氏： 最大の問題は、Javaと違ってJavaScriptは型付けされていない、ということです。例えば、Javaで2つの変数を加えることは簡単です。それらの変数が整数か、倍精度浮動小数点数かなどが厳密にわかり、JITはそれらを加えるための1つか2つの機械命令を生成することができます。
JavaScriptでは、このような型の情報は持っていません。2つの変数を加えたいなら、それらの型を動的に調査し、正しい強制（coercion）と加算のアルゴリズムを使う必要があります。そうした検査や潜在的なディスパッチはすべて本当に遅く、その結果がどうなるかがわからないことがさらなる最適化を妨げます。
JavaScript JITはこの問題を楽観的に一般的なユースケースから始めることで解決しようとします。たとえば、加算に対して生成されたコードは最初は整数に対するチェックと演算のみを行おうとするかもしれません。これらのチェックが失敗したら、代わりに新しい型に対するコードに切り替えるでしょう。これはまだJavaのものほどよいものではありません。というのも、Javaはそのような型チェックを必要としないはずだからです。
JavaScript JITの最新の活動の多くはより正確で完全な型情報をどのように得るかを見つけ出すことに関するものです。これらのチェックを除去することは優れたレジスタ割付や冗長なコードの除去といった、型付けされた言語のコンパイラにはあるものを実現するのに重要なことなのです。
この難しさの別の側面は、型情報を極限まで高速に得ることです。非常に重い分析がウェブメールアプリ上で実行されてしまうためにブラウザが数秒間固まってしまうとしたら、ユーザはまったくいい気分はしないでしょう。（たいてい短時間しか動作しない）ベンチマークにとってさえ、分析時間のトレードオフは微妙な問題になり得ます。
InfoQ： JavaScriptの動的な性質によって得られ、静的な型付け言語では意味をなさないような先進的な最適化は何かありますか？
David氏： 動的言語が生来備えている最適化の利点というようなものはおそらくありませんが、静的言語が持ち合わせていない興味深い最適化があります。たとえば、JavaScriptを書いているとき、ユーザにとってオブジェクトはプロパティ名を値に対応させるハッシュテーブルのように見えます。かりにそれらが実際にそのように実装されたとすると、速度は遅くメモリを多く使うものになるでしょう。
すぐれたエンジンは同じであるように見えるオブジェクトを内部的にグループ化します。オブジェクト群の中から内部的にJavaライクなクラスを抽出するようなことを実行するのです。そうすることにより、JITはオブジェクトを実際に型を持っているように扱うことができ、コストの高いプロパティ検索を避ける非常に高速なコードを生成します。
InfoQ： IonMonkeyとV8で使われているCrankshaftの主な違いは何でしょうか？
David氏： IonMonkeyは私たちにとって長期の投資であると述べておくべきでしょう。Firefoxはすでに2つのJITを持っていて、IonMonkeyは3つ目になります。V8も3つ持っています。この調子でいくと、私たちは毎年新しいJITを加えることになるでしょう。
私たちは統合して、IonMonkeyを全ての最適化の作業や研究のための単一のプラットフォームにしようとしています。IonMonkeyに"速度"や"シナリオ"のノブのようなものを与えて、状況に応じて適合できるようにしようとしています。単一のプラットフォームにするというのは、JaegerMonkeyのように、ほぼすべてのコードをx86、x64、ARMで共有することに特に注意を払っていることも意味しています。私たちはこのようなことをしているたった1つのオープンソースエンジンだと考えています。
より興味深い相違はBrian Hackett氏の型推論で、Mozillaで進行中のとてもクールなプロジェクトです。これは、静的分析と動的分析のハイブリッドで、JavaScriptプログラムのすべての変数やプロパティの型を確実に正確に特定することができます。これによりランタイム時チェックをすべて除去することができ、そうしなければ不可能な最適化を実現することが可能になります。彼はこの1年でプロジェクトを驚くほど進捗させ、今はコミュニティメンバもそれを助けています。非常に有望です。
InfoQ： IonMonkeyを他の動的言語のコンパイルインフラストラクチャと比較した場合どうでしょうか？
David氏： LuaJITとPyPyが思い浮かびます - ともに私たちの最初のJIT、TraceMonkeyでも取り入れた非常に積極的な特殊化戦略であるトレースコンパイルを追求しています。解決すべき問題はとても似ています。最適化度合いの高いコードから動的なプログラムを復元することを可能にする必要があり、あまりに積極的すぎた場合に最適化を戻すことも頻繁に行わなければなりません。LuaJITとPyPyはともに柔軟に扱える中間表現を持っていて、それは私たちが構築しようとしている基盤です。
IonMonkeyは現在設計段階にあり、Mozillaの特有の伝統にのっとってその過程はかなり公開されている。このInfoQでも、JavaScriptに関するさらなる情報を見つけられるだろう！
Dionysios G. Synodinos氏 はWebエンジニア兼Web技術にフォーカスしたフリーランスのコンサルタント。
$("