Servlet Garden

2月16日にJRuby 1.1 RC2がリリースされましたが、このときにメインコミッタのお一人であるCharles O. Nutter氏がブログで現在のJRubyと今後のJRubyについて熱く語っていました。このエントリを勝手に和訳してみました。原文はJRuby RC2 Released; What’s Next?です。

JRuby RC2がリリース；次は何が起こるか？

今日、Tom(訳注: JRubyプロジェクトの代表、Thomas Enebo氏)がJRuby 1.1 RC2をリリースしました。このリリースではパフォーマンスをかなり改善し、Rubyとの互換性の問題を修正したので、驚くほどいいものとなっています。Tomが行ったJRuby 1.1 RC2のアナウンスがここにあります。

このバージョンで何をしたのかをすこし説明しようと思います:

• ・RC1よりもさらにパフォーマンスを改善しました。手短に言うと、ちょっとした数値演算的なベンチマークならRuby 1.9にかなり近いか、超えているものもありますが、ほとんどのベンチマークでは互角です。つまり、比較対象として主にRuby 1.9を使い始めたわけです。
• ・通常のRC開発行程とちょっと違って、RC1以降、260ものバグを修正しました。そうです。RC開発のルールからちょっと外れてはいますが、たったの１ヶ月でこれだけたくさんのバグを修正できたとしたら、だれも我々がやっていることを非難したりはしないでしょう。現在存在している他のRubyの実装と比べてもJRubyが一番Ruby 1.8.6と互換性が高いのは明らかです。
• ・このバージョンではかなりメモリの使い方も改善して、JRubyインスタンスが使用する全体のメモリ使用量を削減しました。さらに注目に値するのはおそらく、JITでコンパイルされたコード(JVMのバイトコードにコンパイルされるRubyのコードが使用する、いわゆる”Perm Gen”空間)のメモリ使用コストも削減できていることでしょう。ざっと見積もると、 JRubyのN個のインスタンスが動いているアプリケーションはおよそN分の1を使うことになりますが、Perm Gen空間も同様です。

つまり、今回のリリースには二つ、ほんとうに大きな意味があります。1つ目は、大きなアプリケーションを作ろうとしたときに、できるだけ速く、できるだけスケールするようにしたい場合のRubyの実装としてJRubyが有力になったことです。私たちが互換性、安定性、パフォーマンス向上のために多大な時間をつぎ込んできた成果が出始めています。2つ目として、私から皆さんにこう伝えたいと思います：

もし、まだJRubyを使ったことがなかったら、今こそ使い始める時期です。

未解決の問題も落ち着き始めています。JRubyは満足に使ってもらえるようになったと同時に悪口も言われるようになってきましたが、利用者がJRubyをどのようなたぐいのアプリケーションにも投入できるようなよりよいレベルにもっていくために、私たちは悪評も受け入れたいと思います。私たちはJRubyが利用者の役に立つようにしたいと思っています。

そして、このような背景から、”次は何か？”というこのブログのエントリを書くにいたりました。私たちはここからどこへ向かおうとしているのでしょうか？

1.1 finalをリリースするまでに、さらなる機能向上とバグフィックスのための時間が若干残されています。時間は限られているので、私たちはJRubyをより完全なものするのに必要なところに時間を費やしたいと考えています。ですから、皆さんにお願いしたいのです。バグを見つけて、レポートしてください。パフォーマンスのボトルネックを教えてください。もし可能なら、問題をフィックスし、パッチを作ってバグレポートを解決する手助けをしてください。

ただし、一風変わったことにも取り組もうとしています。JRubyは他のどのRubyの実装にもない機能を持っていますが、今回採用したその機能とは次のようなものです：

ひとつのJVMのプロセスの中で、JRubyがいくつでもアプリケーションをホストするような使い方で、並行的にアプリケーションを利用しようとする多数のユーザがいてもスケールするような使い方を可能にする。

