パフォーマンスが大幅に向上したJRuby 1.1のリリース

JRuby 1.0のリリース(参考記事・英語)から9ケ月後、 そして3 Release Candidatesの後(参考記事)、今や最終的なJRuby 1.1が利用可能になっている(source)。InfoQはJRubyのCharles Nutter氏(サイト・英語)およびOla Bini氏(サイト・英語)と情報交換し、JRuby 1.1での変更点とプロジェクトの今後の方向性について詳細を伺った。

Charles氏は、JRuby 1.1での主要な変更として以下の項目を挙げた。

最大の改良点は以下のとおりである。

• フルコンパイラで、RubyコードをJavaバイトコードに変換する
• IOサブシステムが再書き込みされ、Rubyの振る舞いにますます適合する
• Regexp新エンジンが、大幅に改善されたパフォーマンスで、Rubyのストリングをサポートする
• 全体的なパフォーマンスは、1.0のリリースの何倍も優れている

Ruby 1.8.6との互換性の実現のために、莫大な数の修正を重ねた。JRubyは、間違いなく最も互換性のあるサードパーティインプリメンテーションで、今後も長期間にわたってそうであり続ける。

そして、JRuby 1.1におけるパフォーマンスの見解を以下のように続けている。

一般的なRubyコードは、非常に高速に実行する。特に通常の式を大量に使用している場合は特にそうである。概して、RubyコードがRuby 1.8.6よりJRubyで高速に実行しない場合、バグとみなす。したがって他に潜んでいる障害を除去するため、バグレポートを探している。

JIT (Ruby source to Java bytecode Just In Time compiler)の他にパフォーマンス向上の動機はJoniであり、Oniguruma RegexエンジンのJavaポートである(参考記事)。Ola氏は以下のように概説している。

基本的に、通常の式エンジンはOnigurumaの完全なポートで、Ruby 1.9が使用するRegexエンジンである。ポートは、Marcin Mielżyński氏によってなされ、パフォーマンスが優れている。またOnigurumaオリジナルに未だ残っているバグの修正もおこなう。
その新たな実装によって、他のどんなJavaベースのRegexエンジンよりも優れたパフォーマンスが可能でありながら、 Ruby 1.8およびRuby 1.9との互換性も極めて良い。RegexおよびStringメソッドのほとんどが、完全に再実行されていて、新しいエンジンを効果的に使用する。

Charles氏が、さらに詳細を付け加えた。

Rubyのストリングは、単なるバイトの集合であるので、JRubyはJavaのバイト配列で実装する。このことが原因で、Javaの通常の式エンジンが 適切に実行することはなく、すべてのregexp操作はbyte[]をchar[]およびbackに変換する必要があった。しかし、JRubyコミッター の1人であるMarcin Mielzynski氏は、Onigurumaのポートに取り組んだ。それは、Ruby 1.9で多く使用されるバイトベースのエンコードにとらわれない通常の式エンジンである。「Joni」ライブラリのおかげで、これまでになく素晴らしい regexpサポートがある。そして基本的にはすべてのregexpパフォーマンスの問題は解決している。偉大な作業の結果であり、それに対する貢献は素 晴らしいものである。

1.1の開発サイクルが終了するにつれて、もちろん今後のリリースについて検討するときであることを意味している。Ruby空間の1つのテーマは、Ruby 1.9(参考記事リンク)の機能のサポートである。Ola氏は、現在の計画を以下のように説明している。

現在[1.9]は、開発リリースであるため、たいして影響を及ぼさない。役立つ2つの方法がある。1つは、1.9の機能はさらに安定しているので、 JRubyへの機能追加を適切に、簡単におこなえる。次に、1.9の本当の意味でのパフォーマンスの進歩を見出し始めているので、基本的にすべてのベンチ マークにおいて1.8を越えた今となっては、それと比較するという良い目標がある。.

JRubyへの1.9の機能の追加をすでに開始しており、それを継続的におこなっていく。もちろん、訂正や修正が最優先である。しかしたとえば、Onigurumaポートがストリングなどへのエンコードサポートの追加を容易にする。

2.0については、それほど取り上げてこなかった。個人的には、1.9および1.8に完全準拠するリリースは、2.0だと踏んでいる。1.2に関しては、 Javaの統合と外部APIの統合に取り組む予定である。今のところJavaの統合機能は実にうまく進んでいるが、実装上でいくつかホールがあり、その他 に非効率的な側面もあるので、サブシステムの徹底的な総点検を計画しているところである。もちろんこれは大掛かりな作業であるが、そのことで得られる向上 もかなり大きいものである。

いつものことであるが、パフォーマンスは重要なトピックである。以下のようにOla氏は、確実にパフォーマンスの向上が見込める分野を示している。

おおむねすべての分野でパフォーマンスの向上は期待できるが、スタックベースのローカル変数がセーフ、評価されていない、暴走がおこっていないと統計的に 判断することができる分野が、最も向上が期待できる。これらのメソッドで、コンパイラーから大幅な向上が実現でき、それらがプログラムでホットスポットで ある場合、一般的なランタイムが大幅に向上する。

Charles氏は、今後の計画について以下のように話している。

JRuby 1.1の後に、検討したい分野は1.9のサポートとJavaのさらに優れた統合である。その作業は、結局JRuby 1.2になるか、JRuby 2.0には十分大きすぎるかもしれない。そしてもちろん、パフォーマンスの向上は継続しておこない、一歩抜きん出ているように努める。しかし現在はかなり 満足している。 JRuby 1.1がリリースされてしばらくした後、Ruby 1.9機能での作業を検討している。しかしながら、その分野で莫大な時間を費やす前に、1.9の機能セットが安定するのを見たい。1.9機能の変更を来年もずっと追跡するようなことは本当にしたくない。特に1.9が急速に進化しているようだからである。

またCharles氏は、JRubyのパフォーマンスのみならずJVMの動的言語のパフォーマンスに関する今後の向上についても考えを述べている。

JVMの動的言語の潜在性を何としても公開する必要があると思う。もしそれが、新たな、ひょっとしたらOpenJDKの非互換の「フォーク」を作成するこ とを意味するならば、それでよい。そのような作業がJavaに適切に統合することができないわけはなく、開発されるのを待っている本当に驚くほど素晴らし いVMがある。人びとが利用できることを知った今、OpenJDKにとって非常に重要な年になると考える。人びとが考え付くあらゆるOpenJDKの試み を利用しているJRubyの作業がある。

JVMの動的言語サポートを向上する計画やプロジェクトを参照したり(参考記事)、その研究の詳細を直接Da Vinci Machine Webサイト(source)で覗いてみるのもよい。

InfoQで取り上げているJRuby(参考記事リンク)を参考にすることもできる。

原文はこちらです：http://www.infoq.com/news/2008/04/jruby-1-1-release