JavaScriptはJava, .netに続くIL環境になれるか

この記事は古い postmortem: http://d.hatena.ne.jp/mjt/20110502/p1
OSという文脈はともかく、Google Chromeが現在の環境としてもっとも重要な言語処理系を配布しているということは注目に値する。

Java, .net, LLVMが乗れなかったのは何故か

重要なのは、JavaScriptのJITCという市場に、Javaや他の中間言語システムが乗れなかったというポイントに思える。
市場にあるほぼ全てのJavaScript JITCは、自前の(互換性のない)中間言語とコンパイラを持ち、他の言語を取り入れる余裕が無い。
そうなると、今後はJavaのバイトコードを出力する代わりに、JavaScriptを出力するコンパイラが求められる時代が来るかも知れない。
例えば、ダイナミックリコンパイルを伴うエミュレータをそれぞれの環境で実現することを考える。IKVM(Java→.net)やRhino(JavaScript→Java)、JPSX(MIPS→Java)のような共通のインフラストラクチャの存在する環境では十分に実現できるが、これをJavaScriptに置き換えることによるオーバーヘッドや、言語マッピング戦略などは検討されなければならない。

fat IL

従来の中間言語(IL)に比べて、モダンな高級言語をILとして使うことをとりあえずfat ILと呼んでおく。
過去に、OLEというバイトフォーマットから近年のXMLへ移行したように、中間言語というバイトフォーマットからJavaScriptといったfat ILへの移行が行われる場合、個々のJITCにおける変換の共通項を模索する必要が生じる。
fat ILとして既存の言語を使用する試みとしては、qemu(のdyngen)がC言語を使ってコードフラグメントを生成していたことが思い当たる。しかし、JavaScriptをfat ILとして利用する場合は、よりモダンな言語機能(GCや例外、XMLや日付処理といった各種ライブラリ)と適切にマッピングをしなければネイティブと同等のパフォーマンスを実現することは難しいかも知れない。
性質の近い言語とは良くマッピングすると考えられる。JavaScriptはJavaに『似て』いるので、GC等の言語機能を期待したILのコードをそのまま変換しても大きな問題は発生しないだろう。
逆に、C言語やLLVMのILといった単純なシステムをマッピングするのは難しい問題になりうる。
例えば、JavaScriptはデータ構造をプログラミングしない。これは2方向の問題となる。つまり、「データ構造を解体し、クラスに分配する」ことと、「クラスをデータ構造に置き換える」ことの両方が必要になる。
データ構造を解体するのは、C言語では構造体の位置に依存したコードを記述できるという問題のために必要になる。必要なときにだけ構造体をメモリ上に再現することで無駄な加工処理を減らせる可能性がある。
後者は本来はコンパイラが考えるべき問題だが、望んだ構造体を得るようにコード生成側も配慮する必要があるだろう。
もっとも、Google ChromeしかJavaScriptのJITCを普及させられないのなら、そもそもfat ILを考えること自体にあまり意味が無くなる。他の処理系の動向も注視しなければならない。
問題を単純化するなら、以下の疑問にまとめられる。

• JavaScriptでJVMを効率的に実装できるのか
• Java Bytecodeを経由し、JavaScirptで実現されたJVMで実行するのと、JavaScriptコードを直接出力するのではどのような違いがあるのか
• LLVMのような軽い中間言語と争った場合はどうか

個人的には、データ構造を抽象化に含んでいない中間言語環境(つまりこれはJVM等も含む)では、今後のアーキテクチャの変化に対応出来ないのではないかと考える。例えばSIMD化やプリフェッチなどのテクニックは今後不可欠になるが、その良いサポートのためには適切なデータ構造の生成が必要になる。