この機能はRailsばかりではなく。Merbのような最近、急激に人気がでてきたwebフレームワークにも等しく適用できるものです。さらに、GlassFish gemのような新しいプロジェクトのおかげでRubyによるwebアプリケーションを簡単に、スケーラブルに、苦労せずにホスティングする方向へと向かっています。そうはいっても、JRubyプロジェクトのリソースはとても限られています。フルタイムのコミッタは二人で、就業時間内、就業時間外に開発に関われるコミッタが一握りほどいて、自分の時間をつぎ込んで助けてくれているだけです。Webアプリケーションをホスティングする際にJRubyを利用者の要求に見合うように改善するには、利用者のユースケースや経験、インプットが必要になってきます。私たちはJRubyでもっともスケーラブルでもっともパフォーマンスのよいRubyによるwebアプリケーションのプラットフォームを作ろうとしています。しかも、純粋にOSSスタイルでそれをやろうとしています。秘密もなければ、隠された議事もありません。利用者のためのwebアプリケーションプラットフォームになるはずです。そうでなけでば、私たちの努力は無駄になってしまいます。どうあるべきでしょうか？

GlassFish gemは最初の一歩です。GlassFish gemはJavaプラットフォームのもっともよい機能のいくつかを利用してすばらしさをかもしだしています。つまり：高速非同期IO、ネイティブスレッド、あらかじめ組み込まれている管理とモニタリングの機能、アプリケーションの名名空間を独立させること(そうなんです。やっかいなクラスローダでさえも良いところがあるのです)、といった機能によりRubyによるwebアプリケーションをデプロイするのもスケールするのもボタンをクリックするだけでできてしまうようなものにしています。たったひとつのコマンドで利用者のアプリケーションは製品レベルにまでなります。管理のためのMongrelのパッケージもいらなければ、アプリケーションをモニタするクラスタもいりません。しかも、利用者の開発スピードを落としてしまうようなWARファイルのしきたりもありません。”glassfish_rails myapp”というコマンドを実行するだけで、全ての作業が終わります；本当に、ワン・ステップのデプロイです。残念なことに、GlassFish gemは今のところ、Railsしかサポートしていません。私たちはGlassFish gemを安定したパフォーマンスの良いRails用サーバにするだけではなく、どのRubyによるweb開発用途にも適用できるようなより一般的な”mod_ruby”のようなものにしたいと思っています。今時のちょうどよいプラットフォームになるはずです。私たちは次のレベルのものとして取り入れられる段階にきています。ですが、現時点ではまだ、利用者に使ってもらって何が必要なのか教えてもらう必要があります。

通常、JRubyのパフォーマンスはRuby 1.8.6よりも上です。しかも、Ruby 1.9を超えていることもよくあります。

今の段階で、”Ruby”であるという定義を考慮すると、JRubyは”もっとも高速なRubyの実装”というタイトルを手にできるはずだと自信をもって言えます。もし、そのタイトルにふさわしいところまできていないとしても、すぐにそうなるはずです。ほとんどのベンチマークでRuby 1.8.6に相当するか超えている、また、Ruby 1.9に近づいているか超えている数値を見て私たちはとても満足しています。私がこれまでに学んできたのはパフォーマンスは重要だが、パフォーマンスだけがRuby開発者の関心を引きつけているのではないということです。特に、Rubyとは関係のない、IOやデータベースアクセスのボトルネックに制約されることが多いwebアプリケーション開発者がそうです。しかし、これは私が利用者のごく一部の人たちを話をして収集できたわずかの知識に基づいています。私たちがやるべきことはもっとあるのでしょうか？このままパフォーマンス向上に固執し続けるべきか、あるいは他に注目するべきところがあるでしょうか？JRubyのパフォーマンスが十分ではないと感じるケースがあるでしょうか？

現時点では、JRubyのパフォーマンス向上に対して今後どう取り組むかについての方針は定まっていません。これまでにリリースしてきたJRubyはとてもよく動いていて、パフォーマンスが問題になるアプリケーションでは”他よりも十分いい”という理由ですでに使われています。ボトルネックがあることは承知ですが、問題が現れ次第解決するようにしているので、ボトルネックの問題は減少してきています。ボトルネック以外のところでは、何か改善する余地があるでしょうか？利用者がそう主張するなら私たちは取り組みます。JRubyのパフォーマンスをさらに向上させるような、”experimetal”な機能が実装されたプロトタイプがすでにありますが、まだテストされてはいません。もちろん、常にトレードオフとなる問題は存在します。おそらく利用者はかなりのメモリ消費を覚悟しないといけないでしょう。あるいは、自動的にパフォーマンスが低下するのを承知のうえでRubyのedge-case(境界ぎりぎりの)機能を無効にするしかないかもしれません。そして、今後もっともめざましく性能向上に貢献するであろうと思われるのはダイナミックなメソッド呼び出し(訳注：参照)(できればJDK 7 で導入されることを期待しています)のサポートと他の機能をホスト(OpenJDKの”Multi-language VM”サブプロジェクト(訳注：the Da Vinchi Machine Project)でできるようになるとほぼ確信していますが)にかかっています。しかし、パフォーマンスの向上が要求されるようなところでは、すでにそのようなことが起きつつあります。また、他のJVM上で動く言語全てにとっても恩恵があるような方法で、起きつつあるといってもいいでしょう。私は利用者からパフォーマンス向上の優先順位を決めてほしいと思っていますし、また、利用者のニーズという点からどのような方向に進めばいいかも教えてほしいと思っています。

