NewsInsight

CommunityOne/JavaOneレポート

Javaプラットフォームを進化させるJRuby

2009/06/12

　「JVM上で不可能なことなど何もない」（Nothing is impossible on the JVM）――、こう話すのはJRubyでコア開発メンバーを務めるチャールズ・ナッター氏だ。2009年6月1日、米国サンフランシスコで開催されたCommunityOne（JavaOne）で講演したナッター氏は、JavaVM上にRuby処理系を実装した経験について話した。当初まったく実現不可能に思えたプロジェクトで、どう障害を乗り越え、その取り組みがいかにJavaプラットフォームに影響を与えているかについて解説した。講演のタイトルは「不可能を超えて：JRubyはいかにJavaプラットフォームを進化させたか」（Beyond Impossible:How JRuby Has Evolved the Java Platform）だ。

Ruby on JVM!? そんなの実現不可能！

　もともとJava言語向けに開発されたJVMだが、最近ではScala、Clojure、Groovy、JRubyなど多くのプログラミング言語が利用可能となっている。しかし、ScalaのようにもともとJVMをターゲットとして開発された言語と異なり、JRubyのような既存言語をJVM対応とするための課題は多かった。ナッター氏には、それは当初は不可能に思えたという。

　「（JVMの文字列オブジェクトの扱いと異なる）バイナリの文字列、POSIX対応、ネイティブライブラリ、高速な正規表現ライブラリ、libcのI/Oセマンティクス、こうしたものを実装しつつ、ネイティブスレッドに対応させ、さらにCベースのRubyよりも高速に動作させる……、しかも、それを言語仕様もAPI仕様もなしにやる。これはまったく不可能なことに思えましたね」（ナッター氏）。

　実現不可能に思えたものの、Rubyの美しさや楽しさ、Rubyコミュニティが生み出すGems、Rake、RSpec、Railsといった独特のツール群があったことなどから、ナッター氏は「Rubyが好きだったし、それに難しい問題ほど解くのが楽しいもの」とJRubyの開発に取り組んだという。

irb、Gems、Railsが動くまで

　JRubyが現在のようなCRubyとの互換性を持つにいたるまで、いくつかステップがあった。

　まず、インタラクティブな実行環境（REPL）の「irb」の実現のためにevalや基本的なバインディング、変数などで、Rubyの挙動を実現。これは実行と修正を繰り返すシンプルなステップだったという。次に取り組んだreadlineのサポートも、JVM上の複数のライブラリから選択して、それを流用するだけですんだ。

　Rubyのライブラリパッケージ管理ツール、RubyGems対応とするには、もう少し手間がかかったという。まず、定義ファイルで使われるYAML形式のファイルをパースするJVM上のライブラリが部分的なものしかない。パッケージの圧縮に使われるzlibも、RubyはCで書かれたライブラリを使っていて、こうしたライブラリもJRubyでは実装する必要があったという。結果、「今やJRubyはRubyよりもYAMLとの互換性が高い」とナッター氏は笑う。

　Ruby on RailsはRuby処理系の試金石だ。「Railsが動けば本物、もし動かないなら、それはRuby実装とは言えない」（ナッター氏）。今やRailsはRubyを使ったアプリケーションとして最大規模、しかもRubyの機能をもっとも深い部分まで使っていると言われている。これが動けば大きなマイルストーンとなる。

　Rails対応で問題となったのは、ORマッパのActiveRecordだったという。Rubyによる実装はJRubyには複雑すぎ、かといってJDBCは低レベルすぎた。そこでJDBCのAPI上にラッパーを実装することで対応。JRuby on Railsが動くようになったという。「2006年5月に初めてRailsがJRubyで動いた時には感動しましたね。JavaOne2006のデモにも間に合って、それでサンに職を得たわけです（笑）」（ナッター氏）。2006年9月、サン・マイクロシステムズはJRubyコア開発者のナッター氏とトーマス・エネボー氏を雇い入れた。このとき実は、事前にサンでWeb技術担当責任者を務めるティム・ブレイ氏から、「JavaOneまでにRailsが動けば、何かいいことがあるかもね」とほのめかされていた、と明かす。

