JRubyで有名なCharles Oliver Nutter氏が最近Rhinoプロジェクト(JavaScriptのJava実装)を支援し始めた。目的は、V8のようなエンジンと競えるくらいRhino JavaScriptランタイムを高速にするためだ。Rhinoは堅牢な実装だが、他のJavaScriptランタイムと比べて性能が悪い。氏はInvokedynamicを使ったり、他の最適化を行えば、Rhinoはもっと速くなると考えている。V8と競えるできるくらいには速くなる可能性がある。
InfoQは、氏とRhinoチームは何をするつもりなのか話を聞いた。氏はJVMのInvokedynamicを採用してRhinoのディスパッチの仕組みとJVMの最適化コンパイラを直接結ぶつもりだ。こうすることでメソッド呼び出し時のメソッドの検出や引数のボクシングのオーバヘッドを削減できる。また、インライン化を行ってJavaScriptからJavaScriptの呼び出しをJavaScriptからJavaの呼び出しと同等にし、全体を最適化する。氏の説明のよれば、invokedynamicを使うことでRhinoの呼び出しロジックはJava 6より遥かに簡単になる。
InfoQは氏にJavaScriptが次第に重要になっている今、JVMがより高速なJavascriptの実装を持っていることがどのくらい重要だと考えているのか話を聞いた。
私は個人的には、JavaScriptについて喧伝されている様々なことは誇張されていると思います。ブラウザで使うには優れた言語でしょう。しかし、優れているのは、すべてのブラウザがサポートしているからであって、ほかの言語より格段に優れているからではありません。
サーバサイドについて言えば、ランタイムが上手く動くようになり、クライアント用のライブラリがサーバでも上手く動くので人気が出ているのだと思います。 ...
しかし、エンドツーエンドのアプリケーションでJavaScriptが人気になっている状況ですが、JVMのバージョンも当然新しくなっています。また、おそらく最速のVMであるJVMがJavaScriptを競合と同じくらい高速に動かせないのは少し恥ずかしいことです。このような状況を変える時期が来たと考えています。
最後に、JRubyとRhinoの難しさを実装の観点から比べるとどうか尋ねた。
いろいろな意味でRhinoの方が簡単かもしれません。Rubyのような幅広い機能を持っていないからです。しかし、プロトタイプベースのオブジェクトモデルはRubyのようにメソッドテーブルのキャッシュを保存するためのはっきりとしたロケーションを残しません。これは興味深い課題です。V8やJohn Rose氏の"DavinciMonkey"(invokedynamicベースのRhinoの初期の実装)で使われているようなプロトタイプが変更される都度、総合したクラスを生成する技術を使えば、Rhinoも柔軟な型構造に簡単に対処できるでと思います。
Chromeに搭載されているV8エンジンとRhinoには圧倒的な性能差がある。氏はJVMのinvokedynamicのような特徴がこの差を埋めてくれるが、Rhino自体も性能を考慮してアップグレードしていく必要がある。Rhinoは素晴らしい実装だが、invokedynamicのような新しいJVMの技術も、JVMと関係ない技術も性能改善のために採用できる。
RhinoがJavaScriptのVMと競争できるようになるかどうかは分からないが、性能改善が進んでいるのは間違いない。