JRubyはJavaのライブラリ全てとJVMマジックの全てを利用できる環境で、すばらしい言語パフォーマンスと、”より親しみやすい”顔によってJVMとJavaプラットフォームをいっそう魅力的にしています。

私はこの領域は今、具体化しはじめたにすぎないと考えています。というのは、JRubyは JVMの上で動作するようになっているため、単一のプラットフォーム上に結集しているこれまでで最良のJITテクノロジー、最良のGCテクノロジー、最良のライブラリ群を使えるようになっています。Javaに何を望んでいるか言ってください。Java言語はとても好きかもしれませんし、とても嫌っているかもしれません。ただ、JVMは単にJavaだけのものではなくなるだろうことは明らかになってきています。私が知る限りでは、JVMが想定していなかったにも関わらず、実務的な製品レベルのフレームワークを動かすのに使われることになった非JVM言語のJVMへのポーティングはJRubyだけです。私たちはきちんとした仕様すらないたったひとつの実装だけがあった言語(MatzのRuby)とその重要なアプリケーションフレームワーク(Rails)に取り組んで、少なくてもオリジナルと同等であり、かつ様々な面で超えているようなホスティングと配備を行えるようにしてきました。このようなケースとしては最初のひとつのはずです‥‥Jythonの開発者たちには今ではDjangoがあるので、JythonがPythonによるwebアプリケーション開発のための実際に使えるプラットフォームになるのは時間の問題でしょう。そして、Railsに啓発されたにも関わらず、Railsの醜いところが無いMerbというフレームワークがすでに使われだしていますが、これもJRuby上では完璧に動作します。加えて、JVMから上の部分は全てがオープン・ソースです。きっと利用者の未来を形作ってくれるはずです。

おそらく、JRubyの次のフェースではJavaプラットフォームの残りの部分と統合してよりしっかりとした、きれいな実装になると私は考えています。すでに、利用者はJavaで作られているライブラリをRubyで記述されているコードであるかのように呼び出すことができるようになっています。しかし、現状のものは私たちが考えているほどシームレスにはなっていません。たとえば、正しいターゲット・メソッドや強制変換する適当な型の選択といった問題は、静的な型システムのコードを呼び出すときにどの動的な言語でも直面する問題です。Groovyには明示的なキャスティングによる型変換や強制的な方変換、あるいは境界における限定的な静的な型宣言といったまねるべき様々な機能があります。マイクロソフトが作っているDLRのようなフレームワークもにたようなアプローチを行っています。というのは彼らは最初から”ファーストクラス”の新しい言語を作るための設計を行ってきたからです。私たちはJRubyで発生する問題を解決するのと同時にJVM上で動かす全ての言語でも起こるであろう同類の問題を解決する方法を見つけようとしています。しかし、Rubyユーザからあがってくる要求もまたかなりあります。JVMとJavaのライブラリ全てがユーザのために動くようにするには私たちは何をすればいいでしょうか？

私はこれら全てに関係する明らかに本質的なものがあると考えています。JRubyはOSSプロジェクトで、主にコミュニティの貢献によって運営されています(8人のうち5人のコミッタは自分の時間を使って働いてくれていますし、数百もの人たちがパッチを送ってくれたりバグレポートをして貢献してくれています)。また、OSSプラットフォーム(OpenJDKだけではなく、Javaの生態系全体に染み渡っているフリーソフトウェアやオープンソースの文化も含めて)に基づいていますし、OSSのフレームワークやライブラリ(Rails, MerbをはじめとするRubyの世界のアプリケーション)をホスティングしています。利用者と利用者のアプリケーションがなければこれら全ては存在価値がありません。私たちはこのプラットフォームがユーザのために動くようにするために努力を注ぎ込むつもりです。あなたは私たちを手伝ってくれますか？