JRuby 1.6 RC1が発表された。改善点は多岐にわたる。Charles Nutter氏がJRuby 1.6の概要を説明している。また、Tom Enebo氏はWindowsサポートの強化について説明している。そしてYoko Harada氏はJRubyの組み込みAPIの変更を挙げている。
JRubyの現在と未来についてより詳しい情報を手に入れるため、InfoQはCharles Nutter氏に話を聞いた。
InfoQ: JRuby1.6の大きな変更点は何ですか。
JRuby 1.6 RCには2,000を超えるコミットがなされました。そして、260を超える問題を解決しました。JRuby 1.6は今までで最大のリリースになります。
JRuby 1.6 RCの主な特徴として、Ruby 1.9との互換性が挙げられます。JRubyはRubyの最新バージョン1.9.2.を追いかけています。JRuby 1.6は1.9のアプリケーションとの互換性が間違いなく強化されています。新しいエンコーディングAPIもサポートします。また、コードの性能が向上しました。JRuby 1.6は多くの性能改善をRuby 1.9から取り込んでいます。高速化された標準ライブラリも取り入れました。もちろん将来の開発に向けた下準備もやりました。
そしてWindowsのサポートを強化しました。JRuby 1.6ではWindowsのサポートを再度強化して、 WIN32OLEを組み込みでサポートするようにしました。また、他の環境と同じようにWindowsでもRubyのアプリケーションが滞りなく動くように互換性を改善しました。
Ruby 1.9.2との互換性は成功しました。次のリリースで追加しようと考えている機能もあります。例えば、 Encoding::Converter、非ASCII識別子、そして'ripper'ライブラリと'fiddle'ライブラリです。ユーザにはJRubyを1.9モードで動かして最終バージョンのリリース前に問題点を出してほしいと思います。
InfoQ:Fibersはどうですか。
FibersはJRuby 1.6 RCでも動きますが、将来のリリースでさらなる性能改善を行いたいと思っています。
InfoQ:最近のMLVMの中にはコルーチンをサポートするものがあります(Lukas Stadler氏の仕事でしょうか)。これについては試してみたことがありますか。
MLVMは試験的に使ったことがあります。将来のバージョンでサポートする予定です。
InfoQ:Rubyの使い手やNode.jsコミュニティのメンバの中には非同期処理とノンブロッキングI/Oの楽しさについて騒いでいる連中がいます。ブロッキングI/O対ノンブロッキングI/Oについてのあなたの意見を聞かせてください。
他のことと同じように、ふたつの方法を合わせるのが一番いいと思います。非同期I/Oを使えばワーカーキューにI/Oチャンネルを入れて、I/Oチャンネルが待っている間、スレッドやリソースを解放することができます。
シングルスレッドのランタイム、例えば、MRIやV8の場合、これはとても重要です。ひとつのスレッドしか利用できないからです。JRubyのようなマルチスレッドの実装だと非同期I/Oは便利なのですが、多くの並列ワーカースレッドを使ってブロッキングするコールもしないコールもできます。ふたつの方法を合わせるのが最も柔軟な方法です。システムコールや非同期をサポートしないライブラリに邪魔されることもありません。
InfoQ:JRubyは両方とも提供できそうですね。MRIとは違って並列スレッドがありますし、NIOもありますから。ノンブロッキングI/O(またはJava 7のNIO 2を使った非同期I/O)はどんな場合に役に立ちますか。
数千ものコネクションを扱わなければならないサーバやクライアントを実装する場合、より小さなワーカースレッドプールで大量の非同期I/Oチャンネルをさばかなくてはなりません。多くのユーザはこのような状況に直面しないと思いますが、非同期チャンネルが必要になったら、他に方法はありません。JRubyのI/Oサブシステムのすぐ下にはNIOがあります。なので多重送信できる選択可能なI/Oチャンネルを複数のスレッドで使えます。高度な並列性や高負荷なI/Oに興味があるRubyユーザはJRubyを使うことを検討する必要があります。
InfoQ:Ruby 2.0についての最近の動きはどう思いますか。例えば、Ruby Refinementsはどうでしょう。試してみましたか。JRubyに試験的に実装したりはしましたか(あなたはselector namespaceの初期のアイディアを試験的に実装していましたね)。
Refinementsは面白い機能だと思います。もう少し仕様が"精錬"されたらサポートしたいと思います。安全な名前空間のモンキーパッチはRubyに共通する問題に対処できると思います。Refinementsについてはコメントやプロトタイプの実装を通じて貢献をしています。今後も仕様が進化するのに合わせてサンプル実装を行いたいと思います。
InfoQ:今年はJava 7が登場するかもしれません。今後のJRubyのバージョンでJava 7の機能を使う予定ですか。もし使うなら最初に取り組みたいのはどんな機能ですか(invokedynamicに加えて)。
Java 7の機能についてはエンドツーエンドのサポートをしたいと思います。特にinvokedynamicとメソッドハンドルはとても役に立つでしょう。Rubyのコードを簡単にJVMに最適化できるからです。また、NIO2のファイルシステムレベル機能も面白そうです。シンボリックリンクやファイルシステムイベント、以前はネイティブPOSIX拡張経由でした利用できなかった多くの低レベルイベントが使えるようになります。NIO2を使えば、ファイルシステムの扱いについてはJRubyはネイティブのRubyの実装と同等の能力を持てます。プラットフォームを問わずにファイルシステムのイベントを扱えるRubyの実装としてはJRubyが最も信頼性のある実装になるでしょう。もちろん、Java 5とJava 6のサポートも続けていくつもりです。
InfoQ:JRuby 1.6の性能改善についてはどうですか。次のバージョンではどうなりますか。
Ruby呼び出しのオーバヘッド削減が最大の性能改善です。JRuby 1.5やそれ以前のバージョンでは、Rubyを呼び出す毎にスレッドローカルのデータ構造を追加していました。このデータは、バックトレースの作成や"super"呼び出し、現在の"self"と含んでいるクラスの特定などに利用していました。JRuby 1.6ではバックトレースの作成にこのデータ構造が必要なくなりました。その結果、多くのRubyのメソッドは呼び出しのオーバヘッドがほとんどなくなりました。ディスパッチに負荷がかかるようなベンチマークで性能が改善されました。
将来の最適化についても試作研究を始めています。上で述べた"backtrace"を使えば"dynopt"と呼ばれる機能を使えます。これによって、コンパイル時にJRubyのインタプリンタからの情報を使って動的な呼び出しを静的なJavaの呼び出しに変換できます。JRuby 1.6ではこの機能はサポートしていませんが。-Xcompile.dynopt=trueという引数をつければ利用できます。簡単にベンチマークを取ったところ、性能に大きな違いがでました。また、コンパイラの最適化も実験しています。新しいコンパイラと中間表現を構築して、JVMバイトコードを生成する前に簡単に最適化できるようにする実験です。これが実現できれば、JVMに解釈される前にRubyのコードを最適化できます。このふたつの機能が未来のリリースに含められるように継続して取り組んでいきます。