文字列オブジェクトや正規表現も実装、移植

　当初、JRubyでは文字列オブジェクトをJavaのStringBufferを使って実装していたが、これも問題となった。セマンティクスが違うし、Rubyの文字列オブジェクトはバイナリにも使われるという特徴があったという。このため、Javaのbyte配列を使い、コピー・オン・ライトの特徴を持った文字列オブジェクトを独自に実装した。この変更によって、さらに多くの“不可能な課題”に遭遇することとなったが、「それが本家Rubyと同等になれる唯一の方法だった」とナッター氏は振り返る。

　高速な正規表現ライブラリは、テキスト処理を得意とするRuby処理系のキモの1つだ。JRubyでは、ここでも苦労したという。JRubyで当初使っていたjava.util.regexは、大きなデータではエラーとなって使えず、それに代えて使っていたJRegexはchar配列ベースだったため、これも使えなかった。

　次の“不可能な課題”は正規表現ライブラリの独自実装だった。ただ、このときには魔法のようなことが起こったのだという。CRubyでも使われている「鬼車」というライブラリをJVM上に移植するとメーリングリストで名乗り出た人がいて、実際、たった1人で1カ月で移植作業を終えたという。移植したMarcin Mielzynski氏のことを最初ナッター氏は気にしていなかったという。6万5000行にもなる、C言語特有のテクニックが多用されたソースコードを1人で移植できると思えなかったからで、ナッター氏は「まったく驚異的な馬力だった」と振り返る。

　 Mielzynski氏が鬼車から移植したこの正規表現ライブラリは、JVM上で動くものの中でも最高のものだとナッター氏は言う。そして「Jythonもバイナリ文字列を実装したら、これを使うと思います」と、JRubyがJavaプラットフォームに与えつつある影響を指摘する。

POSIXという“不可能な課題”も克服

　POSIX対応も“不可能な課題”と思えた。JVMからは「chmod、symlink、fstat」といったシステム関連のAPIは手が出せない。このため、JNA（Java Native Access）を使ってPOSIX対応とするプロジェクトを開始。その後、マルチプラットフォーム対応としたほか、FFI（Foreign Function Interface）ライブラリベースに移行。JRubyの中からCで書かれたライブラリを呼べるようになったという。ナッター氏はさらにクイックソートのコード例を示しながら、JRuby側のブロック（ソート用の比較関数）をCの関数（qsort）のコールバックとして使うことができることもデモしてみせた。ただし、JRubyからFFIを使ったCプログラムの利用は一般的に推奨しているわけではなく、既存ライブラリの利用などに限定すべきだとしている。

　「この中でOpenJDKにパッチを受け入れてもらったことがある人？」。会場に向かってそう問いかけたナッター氏は、誇らしげに「オレあるもんね」と笑う。I/O周りでlibcと同じセマンティクスを持つライブラリを実装したナッター氏は「libcのコードを追いかけたことある人？ 私はひと夏やりましたが、お勧めしませんね」とも言って会場の笑いを誘っていた。

Java 7で動的言語対応強化

　文字列、正規表現、I/O関連といった実装でパフォーマンスや互換性は向上したが、現在さらにパフォーマンスの改善に取り組んでいるという。Rubyでは明示的な型がなくクラスも動的に生成されるが、それをJavaのクラスにコンパイルするという難題に取り組み、さらに今は「Da Vinci Machine」と名付けられたプロジェクトが進行中だという。

　Da Vinci Machineプロジェクトでは、JVM自体に変更を加え、特にJRubyをはじめとする動的言語サポートを強化するための新しい仕様でJSR 292として議論が続いている。この新仕様では、実行時にクラスの生成やメソッドの探索を行うRubyのような動的言語のために、「Invokedynamic」と呼ぶ新たなバイトコードなどを定義する。これらの新仕様はJava 7に含まれることになりそうだ。つまり、今やJVMはJava言語のためのVMという枠組みを超えて進化しつつあるということで、JRubyも影響を与えているということだ。ナッター氏は、OpenJDKがコミュニティによって開発が方向付けられるものであることを改めて指摘。「JVMで不可能なことなどない。やりたいことがあれば実装すればいい」と話した。