日本語JRuby

JRubyKaigi 2011、RubyKaigi 2011 で喋ってきました。

2011-07-30T00:45:00.000-05:00

凱旋（？）

2011年7月14日、Rubyで飯を食うようになって初めて帰国しました。タイトルにある通り、JRuby会議とRuby会議で喋る為です。東京への出張は2004年に一回ありましたけど、その時は別の会社で、しかもその会社のCEOの通訳みたいな感じで詰まる所「おまけ」だったので、今回は少し箔がついた感じの帰国でした。

帰国の便

余談ですが、今回の帰国便はデトロイト発の羽田行きでした。ボーイング777型機で、私の座った席には電源が付いていて、ラップトップの電池の残量を気にする事なく道中を楽しむ事が出来ました。惜しむらくはWiFiがなかったのでネットで~~遊べなかった~~調べものが出来なかった事です。乗機率がかなり酷くて、乗っていた人全員が最低三席を占拠して横になって眠れるくらいでした。東京への便が（昨今の事情で）全てそうなのかと思ったのですが、成田への便は結構混んでいたという同僚の話でした。

JRuby会議 2011

今回のJRuby会議は、Ruby会議の前夜祭といった雰囲気があって、50人くらいの方が参加されました。私は、トマス・エネボ氏のキーノートのスライドを翻訳して、弊社エンジンヤード社のAppCloudでJRubyを使ってRailsアプリケーションを動かす方法を紹介しました。

AppCloudではサーバのインスタンスを立ち上げる時必要なスクリプトをS3から取ってくるのですが、私のデモの時はどういう訳かこれに失敗してちょっとあたふたしました。結局もう一つの環境を作り直して何とかデモを終えたのですが、やはりインパクトが弱くなってしまった感は否めません。会議が終わった後、S3の問題も修正できたのですが参加して下さった皆さんにそのことが伝わったかどうかは疑わしいです。非常に残念。

生まれて初めての地震

因みにJRuby会議の最中に地震がありました。会場だった青山の日本オラクルのビルは耐震構造がしっかりしていて建物全体が数秒間ユラユラしただけで事無きを得ました。地震を体験したのは実はこれが生まれて初めてでした。地震国日本に生まれたというのに。

Ruby会議 2011

私は「Rubyを持て、世界に出よう」という演題で話しました。周知の通り、今年でRuby会議は終わりです。私にとっては初めてのRuby会議だったのですが、私の講演は、今の日本のRubyist達が次に目指すべきあり方の一つを示す事が出来たのではないかと思います。（講演についてのもう少し詳しい話は後日書きます。）

初めて会う人々

上記の通り、Rubyを使うようになって初めての帰国だったので日本の著名なRubyistの方々多数に初めてお会いする機会に恵まれました。とは言うものの、普段からTwitterなどでやりとりをしている所為で初対面という感じがしないのが不思議といえば不思議でした。

海の向こうにいる家族ともスカイプでほぼ毎日顔を合わせる事が出来たし、「凄い時代になったものだ」と感心しました。

JRuby 1.6.0 がリリースされました。

2011-03-15T22:12:00.001-05:00

原文

The JRuby community is pleased to announce the release of JRuby 1.6.0.

ホームページ: http://www.jruby.org/
ダウンロード: http://www.jruby.org/download

JRuby 1.6.0 が正規にリリースされました。

JRuby 1.6.0 は過去最大のJRubyリリースです。
このリリースは、ユーザから報告のあった数百の不具合を直し、またRuby 1.9.2との高い互換性を実現しています。
またウィンドウズ上で継続的インテグレーションを行い、これをサポートするプラットフォームに加えました。
ウィンドウズでRubyを体験するのにJRuby 1.6は最適の方法と言えるでしょう。
このリリースではRubyのAPIに基づいたC拡張への対応を試験的に取り入れています。
更に、今までの主なリリースと同様、ユーザの声に耳を傾け、安定性とパフォーマンスの向上を実現しています。

今後一二ヶ月の間は1.6.0へのフィードバックを受けて1.6.1, 1.6.2等、細かくリリースを行う予定です。
1.6.0を是非使ってみて、報告をして下さい。

主な特長

Ruby 1.9.2言語とAPI互換性の実現
- Encoding::Converterとripperは未対応
Rubyメソッド呼び出しのパフォーマンス向上
組み込みのプロファイラ(–profile, –profile.graph)
RSpecを配布ファイルから外しました
C拡張のサポート（試験的）
MavenアーティファクトをRuby gemとして扱える（プレビュー）
Windowsプラットフォームへの対応
1.9標準ライブラリをjruby-complete.jarに追加
組み込みAPIの更なる改善
2000のコミットと270を超える不具合の解消

JRubyの一年を振り返って

2010-12-30T10:54:00.001-06:00

原文: チャールズ＝オリバー＝ナター

皆さん、こんにちは。

2010年ももうすぐ終わり。この一年を振り返ってJRubyにとって重要な出来事や人々を見て行きましょう。
2010年は、JRubyにとって素晴らしい年でした。様々なプロジェクトに採用され、また、第一級のRuby言語実装としても第一級のJVM言語としても人々に認知され、更にはJRuby自体も多いに進化した一年でした。早速みていきましょう。

JRubyを巡る人々

JRubyの大事な使命の一つは、より多くの人にRubyというプログラム言語を届ける事です。
その為に、世界中を飛び回ったり、ブログ記事を書いたり、援助者を募り、パッチを取り込んだり、ユーザのサポートに努めてきました。2010年特に貢献のあった方々を挙げて行きましょう。

浅里洋嗣氏

浅里氏は2009年を通じて貢献の実績があり、メーリングリストやIRCチャンネルでも、JRubyを使ったアプリケーションを動かす際に起こる様々な問題点を解決する手助けをする常連でした。
2010年初頭にEngine Yard社がJRubyサポートエンジニアの募集を行ったとき、浅里氏はこの仕事に適任だったと言えます。
彼はフルタイムで雇用され、JRubyコミッタに迎え入れられました。
今年の終わりにはカンファレンスなどでも講演をする事にもなりました。

Nahi（中村浩士）氏

NahiさんはRuby（CRuby、つまりMRI）のコアチームのメンバーとして、OpenSSLに代表される暗号、I/O等、システムレベルを専門に貢献されてきました。
Rubyの標準ライブラリを覗いてみると、彼の名前が其処彼処に見えるでしょう。
2010年の半ば頃、NahiさんはJRubyでopensslライブラリを使う為のjruby-opensslの手伝いを買って出てくれました。
NahiさんはOla Bini氏のOpenSSLの移植という大作を基に、CRubyバージョンとほぼ100％互換性のあるライブラリを造り上げてくれました。 opensslが如何に低水準の事を取り扱うのかを考えてみると、これは正に驚くべき偉業です。
この後、Nahiさんは他の厄介なサブシステムの手伝いをされ、またJRubyの大きな支援者として活躍されています。

David Calavera氏

Calavera氏もまた2009年以来の貢献者で、2010年も引き続き多くの貢献をしてくれました。
彼の貢献の多くはRuby 1.9仕様の充実や、ユーザから報告のあった不具合の修正、そしてメーリングリストとIRCでのユーザサポートです。
加えてDavidは素晴らしいTrinidad gem（Tomcatを組み込んだ、JRubyによるRails/Rackアプリケーションコンテナサーバ）を書きました。Trinidadは急速に世界中のJRubyユーザの間に浸透しています。

Joe O'Brien氏

O'Brien氏はオハイオ州に本社を置くRubyとRailsのコンサルタンティング会社EdgeCaseの創始者の一人です。
大企業関係のプロジェクトに経験が多く、大企業の新しいテクノロジーを取り入れる傾向の薄さを知るO'Brien氏はJRubyの偉大な支持者の一人です。
2010年、O'Brien氏は彼自身のプロジェクトである"eRubyConf"を一年休んで、始めての単体開催となるJRubyConfの実施を現実のものとする手伝いをして下さいました。
このような機会に恵まれてJRubyをより多くの人に知ってもらう事が出来るのはとても素晴らしい事です。
O'Brien氏のお陰でJRubyConfが実に素晴らしいイベントであった事は言うまでもありません。

Engine Yard社

Engine Yard社の絶え間ないJRubyへのサポートにも感謝致します。
Engine Yard社はJRubyのコアメンバー（筆者、Tom Enebo氏、Nick Sieger氏、浅里氏）の新しい「家」となり、またマーケティング、トラベル、技術的そして精神的な面からも支えて頂いています。

JRubyのサポートとプロフェッショナルサービスは今年開始されました。
xCloudではJRubyは既にサポートされていますし、
AppCloudでもベータプログラムによりJRubyを試用することが可能です。
Engine Yard社で働く事は素晴らしく、会社の収益に貢献出来るのは尚の事素晴らしいです。

ユーザと貢献者の皆さん

勿論、ユーザと貢献者無しにJRubyを語る事は出来ません。
今年に入ってJRubyを使っているというサイトの報告を何十も貰いましたし、Ruby gemの作者達もJRubyを意識してテストやサポートを始めました。
Rails作者であるDavid Heinemeier Hansson氏によれば、Rails 3.0は（C Rubyに加えて）JRubyでも動くように設計されています。
Twitterにおいても毎日JRubyについてのツイートが何百もあり、JRubyに関するメーリングリストも今年に入って14000件の投稿があり、何十もの世界中のカンファレンスを通じて、何千というユーザや将来のユーザたり得る人々に出会う事が出来ました。
2010年をJRubyにとって最高の年にして下さったユーザ、貢献者、そしてRubyライブラリとアプリケーションの作者の皆さんに感謝の意を表します。

JRubyの進化

勿論JRuby自体にも多くの動きがありました。
今年に入ってのコミットの数は（マスターブランチで）2300を超え、567に上るバグレポートを解決し（とは言うものの、更に868件の追加がありましたので我々の仕事はまだまだ続きます）、八つ（1.4.1, 1.5.0-1.5.6）のJRubyリリースを行い、 "RubySpec"のテスト結果を 1.8互換モードで99%、1.9互換モードで90%を越えるまでに改善しました。
2011年初めに予定されているJRuby 1.6のリリースで公式な発表となります。
主立った改善点を見ていきましょう。

Ruby 1.9との互換

今年八月のRuby 1.9.2リリースを受けて、JRubyでもこの1.9系統のRubyとの互換性を最優先事項にしました。Marcin Mielzynski氏、Ola Bini氏、David Calavera氏、そして浅里氏らの貢献により断片的なサポートの素地は既に在りましたが、本格的な作業はRubyのコアチームが最終的な1.9.2をリリースするまでは保留にしておきました。
夏の1.9.2リリースから、何百ものコミットがあり、また多数の不具合を修正しました。その結果JRubyは1.9互換モードでRubySpecの90%、そしてRailsの一部であるActiveSupportのテストの95%をパスするまでになりました。
JRubyはこの先数ヶ月で正式に1.9互換となる見込みです。

Windowsのサポート

私達はJRubyが「どこにでもRuby」を実現する最善の手段であると信じています。
このために2010年にはWindows上でJRubyをより良く動かす為の手段を講じてきました。
様々なJVMについて言える事ですが、JRubyのコアである仮想マシンは既に堅牢なものです。
ところがRubyの機能という物はシステムレベルでの機能を含んでおり、あらゆるOSプラットフォームでのサポートを一様に実現するのは難しいものがあります。
機能を苦労して実装しても、RubyプログラマはWindowsではどうしても動かなかったりビルド出来ないC拡張に出くわす事がしばしばあります。
最新のRubyのビルドを手にする事すらままならない可能性もあります。
私達は、鍵となるC拡張をJava（またはRubyとJavaの統合）に移植する事によってWindowsを使う人たちが初めの一歩を踏み出しやすくする為の努力を続けています。
そしてJRubyはWindowsでRubyを使う最も簡単な方法と考えられる事もあります。
2011年もこの方面での作業は続きます。

Rails 3のテスト

JRubyはCRuby以外のRuby言語実装の中では（2006年以来）最も長く「Railsを走らせて」いますが、この間Rails自体のテストを100%通す事は実は出来ていませんでした。
2010年、浅里氏、Calavera氏、Nick Sieger氏、Tom Enebo氏らの貢献により事態は一変し、JRubyはRailsのテストを100%通すようになりました。
更に素晴らしいのは、JRubyは多くのRuby言語実装のうち、継続的インテグレーションをRailsに対して毎日行っている唯一のものであるという点です。
RailsをJRubyで動かそうとするユーザが快適な環境を提供する努力を我々は怠りません。

C拡張のサポート

2010年のRuby Summer of Codeのプロジェクトの一つとして、Wayne Meissner氏が造り上げたプロトタイプを基にTim Felgentreff氏はJRubyにおけるC拡張のサポートを実現しました。
予想を遙かに超えた、実に素晴らしい努力の賜物で、（私は絶対に不可能だと考えていたのですが、Felgentreff氏とMeissner氏は私が間違っていた事を証明してくれました）よく見かける多くのC拡張は「一通り動く」ようになりました。
勿論、（多くのOSプラットフォームで、安定して、また並行して動かすという観点から）Javaでそれに相当する物や移植した物があればそちらを薦める事に変わりはありませんが、JRubyへの移行を楽にする短期的な手段としては問題ないでしょう。
これも近いうちにリリースされるでしょう。

性能

言語実装としてのJRubyも見えない所で進化しています。
Subbu Sastry氏とEnebo氏は、新しいIR（中間表現）と、それを利用してRubyコードを最適化するコンパイラの実装を進めていて、既におおよその形が出来上がっています。2011年にはこれを基にしてJRubyのパフォーマンスの更なる向上が期待出来そうです。
私もJRubyの動的最適化に努めています。インタープリタをプロファイリングする事で動的な呼び出しを取り除いたり、Rubyメソッドの呼び出し毎に起こるオーバーヘッドを取り除いたり、といった具合です。
暫定的なテストによると、この「dynopts」オプションを使うとJavaそのもののパフォーマンスに匹敵するような結果を得る事も可能である事が分ります。同時に、（Ruby言語実装の中にあって既に最善のものの一つであるとは言え）JRubyのパフォーマンスがこれ以上ないくらい最適化されているのではないということを実感する一瞬でもあります。
2011年初頭にはこの方面での作業が続きます。

周辺のソフトウェア

JRubyのコアチームがJRubyの改善に努力する一方、多くの方々がJRubyに関わるライブラリ、サーバなどを進化させています。
これらのうち幾つかを見ていきましょう。

win32ole

JRubyのバグトラッカーで解決されずにいた物のうちで最も古い物の一つが「win32ole」ライブラリの問題でした。
win32oleライブラリは、Windows上でOLEへのクリーンなアクセスを可能にします。
これにより、ネーティブのコードを書かずにマイクロソフトOfficeやインターネットエクスプローラ、その他のWindows固有のアプリケーションやライブラリを呼び出すことが出来るようになります。
これはEngine Yard社のAudentes Technology社とのプロフェッショナルサービス契約の一環として行われました。
JavaとCOMのブリッジであるJacobライブラリを大幅に改善し、それをガッチリ統合して、win32oleサポートを実現しました。
Enebo氏の数週間に渡る並々ならぬ努力の結果、Rubyで使うwin32oleライブラリとしては最も堅牢でマルチスレッドで利用できるものが生まれました。

ActiveRecord JDBC

Rails 3.0をサポートする為には、JRuby自体の修正に加えてデータベース接続の為のアダプターも数々のデータベースのいずれにおいてもテストを100%パスする物である必要がありました。
「ActiveRecord-JDBC」の強力な推進者であるSieger氏は、AR-JDBC 1.0を今年リリースしてそれを実現しました。
この仕事は続いており、Javaで書かれたデータベースであるDerby（JavaDB）、Hypersonic SQL、H2をもサポートしています。
これによりJRubyは、多種多様なプラットフォームでRailsアプリケーションを動かすのに最も手軽な手段になったと言えるでしょう。
JRubyのユーザの中には実に変わったデータベースとOS環境の人々が居るのがその証左です。

デプロイメントのオプション

以下に挙げる方々の貢献でJRubyでサーバアプリケーションを書くのが一層簡単になりました。

Nick Sieger氏はwarblerとjruby-rackライブラリのバージョン1.0を今年リリースしました。
Warblerにより、Rackに準拠したアプリケーション（Railsを含む）をWAR（Web ARchive）ファイルとしてJavaウェブコンテナにデプロイ出来ます。
WinStoneというサーバの搭載により、実行可能なウェブサーバをWarblerだけで造り上げることも可能になりました。
さらにSieger氏は、"warble"コマンドだけで、Rubyのアプリケーションを1つの実行可能JAR形式にまとめられるようにしてくれました。凄いです。
Railsを大企業向けに浸透させる事が出来る可能性を持ったデプロイメントの選択肢はWarberを置いて他にありません。
その意味でバージョン1.0は記念すべきマイルストーンです。
Warblerと表裏一体を成すjruby-rackは、rack仕様のインターフェイスとJava servlet APIの互換を実現し、servletに拠ったRubyアプリケーションの中核を成す物です。

コマンドラインを使う人々にはTrindadもデビューしました。David Calavera氏はjruby-rackを使ってTomcatを組み込んだツールを作りました。これによりJRubyユーザは高速で並行処理に長けたサーバをたったの7MBのgemで手にする事が出来るようになりました。
これと似た物として、浅里氏がメンテナを務めるGlassFish gemが挙げられます。
TomcatのかわりにOracleのGlassFishサーバの中心を成すGrizzlyを組み込んでいます。
この二つのgemは紛れもなくRailsのアプリケーションを世に出す最も簡単な方法と言えます。

JBossを好む向きには、Bob McWhirter氏とRedHatの彼のチームにより産み出されたTorqueBoxがあります。
これにはJavaのアプリケーションサーバの中で最も素晴らしいJRubyが実現されています。
TorqueBoxはjruby-rackによってJRubyアプリケーションをデプロイしていますが、それに加えてJava EEサブシステムの為のRubyで書かれたAPIやプラグイン、バッチ処理、ウェブサービス、その他諸々を提供しています。
「Java EEの為のRuby」として最善のオプションと言えます。
既にJBossやJava EEを使っていてRubyを弄ってみたいと言う人（またそうでなくとも色々なサービスが初めから備わっている方が良いという人）にはこれをお勧めします。

最後にJohn Woodell氏とRyan Brown氏が続けているGoogle AppEngine for JavaにおけるJRubyサポートが挙げられます。
GAE/Jは小さなサービスを手軽に実現出来るツールで、JRubyで書かれたアプリケーションを動かす場所として成果を挙げています。
両氏はJRuby-on-GAEを通じてJRubyユーザをサポートしており、JRubyユーザはデプロイメント手段の選択の幅が広がる事を歓迎しています。

開発ツールと管理ツール

JRubyでは標準のJVM/JDKツールと管理インターフェイスを使う事が出来ますが、このようなツールはRubyを普段使うプログラマにとっては馴染みが薄く、時に仰々しい物です。
このため、「--profile」というフラグでRubyコードだけを考慮する計測化プロファイラーを動かす事が出来ます。（コールグラフのサポートも近く追加される見込みです。）
ruby-debug gemのメンテナ諸氏との連携によりJRubyをバックエンドとするデバッガが正式にリリースされ、ruby-debug gemは綺麗にインストールされるようになりました。
RubyGemsにも起動時間短縮の為のパッチを提供しましたし、JRubyが使うスクリプトも（mkristian氏の多大なる協力の元）修正してmavenライブラリをRuby gemとしてインストールしたり依存の解消を行ったり出来るようになりました。
AntとRakeの双方向統合も今年リリースされました。
これによりAntで書かれたビルドスクリプトをRakefileで書き換えたり二つをシームレスに組み合わせる事が至極簡単になりました。

Java純正のNokogiri

2009年頃、RubyでXMLを扱うライブラリの定番としてNokogiriが定着し始めました。
クリーンで高速なこのライブラリは人気のあるlibxmlライブラリを使っています。
JRubyユーザもこのライブラリの恩恵にあやかる事が出来ましたが、それは速度にC拡張に劣るFFIを使った物を使わざるを得ませんでした。
Ruby Summer of Codeのプロジェクトの一つとしてSergio Arbeo氏はJavaのライブラリであるXercesを使って純正Javaのライブラリを作り始めました。
完了にはまだ沢山の課題が残っているうちに、残念ながら夏は終わってしまいましたが、原田洋子氏（組み込みJRuby、JSR-223及びBSFの実装者）がこの後を引き継いでくれました。
この結果、どのプラットフォームでもlibxmlの有無に関わらずネーティブのコードを書く事無しにほぼ完璧に動くNokogiriが完成しました。
これは最もポータブルなNokogiriであると言うだけでなく、FFIバージョンに較べてかなり高速な物です。

JRubyを取り巻くコミュニティ

前にも述べましたが、JRubyを使ってくれるユーザ、イベント、そしてプロジェクトなしにはJRubyはJRubyたり得ません。
JRubyのコミュニティではどんな事が起こったのかを振り返ってみます。

JRubyConf 2010

Joe O'Brien氏とEngine Yard社の協力により、始めての単体開催となるJRubyConfがありました。10月の初めに150人を超す参加者が世界中からオハイオ州コロンバスに集い、JRuby、JRuby on Rails、JRuby on Android、JRuby関連のプロジェクト、その他（勿論JRubyに特化されていない議題もありました）についての講演に耳を傾けました。
昨年RubyConf 2009直後に開催されたJRubyConf 2009と今年のJRubyConf 2010の成功を受けて、来年も是非JRubyConf 2011を開催したい所です。ヨーロッパでもJRubyConfを、という気運もあります。あなたの参加をお待ちしています。

ブログ

JRubyのコミュニティの面々は何百と言う記事を今年書きました。多すぎてここでは挙げません。いずれ纏めて発表出来ればいいと思いますが、それまではどうか独自に検索して下さい。JRubyが実に目新しい方法で使用されているのが解ると思います。

会議とユーザグループ

RubyとJavaの両方に根差すJRubyは両方のイベントに気を配る必要があります。
そしてJRubyの普及の為、色んな場所へと旅をしました。
今では世界中でRubyやJavaの会議と言えば誰かがJRubyについて話をしてしているでしょうし、RubyやJavaのユーザグループでは最低一回JRubyについての発表があったのではないでしょうか。
JRubyのコアチームメンバーがした物が多いですが、実際にJRubyを使っているユーザによる発表も数多くあり、JRubyの普及に一役かっています。
JRubyコミュニティは益々多くのイベントに姿を現していますし、この傾向は2011年も続くよう期待しています。

2010年にはJRubyを中心に据えたユーザグループが誕生しました。JRuby Users JPです。片手に余る回数の会合を既に開催しており、Ruby会議2010ではメンバーの方々ともお会いする事が出来ました。

さあ、あなたもJRubyについて発表されては如何ですか？

RubyConf 2010でのJRubyトラック

筆者自身による初めてのJRubyについての（実は人前で喋る最初の）発表はRubyConf 2005でした。当時JRubyはIRBを動かす事もままならず、他の講演者達はJRubyをネタにしてジョークを飛ばしていました。
それが2010年になると、JRubyを主な題材とする講演は数多くあり、その他の講演でも取り上げられる事がしばしばになりました。
RubyConf主催者の方々に感謝します。そして、JRubyを受け入れてくれたRubyのコミュニティの人々に敬意を表します。
我々の努力が、諸氏がより良いRubyプログラマとなる一助となっている事を実感しています。

LinkedIn社の"Signal"

LinkedIn社は多くのプログラミング言語を用いて開発をする事で知られている所で、JRubyをユーザ向けに使った（LinkedIn Polls）先駆者の一つです。
LinkedIn社は今年、野心的な、Signalというソーシャルアグリゲータをユーザのプロファイルへとつなげるアプリケーションを発表しました。
そのフロントエンドはJRubyで、Scala等、他のJVM言語によりバックエンドサービスが実装されています。
このプロジェクトの成功により、これに似たプロジェクトの幾つかにゴーサインが出ているそうです。

RedCar

Macユーザなら、エディタはTextMateを使っているのではないでしょうか。
大人気のこのエディタに触発されてDan Lucraft氏はRedCarを書きました。
そして手軽に弄る事が出来るよう、Lucraft氏はRedCarをRubyで書いたのです。
2009年の終わり頃、Lucraft氏はマルチプラットフォームでのサポートを容易にするため、コードベースをC RubyとGTKで書かれた物からJRubyへと移植する決断をしました。
2010年、RedCarは幾つかのリリースを経て、沢山のフィーチャを備え、多くのユーザと貢献者を獲得しました。
かく言う私もTextMateからRedCarに乗り換えたユーザの一人です。
JRubyについての講演でRedCarを使うのは実に快いです。
そしてJRubyで書かれたデスクトップのアプリケーションに人気が出るのもとても良い事です。

Ruboto

2010年はAndroidプラットフォームの人気が爆発した年でもありました。
AndroidはJavaに似たシステムですので、Javaの行く所にはJRubyもついて行きます。
2009年に私が実験的に行ったJRubyをAndroidに移植する試みを
Jan Berkel氏やScott Moyer氏等がRuboto IRBに大幅に手を加え、今年Androidマーケットプレイスにリリースされました。
Ruby Summer of Codeの参加者であるDaniel Jackoway氏はRuboto Coreプロジェクトを起こし、Androidで動くJRubyベースのアプリケーションの生成器とそれにまつわるAPIを作り上げました。
またJay McGavren氏等はRubotoでの実験を多いに宣伝して、Rubyのモバイルの分野での可能性を示してくれています。

「Using JRuby」刊行

5人の執筆者（コアチームからの四人—私、Sieger氏、Enebo氏、Bini氏とIan Dees氏）による二年の歳月を経て、JRuby本の決定版とも言うべき「Using JRuby」が遂に完成しました。
この記事を書いている現在、本は版組みに入っており、2011年一月に出荷の予定になっています。
これにはPragmatic Programmersからの根気強い支持が欠かせませんでした。
それを主題とするカンファレンスと、そしてそれを主題とする本が出版されたと言うことは、私にとってみれば、そのプロジェクトが一人前になったと言う事です。
JRubyにも遂にその日がやって来ました。

The Bossie

JRubyは他の分野でも認められるに至りました。InfoWorld誌による（Best Open Source Application Development Software）部門Bossie賞の受賞です。
これで「InfoWorld誌が認めたRuby言語実装」と書いても差し支えありませんね。

次はあなたの番です

さあ、あなたもJRubyコミュニティに参加してみませんか。
あなたの地域のJava、Ruby、OO、その他テクノロジー関係のグループで発表したり、コーディングイベントを主催してみませんか。
近くのカンファレンスでの発表はどうですか。
自分のプロジェクトにJRubyを使ってみて、JRubyが改良すべき点などを教えて下さい。
ブログ記事を書いたり、スクリーンキャストを収録されてはどうですか。
JRubyがどんなに素晴らしいか、友人に伝えて下さい。
JRubyのトラッカーを眺めたり、今動かないRubySpecsを見たり
メーリングリストで話題になっている問題などを読んで、貢献出来るかどうか見てみて下さい。
JRuby wikiを読んでみて、改善すべき所を見つけたり、新しい記事を書いたり、或いは他の言語への翻訳などの手伝いをしてみませんか。
Rubyを広める手伝いをお願いします。
私達はJRubyをより良い物にする努力を続けて行きます。

最後に…。あなたにとって印象深いJRubyの出来事は何でしたか。コメント欄でもいいですし、ブログ記事などでも構いません。お待ちしています。

Eclipse Memory AnalyzerでRubyアプリケーションのメモリリークを検知する

2010-07-25T02:54:00.001-05:00

原文: チャールズ＝オリバー＝ナター

前回の記事「JRubyでメモリを観察するには」の後、何人かの人からEclipse MATのJRubyでの使い方について書いてみたらどうかとの意見を貰いました。これを早速取り上げる事にします。

Eclipse Memory Analyzerは他のEclipseを基盤にしたアプリケーションの例に外れる事なく、起動すると基本ページから個々の作業向けのページへと移動します。

MATは、jhatに較べてもっとインタラクティブにヒープダンプを解析する事が出来ます。MATはjmapのダンプファイルを解析出来ますので、メモリリークを起こしているRailsのアプリケーションからダンプを取ってくる事にしましょう。

このコントローラをアプリケーションに加えました。

class LeakyController < ApplicationController
  class MyData
    def initialize(params)
      @params = params
    end
  end

  LEAKING_ARRAY = {}
  def index
    LEAKING_ARRAY[Time.now] = MyData.new(params)
    render :text => "There are #{LEAKING_ARRAY.size} elements now!"
  end
end

どこかの秀才君が最近使われたリクエストへのパラメータを、時間をキーにカスタムタイプで包んで、定数としてLeakyControllerに後片づけする事なく保存する事にしたようですね。これは一時凌ぎなのかも知れませんし、もしかしたら開発スタッフの中にはオバカサンが紛れ込んでいるのかも知れません。いずれにしてもこれは検知して直す必要があります。

このアプリケーションを動かして/leaky/indexを10000回ほど呼びます。There are 10000 elements now!と出力される筈です。

~ ➔ ab -n 10000 http://localhost:3000/leaky
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
...

10000のリクエストを処理してしまった後も、アプリケーションのメモリ消費量は、ヒープが一杯になるまで増加の一途を辿ることが解ると思います。（JRubyはJVMで走りますから最大ヒープ量を自動的に設定します。）jmapを使って調査を始めましょう。

~ ➔ jps -l
61976 org/jruby/Main
61999 sun.tools.jps.Jps
61837

~ ➔ jmap -histo 61976 | grep " ruby\." | head -5
 37:         11685         280440  ruby.TZInfo.TimezoneTransitionInfo
 40:         10000         240000  ruby.LeakyController.MyData
133:           970          23280  ruby.Gem.Version
137:           914          21936  ruby.Gem.Requirement
170:           592          14208  ruby.TZInfo.TimezoneOffsetInfo

私達の旧友TimezonTransitionInfoがまた顔を覗かせていますが、これはもうお約束なので気にしない事にします。この、一見して10000個もあるLeakyController::MyDataってなんでしょうか。これはどこから来たのでしょう。これを参照しているオブジェクトなんでしょうか。

ここから、メモリをダンプして、MATを使って解析したり、或いは、VisualVMでやるようにMATでダンプをとって一気に解析に移ったりする事が出来ます。ここではMATに全部やらせることにします。

MATにヒープを読ませる

（注記：ここまで記事を書いてきて、最新のOS X版のJava 6のjmapにはちょっとした欠陥がある事が判明しました。どうやらダンプされないオブジェクトが有るようなのです。結果的にダンプを解析しても表示されないフィールドやオブジェクトがあります。幸いにもSoylatteやOpenJDKのビルドにはこのような問題は存在しないようです。ここでは私がビルドしたOpenJDK 7を使います。

ファイルメニューからAcquire Heap Dumpを選びます。

このダイアログは、前述のjpsコマンドが挙げるのと同じプロセスを表示しますから、解り易いと思います。（JDKのインストールディレクトリを指定しなければならない時は、Configureボタンを押して、jdkhomeフラグをHPROF jmap dump providerに指定して下さい。）

Railsアプリケーション（プロセスIDは61976）を選んで続行です。

MATはプロセスに接続し、ヒープをディスクにダンプして、直ぐにこれを読み込みます。

ダンプの読み込みが終わると、次の選択肢は幾つか有ります。

日が違えば、コンポーネント毎にメモリ消費の多いオブジェクトを探して回ったり、或いは過去の解析結果を見直したりする事にもなるでしょうが、今回はMyDataのリークの解決が最優先なのでLeak Suspects Reportを走らせます。

リーク容疑者ですって?

メモリリークを起こしているかも知れないオブジェクトを探して回る事が出来るなんて便利なツールがあるなんて、冗談ではないんでしょうか。それが本当にあるんですのよ、奥様！

これは、ツールが星の数ほどあるJVMならではの長所だと思います。基本的なツールの数が多すぎて（メモリを調査するものだけで最低1ダースはあるでしょうから）デベロッパはメモリ解析等、特定の目的の為のツールへと移行して行ったのです。私がリーク追跡する時にはMATをよく使います。（jhatに較べてメモリ消費が少ないのでヒープをざっと読むにはとても都合がいいのです。）

さて、MATがヒープを読み込んだところで、メモリリークを起こしていそうなオブジェクトのチャートが表示されます。理論的には、オブジェクトが消費するメモリの量が、ヒープに存在する他のオブジェクトに較べて特別に多いものを探しているのです。今回の場合、MATは、合わせてヒープの半分以上を占めている容疑者を三つ挙げました。

下へスクロールしてこれらを見てみましょう。

容疑者のリストには、Hashが一つ、Moduleが一つ、そして711個のClassオブジェクトが含まれているようですね。JRubyが使う、コアクラスとRailsとそしてRailsが依存するライブラリに含まれるクラスの数は容易に数百に上りますから、Classオブジェクトはここでは無視します。4MBも消費している巨大なModuleがありますが、これについては後述します。

Hashが第一容疑者ですね。これを拡大してみましょう。

新しく表示された情報の一番上のものは「accumulation point」への「最短パス」のリストです。「accumulation point」というのは、リークを起こしていそうなデータが集まっている場所の事です。ただ集まっているだけではないのですが、ここでは一部だけを見ています。

このリストの一番上には、始めに容疑者として挙げられたRubyHashオブジェクトと、それへと連なるオブジェクトの列が表示されています。この場合、Hash自体からConcurrentHashMap、そしてClassオブジェクトのconstantsフィールドへと参照の連鎖を辿って行けます。（ここでは何も隠された要素がないと言う事に注意して下さい。）たったこれだけで何かしらのClassがこのHashオブジェクトを定数として保有している事が解りました。凄いでしょう。

念の為、本当にこのオブジェクトに問題がある事を確認します。もう少し下へとスクロールするとこのHashが集めたオブジェクトのリストが有りますので、これを見てみましょう。

ハッシュテーブルの項目が並んでいますが、もっと詳しく見る事は出来ないものでしょうか。

この項目もクリック出来ますから、どんどんクリックして中身を覗いて行きましょう。項目をクリックすると何が集まったのか解ります。List Objectsメニュー、そしてサブメニューからwith Outgoing Referencesを選びます。

このRubyHashEntryに隠されたMyDataオブジェクトが漸く見えてきました。

これでこのRubyHashが目的のデータである事が確認出来ました。更に、このオブジェクトのキーはTimeオブジェクト（org.jruby.RubyTime オブジェクト）である事も合わせて知ることが出来ました。「最短パス」画面に戻って、このオブジェクトを保有しているConcurrentHashMapについてもう少し詳しく調べてみましょう。このマップのエントリーは定数をキーにしていますから、どのキーがメモリリークを起こしているデータを参照しているかが解る筈です。

（OpenJDK 7を使った事でメモリアドレスが変わっている事に注意して下さい。データの構造に変化は有りません。）

注目のRubyHashを直に参照しているHashEntryオブジェクトから今一度「List Objects」「with Outgoing References」をやります。

ありました！HashEntryのkeyのところに定数「LEAKING_ARRAY」がありました。

例のModuleは？

メモリリークの容疑者に挙げられていたModuleはどうしたんでしょう。ヒープで4MBものスペースを占有していました。これも調べてみましょう。

ああ、どうやらEclipse MATはGemモジュールにメモリリークの容疑を掛けたようですね。何故でしょう。もう一度レポートに戻って、下の方にある「Accumulated Objects by Class table」を見てみましょう。

Gemモジュールが最終的には~~6000~~ものGem::Specificationオブジェクト（3.8MBを占有しています）を参照する事が見て取れます。（~~ところで手元には6000ものgemは決してインストールされてはいません。~~これはRubyGemsのバグなのかも知れません。もしかしたらJRubyとEclispe MATを使う事でRubyGemsのメモリリーク、又はメモリの浪費を発見したのかも知れませんね。）

Evan Phoenix氏によると私は結果を読み間違っていたようです。Specificationオブジェクトの数は249で、「self」のサイズがおよそ6000バイト、そしてその占めるメモリの量が3.8MBということです。では、MATのもう一つのフィーチャであるCustomized Retained Set計算を使って説明します。

今、保有されているメモリの量がちょっと怪しいですよね。本当に3.8MBものメモリがGem::Specificationsオブジェクトによって保有されているのでしょうか。多すぎると思いますよね。でもGemモジュールの参照を順々に追って行くのは大変面倒です。無駄なデータを省くのに何か良い手段はないものでしょうか。

まず最初にGemモジュール画面に注目します。メモリリークの第二容疑者として挙げられているところの、「Shortest Paths」を拡大します。一番上のRubyModuleがGemモジュールで、ここからCustomized Retained Setを計算します。

出て来るダイアログでは計算の為のオプションを指定する事が出来ます。ここでは、Gem::SpecificationがRubyのクラスとモジュールを参照している部分を除くのが目的ですので、単純にorg.jruby.RubyClassとorg.jruby.RubyModuleを無視することします。

結果は前に見たものと似ていますが、保有されているヒープの量で並べられています。

どういう事でしょうか。全てStringデータのようですね。

JRubyのStringクラスの実装はorg.jruby.RubyStringオブジェクトで行っていますが、それにはorg.jruby.util.ByteListオブジェクトを集め、更にorg.jruby.util.ByteListオブジェクトはJavaのbyte配列を集めたものを用いています。ですから、このリストの上位三つは実質的にはStringと同等であると言えます。これがどこから来ているのかを捜査する最善の方法は、RubyStringについて「List Object」「with Incoming References」をする事でしょう。

やっと、どこからStringがやって来るのかを一望出来る画面が出ました。始めの方にあるものを幾つか調べてみると、それがGemモジュールにある定数のテーブルに有るものだと解ります。これは大した問題ではなさそうですが、RubyStringオブジェクトを保有しているメモリの量の順に並べ替えると、システムの様子が少し違って見えます。

最大のStringオブジェクトを掘り下げてみると、これはGem::Specificationのインスタンス変数に保有されているように見えますね。これはもう少し調べてみる価値がありそうです。

Rubyアプリケーションには押し並べて沢山のStringがあるものです。これだけでは特に変わった事では有りませんが、（バイトそのものに至る迄の）非効率を調査出来るようなツールが有り、またGemモジュールで保有されているデータの一部はクラス序列への参照ではない、「本物」であると知るのは気持ちのいいものです。

（でもこのようなStringの全てがヒープに残っているのがよいかどうかはまだ納得していません。でもこれから先の調査は読者への宿題にします。）

あなたの番です

Eclipse MATは無料で手に入るツールのうち、恐らく最善の物の一つです。オブジェクトの閲覧、メモリリークの検知、GCのルート解析、オブジェクトのクエリ言語の他にも、数多くのフィーチャが本体と第三者からのプラグインには有ります。メモリリークを追いかけていたり、或いは手元の(J)Rubyアプリケーションのメモリ消費を調べてみたいという場合、MATは試してみる価値のあるツールです。（そして、その結果を是非知らせて下さい。）

JRubyのメモリを観察するには

2010-07-24T09:53:00.001-05:00

原文: チャールズ＝オリバー＝ナター

Ruby言語の各実装において、どんなメモリ消費を解析するツールがあるのかが近頃ちょっとした話題になっています。それもその筈、Rubyで書かれたアプリケーションの（不具合の調査は言うに及ばず）メモリ消費の具合を詳しく調べるのは容易い事ではありません。 JRubyを使わないのなら、そうです。

JRubyはJVM上で走るので、JVM向けに作られた何十ものツールの恩恵に授かる事が出来ます。中にはJDKに同梱されているものを含め、メモリの調査、解析、レポートをするものもあります。ヒープダンプが欲しければ、Hotspot系のJVM（SunまたはOpenJDK）に含まれるjmapやjhatが使えます。もっと高度なツールが欲しければ、Eclipseを基にしたMemory Analysis Tool、メモリ及びCPU性能解析ツールであるYourKit、今ではHotspotに含まれているJavaVMを始め、数多くの選択肢があります。こうした数多くのツールのお陰でメモリの調査には事欠きません。

本稿では実際にこのうちの二つのツールをどの様に使いこなすか見ていく事にします。取り上げたツールは起動中のJVMを観察するグラフィカルなツールであるVisualVMと、ヒープをダンプして事後解析を可能にするjmapとjhatのタッグチームです。

準備

ここで紹介するツールはJRubyのどのバージョンでも使う事が出来ますが、JRuby 1.6の開発に当たり、様々な改良を施してあります。特記すべきは、RubyでのオブジェクトとJavaに於けるオブジェクトが並んで表示されるようにしてある点です。ここでもう少し解説しましょう。

JRubyではRubyでのコアクラスは全てJavaネーティブのクラスで表されています。RubyのObjectクラスはorg.jruby.RubyObjectで、Stringクラスはorg.jruby.RubyStringで、と言った具合です。通常、コアクラスを拡張する場合、Javaネーティブのクラスをわざわざ書き出したりはしません。替わりに、ユーザによって作り出されるObjectを拡張するRubyObjectがメモリに出現するのです。このやり方には実によい用途があります。即ち、RubyObjectの中を覗いてmetaClassがどのRubyクラスを指しているかを調べるという用途が。

出発点が解るよう、これがどんな風になっているのかを見てみましょう。独自のクラスを生成し、一万個のオブジェクトを生成し、保存して、その後スリープするスクリプトを動かします。


~/projects/jruby ➔ cat foo_heap_example.rb 
class Foo
end

ary = []
10000.times { ary << Foo.new }

puts "ready for analysis!"
sleep

~/projects/jruby ➔ jruby foo_heap_example.rb 
ready for analysis!

これで実験の準備は出来ました。jmapを使用するに当たってこのスクリプトのプロセスIDが必要です。使い慣れたシェルコマンドを使う事も勿論出来ますが、JDKにはJVMのプロセスIDを集める為のツールが同梱されていますのでこれを使います。jpsというツールです。


~/projects/jruby ➔ jps -l
52862 sun.tools.jps.Jps
52857 org/jruby/Main
48716 com.sun.enterprise.glassfish.bootstrap.ASMain

これから、私は三つのJVMプロセスを走らせている事が判ります。一つはjpsそのもの、もう一つは先程実験の為に走らせたJRuby、そしてもう一つは、ついさっきテスト用にスタートさせたGlassfishサーバです。興味があるのはJRubyですから、プロセスIDは52857です。jmapでこれをどのように扱うか見てみましょう。


~/projects/jruby ➔ jmap
Usage:
    jmap [option] <pid>
        (to connect to running process)
    jmap [option] <executable <core>
        (to connect to a core file)
    jmap [option] [server_id@]<remote server IP or hostname>
        (to connect to remote debug server)

where <option> is one of:
    <none>               to print same info as Solaris pmap
    -heap                to print java heap summary
    -histo[:live]        to print histogram of java object heap; if the "live"
                         suboption is specified, only count live objects
    -permstat            to print permanent generation statistics
    -finalizerinfo       to print information on objects awaiting finalization
    -dump:<dump-options> to dump java heap in hprof binary format
                         dump-options:
                           live         dump only live objects; if not specified,
                                        all objects in the heap are dumped.
                           format=b     binary format
                           file=<file>  dump heap to <file>
                         Example: jmap -dump:live,format=b,file=heap.bin <pid>
    -F                   force. Use with -dump:<dump-options> <pid> or -histo
                         to force a heap dump or histogram when <pid> does not
                         respond. The "live" suboption is not supported
                         in this mode.
    -h | -help           to print this help message
    -J<flag>             to pass <flag> directly to the runtime system

出てきたオプションのうち、一番簡潔なものは-histoです。これでヒープに格納されているオブジェクトをヒストグラムで出力します。これをJRubyのプロセスに使ってみます。


~/projects/jruby ➔ jmap -histo:live 52857

 num     #instances         #bytes  class name
----------------------------------------------
   1:         22677        3192816  <constMethodKlass>
   2:         22677        1816952  <methodKlass>
   3:         35089        1492992  <symbolKlass>
   4:          2860        1389352  <instanceKlassKlass>
   5:          2860        1193536  <constantPoolKlass>
   6:          2798         739264  <constantPoolCacheKlass>
   7:          5861         465408  [B
   8:          5399         298120  [C
   9:          3042         292032  java.lang.Class
  10:          4037         261712  [S
  11:         10002         240048  org.jruby.RubyObject
  12:          3994         179928  [[I
  13:          5474         131376  java.lang.String
  14:          1661          95912  [I
...

出力結果はJVMのシステムに存在している文字通り全てのオブジェクト（JRubyに全く関係の無いものまで）を表示します。この結果の価値は明らかでしょう。自分で書いたコードのメモリ消費だけではなく、同じプロセス内に存在している全てのライブラリ、全てのコードを、バイト配列（上記の[B）やJavaのString（上記の"java.lang.String"）に至るまで全て調べる事が出来ます。特別JRubyに関わる事は何もやっていません。

本題に戻りましょう。僕らの書いたFooクラスは一体どこへ行ったのでしょう。

答えは実は目の前にあります。10002個あるorg.jruby.RubyObjectのうち、10000個はFooオブジェクトに他なりません。残り二つはRubyランタイムが作った何かでしょうが、この出力結果からは残念ながら区別出来ません。JRuby1.6ではこれが改善されます。

今開発中のブランチではユーザによって作り出されるRubyのクラスにJavaのクラスをあてがう為のオプションを使う事が出来ます。これを使うともっと使い勝手のよいプロファイル結果を得るなどの利点があります。このオプションを使ってみましょう。（1.6リリースまでには、これがデフォルトになるか、或いはこのように長いオプションを使わずに済むようになると思います。）


~/projects/jruby ➔ jruby -J-Djruby.reify.classes=true foo_heap_example.rb 
ready for analysis!

このプロセスにjmapを使うと、さっきのよりも面白い結果が得られます。


 num     #instances         #bytes  class name
----------------------------------------------
   1:         22677        3192816  <constMethodKlass>
   2:         22677        1816952  <methodKlass>
   3:         35089        1492992  <symbolKlass>
   4:          2860        1389352  <instanceKlassKlass>
   5:          2860        1193536  <constantPoolKlass>
   6:          2798         739264  <constantPoolCacheKlass>
   7:          5863         465456  [B
   8:          5401         298208  [C
   9:          3042         292032  java.lang.Class
  10:          4037         261712  [S
  11:         10000         240000  ruby.Foo
  12:          3994         179928  [[I
  13:          5476         131424  java.lang.String
  14:          1661          95912  [I

Fooクラスがあるのが一目瞭然ですね。"reify classes"オプションにより、Rubyクラスと同じ名前のJVMクラスが、ruby.という接頭辞付きで生成されました。まだまだ小手調べですが、JVMのツールの本当の力を垣間見る事が出来るようになります。簡素なRailsアプリケーションを走らせて、結果を見てみましょう。


~/projects/jruby ➔ jmap -histo:live 52926 | grep " ruby."
  29:         11685         280440  ruby.TZInfo.TimezoneTransitionInfo
  97:           970          23280  ruby.Gem.Version
  98:           914          21936  ruby.Gem.Requirement
 122:           592          14208  ruby.TZInfo.TimezoneOffsetInfo
 138:           382           9168  ruby.Gem.Dependency
 159:           265           6360  ruby.Gem.Specification
 201:           142           3408  ruby.ActiveSupport.TimeZone
 205:           118           2832  ruby.TZInfo.DataTimezoneInfo
 206:           118           2832  ruby.TZInfo.DataTimezone
 273:            41            984  ruby.Gem.Platform
 383:            14            336  ruby.Mime.Type
 403:            13            312  ruby.Set
 467:             8            192  ruby.ActionController.MiddlewareStack.Middleware
 476:             8            192  ruby.ActionView.Template
 487:             7            168  ruby.ActionController.Routing.DividerSegment
 508:             6            144  ruby.TZInfo.LinkedTimezoneInfo
 523:             6            144  ruby.TZInfo.LinkedTimezone
 810:             4             96  ruby.ActionController.Routing.DynamicSegment
2291:             2             48  ruby.ActionController.Routing.Route
2292:             2             48  ruby.I18n.Config
2293:             2             48  ruby.ActiveSupport.Deprecation.DeprecatedConstantProxy
2298:             2             48  ruby.ActionController.Routing.ControllerSegment
...

ruby.を含む結果だけに絞りました。実に素晴らしい結果です。不可思議な事に970個ものGem::Versionオブジェクトが少なくとも23280バイトを消費しているのが解ります。更に残念な事に11685個に及ぶTZInfo::TimezoneTransitionInfoのインスタンスが280440バイトを消費している事も解ります。

さあ、使えるデータが出揃ってきたところでjmapとjhatについてもう少し詳しく見て行きましょう。

jmapとjhat

ご推察の通り、JRubyを開発するときに私はプロファイラーを多いに使います。かれこれ10個ほどのツールを使った事があると思いますが、最初に手が伸びるのは決まってjmapとjhatのコンビです。

jmapの一番簡単な使い方は既に見ました。次はオフラインのヒープダンプを見てみます。


~/projects/jruby ➔ jmap -dump:live,format=b,file=heap.bin 52926
Dumping heap to /Users/headius/projects/jruby/heap.bin ...
Heap dump file created

こんなに簡単に使えます。バイナリのダンプのファイル、heap.binは幾つかのツールで中身をみる事が出来ます。当然、jhatが使えますし、VisualVMやEclipse Memory Analysis Tool等も使えます。何かの標準に則ったフォーマットではありませんが、長い間そのフォーマットは変わっていません。jhatのオプションを見てみましょう。


~/projects/jruby ➔ jhat
ERROR: No arguments supplied
Usage:  jhat [-stack <bool>] [-refs <bool>] [-port <port>] [-baseline <file>] [-debug <int>] [-version] [-h|-help] <file>

 -J<flag>          Pass <flag> directly to the runtime system. For
     example, -J-mx512m to use a maximum heap size of 512MB
 -stack false:     Turn off tracking object allocation call stack.
 -refs false:      Turn off tracking of references to objects
 -port <port>:     Set the port for the HTTP server.  Defaults to 7000
 -exclude <file>:  Specify a file that lists data members that should
     be excluded from the reachableFrom query.
 -baseline <file>: Specify a baseline object dump.  Objects in
     both heap dumps with the same ID and same class will
     be marked as not being "new".
 -debug <int>:     Set debug level.
       0:  No debug output
       1:  Debug hprof file parsing
       2:  Debug hprof file parsing, no server
 -version          Report version number
 -h|-help          Print this help and exit
 <file>            The file to read

For a dump file that contains multiple heap dumps,
you may specify which dump in the file
by appending "#<number>" to the file name, i.e. "foo.hprof#3".

All boolean options default to "true"

基本的にjhatにヒープダンプを投げてやれば、jhatは仕事を始めます。解析するヒープが大きいと-Jを使ってjhatを走らせるJVMにヒープ用のメモリを多くやらないといけない場合も稀にあります。Railsのアプリケーションを解析しますので、ちょっと多めにヒープメモリを与える事にします。


~/projects/jruby ➔ jhat -J-Xmx200M heap.bin
Reading from heap.bin...
Dump file created Fri Jul 09 02:07:46 CDT 2010
Snapshot read, resolving...
Resolving 604115 objects...
[much verbose logging elided for brevity]

Chasing references, expect 120 dots........................................................................................................................
Eliminating duplicate references........................................................................................................................
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

「サーバの準備完了」と出ました。何ですかそれは！Javaでは何でもかんでもサーバでやるんですか？

まあ、ここでは実際使い勝手が良いので見逃す事にします。jhatはポート7000でウェブサーバを立ち上げました。これでバイナリの中身をマウスを使って調べる事が出来ます。どんなものでしょう。

これが最初のページです。JVMクラスがリストされています。下へスクロールすると一般的な機能が幾つかあります。

ヒープのヒストグラムを選びます。

沢山のオブジェクトがメモリを消費しているのが見て取れます。オブジェクトにはJVM固有のものもあれば、JRubyの実装の為の物も、Rubyのクラスからの物もあります。ここでもTZInfo::TimezonTransitionInfoがあるのが解りますね。クリックしてみましょう。

クラスに関する情報だけで、これと言って余り面白いものはありませんね。しかし、この画面の一番下からTimezoneTransitionInfoのインスタンスを見る事が出来るようです。やってみましょう。

段々面白くなってきました。このようなものが沢山有るのが解ります。もうちょっと調べるのに一番始めのインスタンスをクリックします。

これは凄い。

TimezonTransitionInfoにあてがわれたJVMクラスには三つのフィールドが有るのですね。一つはmetaClassで、Rubyのクラスを指します。もう一つはvarTableで、インスタンス変数や内部で使われている変数を格納している配列です。最後は、freezeされているか、taintされているか等、プログラムの実行時に使う様々なフラグを示すフィールドです。これらのフィールドを見ても良いですが、本稿では飛ばします。

更に下へ行くと、もっと凄いリンクが有ります。一つはこのオブジェクトへのリファレンスのリスト。これを見ると、もう使われていない筈なのに、どうしてTimezoneTransitionInfoがGCされずにメモリに残っているのかが解ると思います。jhatでこのオブジェクトを生かす事になっているリファレンスの連鎖を、スレッドやJVMのオブジェクトにまで遡って見る事も出来ます。また、この連鎖を逆の方に辿って行く事も出来ます。

これはjmapとjhatの機能のほんの一部に過ぎません。こんなに簡単で良いのかな、と思えるくらいに使い勝手がいいです。でも、実行中のアプリケーションを観察するにはどうすればいいでしょうか。ヒープをダンプしてオフラインで解析することで得られる情報は多いですが、オブジェクトが生成されて、そしてGCされて行く様を見たい場合も時としてあります。VisualVMを使います。

VisualVM

VisualVmはNetBeansのプロファイリングのツールとして生まれました。往時のJVMについての大きな不満の一つは、同梱されいたツールがJVMを開発するエンジニアだけを対象にデザインされていた物だったという事があります。Sunには、IDEと関連するモジュールを作るという先見の明があって、これが、誰にでも使えるようなプロファイラーが自然と生まれました。これがVisualVMの起源です。

Java 6をインストールしてあるコンピュータ殆どでjvisualvmコマンドとして実行出来ます。やってみましょう。

VisualVMを立ち上げると、現在実行中のJVMがjpsコマンドの場合と同じように表示されます。他のコンピュータで実行中のJVMに接続したり、ヒープダンプやコアダンプを解析したり、過去に見たメモリやCPUプロファイリングのスナップショットを見る事も出来ます。今回は、実行中のRailsアプリケーションを見てみましょう。

VisualVMが実行中のプロセスに接続して、プロセスやJVMについての基本的な情報を出しました。ヒープの使用状況に興味が有りますのでMonitorのタブをクリックします。

色々と有益な情報がもう入ってきました。この画面ではCPUの使用状況、ヒープの使用状況、JVMで使われているクラスの数と動きの有ったスレッドの数が表示されています。弄り始める前に一旦掃除しようと思えば、ガーベージコレクターを作動させる事も出来ます。最大の利点はjmap/jhatの二つのツールを使ってやっていた事がHeap Dumpボタンを押すだけで一気に出来る事でしょう。魅惑的でしょう？

初期状態ではヒープの総合的な情報が見えます。全体のサイズ、クラスの数、ガーベージコレクターのルートなどです。TimezoneTransitionInfoを探してClassesをクリックします。

ちょっと下の方に有りました。予想通りの数だけ在りますからダブルクリックしてもっとよく見てみましょう。

jhatで既に見たのと同じ情報ですが、ここではもっと見やすくなっていますね。どれをクリックしても何か起きます。ヒープのあちこちを見て回ったり、かなりの手作業を要するような解析も簡単に出来ます。別なツールも見てみましょう。Retained Size計算機です。

ここで見ているJVMのツールにとっては全てのオブジェクトは平等ですから、報告されている、ヒープでのRubyオブジェクトの大きさというのは全てではありません。前述の変数を格納しているテーブル、オブジェクトのインスタンス変数、そしてオブジェクトが参照しているオブジェクトなども考慮に入れなければなりません。別なオブジェクト、Gem::Versionでこれを見てみる事にします。

スクロールしてruby.Gem.Versionクラスを探すのは面倒ですから検索しましょう。OQL ConsoleではSQLに似たクエリでヒープの中から条件に見合ったオブジェクトを探し出す事が出来ます。ruby.Gem.Versionのインスタンス全てを探します。

クエリが実行されてGem::Versionオブジェクト全てが出てきました。これを掘り下げてどれくらいのメモリをVersionオブジェクトそれぞれがヒープにキープさせているのかを見てみましょう。

Compute Retained Sizesボタンを押すと、Instancesペーンがこのダイアログで警告を出します。これくらいではやられません。Yesをクリックします。

ちょっと休憩…

結果が出ました。Versionオブジェクトはそれぞれ125バイトから190バイト、全部で19400バイトを消費しているようです。その殆どは変数テーブルに当てられているようです。何が入っているのでしょう。

なるほど、文字列と配列のようです。ヒープに色々と探りを入れ続ける事も、JRubyやJVMのクラスの中身を見たりして、アプリケーションの本当の姿を見る事が出来ます。凄い力を手に入れました。

あなたの番です

勿論これは氷山の一角です。例えば、Eclipse Memory Analysis Toolにはメモリリークを探知する機能があります。VisualVMとNetBeansにはアロケーショントレーシングという、アプリケーションコードのどこでオブジェクトが生成されているのかを見せる機能もあります。GCの動向を見せるツールも数多く有り、中には稼働中のヒープを弄ってオブジェクトを操作出来るものすらあります。あったらいいな、と思うような機能は何かしらのツールに備わっている、と言えるくらいです。JRubyを使えばそのようなツール全てを何の手を加える事もなく使えるのです。

ここで述べたツールは全てJRuby 1.5.1で使えますが、Rubyクラスに上手に対応するJVMクラスはありません。それにはソースコードからビルドするか、1.6.0.devバージョンをダウンロードするか、或いは1.6.0のリリースを待つかする必要があります。これらを含め、どんなツールを使っているか、是非報せて下さい。このブログでも取り上げたいと思います。

近いうちに、他のツールと、CPUプロファイリングについても取り上げます。それまでは、JRubyを使えばこのような素晴らしいツールが使えるのだと言う事を覚えておいて下さい。

今のJVMに欠けている物

2010-06-17T23:18:00.001-05:00

原文: チャールズ＝オリバー＝ナター

今日ツイッターで、「JVM及びJDKが、あらゆるプログラミングにおいて真にイケてるプラットフォームになる為には未だ幾つかの欠陥が有る」と呟きました。沢山の人から「もっと詳しく」とせっつかれたので、ここに短く書き起こしておきます。勿論、これで全部という訳ではないのでしょうが、今日思いついたのはこれだけです。

ゼロから起動する際のパフォーマンス

現存するJVMの起動はかなり速いですが、Java 7でのHotSpot（訳注：Sun及びオラクルのJVM）にはこれをより良くする為の改良が盛り込まれています。普通、こういった改良は、バイトコードを予め検証したり（或いは検証の為のヒントを与えたり）、クラスデータを幾つかのプロセスで共有したり、在り来たりではありますがプログラムのロード時間やリンク時間を短縮する工夫を凝らす事で成し遂げられます。ところが、多くのアプリケーションにしてみれば、このような改良は、起動時間を長引かせる最大の原因（ゼロから起動する際のパフォーマンス）には余り効果がありません。JVMはJITコンパイルした結果をセーブしないので、起動する際には常にゼロからのスタートを余儀なくされます。その時、コンパイルするに至る迄はバイトコードをインタープリタで走らせるのです。インタープリタの無いJVMでさえ、一番初めに掛かる、それほど最適化されていないアセンブリコードへのコンパイルにはかなりの時間を要します（コマンドラインでJRockit（オラクル及びBEAのJVM）やJ9(IBMのJVM）をいじってみて下さい）。

改善の為の提案は今までにもなされていますが、どれも一筋縄では行きません。

コンパイルする過程の分割: 初めのコンパイルは最速で、最適化を行わないコンパイラを使い、後から適当なプロファイリングを行いながら最適化を行う。HotSpotのJava 7リリースではこのようなコンパイラが装備されるかも知れませんが、この開発を妨げるような問題が幾つか有りました。
コンパイルした結果や最適化した結果を何らかの形で保存する: 理論的には可能ですが、これを深く追求すればするほど保存するのは難しくなっていきます。メモリ内で行われる最適化やコンパイルの結果は、普通メモリのレイアウトに依存しています。これをディスクに保存すると、ロードする際、以前と違う物（メモリアドレスやクラスアイデンティティ等）を消してしまう必要が有ります。.NETでは、凡、静的コンパイルに限られてはいるものの、これが可能です。これが妥協点という事でしょうか。
JVMを常に走らせておいて、それに新しい仕事を与える。: JRubyではnailgunというライブラリを用いてこれを実現していますが、問題点が幾つか有ります。第一に、JVMの状態（システムプロパティやメモリ消費量）に不都合が生じる場合が有ります。第二に、死なないスレッドが発生した場合にそれを終了させる事が出来ないので、長い間走っていると、このような「死に損ない」のスレッドが溜まって行きます。そして第三に、コンソールで走っている訳では有りませんから、普段コンソールで当たり前にやっているような事が出来ません。

これが、JRubyが直面する解決出来ない最大の問題であり、弁明を必要とする最大の問題です。JRubyは速く、時としてとても速く、日に日に速くなっていますが、初めの五秒はそんなに速くないので、余り良いとは言えない第一印象を与えることになるのです。

コンソールとターミナルのサポートを強化

標準でJVMに装備されているIOストリームが色々な面で役に立たないと嘆いているブログは枚挙に暇が有りません。例えば、selectを使えないというのがありますが、JRubyにはこれが原因で直せないバグが幾つか有ります。また、サブプロセスに渡す事が出来ない、というのも有りますが、これはIOライブラリの欠陥よりはプロセス起動の為のAPIに拠る所が多いと言えるでしょう。ターミナル関係の機能はJava APIには悉く欠落しているので、ラインエディットの機能を備える為だけにjlineみたいなライブラリを取り入れざるを得ない事になるのです。もしJDKがターミナルとプロセスを上手く扱えるAPIを標準で備えると、こうした余計な手間暇を掛ける必要が無くなってしまいます。

未だ望みは有ります。Java 7に取り入れられる予定のNIO2ではプロセス起動の為のAPI（標準IOストリームを継承する事も可能）や、select可能な様々なチャンネル等の多くの機能が盛り込まれています。これで充分だといいですね。

壊れたAPIを直す

JDBCは欠陥品です。何故かと言うと、ドライバーをハードリファレンスを含んだマップに登録しなければならず、登録を行ったクラスローダーから登録削除をしなければメモリリークしてしまうからです。と言う事は、ウェブアプリやEEアプリケーションからJDBCをロードすると、ドライバーがアプリケーションへのリファレンスを持ち、且つ上に述べたマップがドライバーへのリファレンスを持つので、アプリケーション全体がメモリに残る事になります。これがアプリケーションサーバがアプリケーションをundeployした後でもメモリリークを起こす最大の理由です。JRubyの立場から言うと、これも直す事が出来ないバグです。

オブジェクトのシリアル化も壊れています。何故かと言うと、クラスローダーを獲得し、オブジェクトのフィールドをリフレクションによりアクセスし（リフレクションを使ってフィールドにアクセスするならば、可能ならばいっそのことカプセル化等は無視してしまえばいい）、そしてオブジェクトのインスタンスを適切に初期化する事なく生成する為に有りとあらゆるトリックを使っているからです。これを使う為には、引数を何も取らないコンストラクタを用意したり、コンストラクタ以外でも初期化が可能なようにfinal修飾子を外したりしなければならず、万が一にもデフォルトで用意されているシリアライザを使おうものなら、その遅さは天誅が下るほどです。

リフレクションが遅すぎるのに、これをどうする事も出来ないというのもあります。リフレクションを通したメソッドを呼び出しを何層にも渡って行う羽目になるだけではなく、引数のリストと数値関係をボックス化しなければならず、加えて例外を扱う為にこれ等全てをラッパーに包む必要が有る、と言った具合です。invokedynamicに伴って、メソッドへのアクセスが高速な直のポインターであるメソッドハンドルが装備されます。これは当の昔に加えられて然るべきフィーチャでしたが、幸いな事にJava 7でこれが現実のものとなります。それ迄は、JRuby等のプロジェクトはリフレクションに掛かるコストを負担するか、メソッドハンドルを手作業で生成するしかありません。実際、JRubyでは両方やっています。

正規表現もいただけません。簡単な選択を用いるだけで、大きなインプットに出くわした時Javaスタックが崩壊してしまうほどです。現在の、Sunによって産み出された正規表現は、選択等に再帰を用いているのでインプットが大きいと簡単に壊れてしまいます。JRubyではこの酷い問題に対処する為、我々自身の手で行ったもの二度を含めて、何と四度も正規表現エンジンの実装を行いました。ユーザの為には私たちは血の滲むような努力をしています。

他にも例はまだまだあります。それはJava 1.0から手直しの入っていない遺物あったり、（老いたAPIは死なず。ただ軽視されゆくのみ…あるいは完全無視されるのみ。）実際には複数のJVMプロセスがアプリケーションを一つずつ又は多くても二三個走らせているのが効率的であるのに、巨大な一枚岩の様なサーバが何十ものアプリケーションを取り扱うのが良いという姿勢の遺物もあります。加えて一枚岩な環境では、アンデプロイの際にメモリリークを起こしたり、プロセスを隔離していれば起こらない、基本的なリソースの奪い合いが起きるなどの問題を抱えています。このようにまずいAPIを本腰を入れて手直しをするのは価値ある事だと思います。

ネイティブライブラリとPOSIX機能の強化

Java 6の時点ですらシンボリックリンクを扱う事が出来ませんし、ファイルのアクセス許可設定も限られたものです。プロセスを新たに起動させるAPIはとても酷い。全てのチャンネルでselect出来ない。出来るのはソケットだけ。ネイティブライブラリを使う為には、JNAやJFFI等の、ネイティブライブラリを動的にロード及びバインドする素晴らしいライブラリが有るにも拘わらず、JNIのコードを書かなければなりません。

POSIXに似たフィーチャが欠けているのは今では言語道断です。JDKに見られるシステムレベルのAPIの殆どは、Windows 95辺りの最低限のレベルに合わせたものです。最近のオペレーティングシステムではPOSIXのAPIの殆どを実装しているというのに。NIO2により、かなり改善されますが、POSIXの一部が対応されないのはほぼ確実です。対応されなかったPOSIX APIにJava APIを完全に合わせるには人手が足りないとか、システムに依存し過ぎのAPIである、等の理由が考えられます。

ネイティブライブラリをロードする問題についても、これが当の昔にJDKの一部になっていて当然であると言えます。「純粋なJavaを!」と声高に叫ぶ人は多いと思います。私も叫ぶでしょう。しかし、Javaのライブラリには機能が備わっていないとか、外部プロセスを介していたのでは容量向上に期待出来ない場合はあります。このような場合、ネイティブライブラリを使わざるを得ません。ところが、これをJavaプラットフォームでやろうとすると、入門者には中々手も足も出るような代物では有りません。ネイティブコードをいつ呼び出すか、自分たちで選べるようにするためにも、JNAやJFFI、又はこれに似た物をJDKに入れて欲しいものです。

決め台詞

ここまでに挙げた様々な問題点の多くは、JRubyでは多大な代償を払って、解決或いは何らかの方法で対処してきました。他のどのプロジェクトよりもJVMやJDKの欠点に対処してきたと言っても過言ではないでしょう。起動時間の短縮の為にあらゆる手段を尽くしました。Cのコードを一行も書く事なくネイティブライブラリにバインド出来るように、華麗かつ堅実なライブラリを同梱しています。コンパイルの際、また実行時に多くのコードを生成して、リフレクションをそれほど使わずに済むような工夫もしています。十数個のOSでPOSIXにネイティブに対応しています。Marcin Mielzynski氏が鬼車をJavaに移植しました。外部プロセスの呼び出しがRubyユーザの思惑通りになるように考えられるトリックは全て使いました。云々。

でも、このやり方では長くやって行く事は出来ません。今まで上手くやってきたとは言え、JVMやJDKにいつまでも継接ぎを当てて行く訳には行きません。願わくば、この記事が世界中のJVMとJDKの開発者への警鐘となりますように。Javaプラットフォームが、サーバのみ、巨大アプリのみ、継続アプリのみ、ターミナル無しの世界になってしまわないようにするために、これらの問題点を解決して下さい。いつでも協力します。:-)

JRubyのパフォーマンスの更なる向上を目指して

2010-06-15T22:19:00.001-05:00

原文: チャールズ＝オリバー＝ナター

JVM上でJRubyが動く事の利点は折りに触れて述べてきました。JRubyのパフォーマンス数値はそこそこの結果を出しているのですが、多くの人々の期待に反して「抜群に素晴らしい」というものではありませんでした。詰まる所、他のRuby言語の実装に較べて良い結果を出したとしても、静的な型システムを用いる他のJVM言語には敵わないのでした。

しかし、それは今までの話し。

最近、JRubyの実行時に得られる情報に基づいた最適化をあれこれと試し始めました。ご存知の通り、JRubyは、Ruby言語の構造木をJVMのバイトコードにコンパイルするJITを搭載しています。その一方で、JITを使った他のシステムとは異なり、JRubyは最終的に良い結果をもたらすような情報をプログラムの作動時点で集めることはしなかったのです。今までにやっていた最適化と言えば、AOTコンパイラで安全に出来るような静的な最適化、そして最終的には、実行前にすべてをコンパイルすることによる起動コストを減らすための、遅延コンパイルJITモード（訳注:現在のデフォルトJITモード。以前はJITなしか、最初にすべての静的最適化を行うか、の2択だった）を追加することでした。

これは実用的な判断でした。JVMは沢山のことをやってくれるので、JRubyが実装しているような未熟なコンパイラと限られた静的な最適化でも、パフォーマンスの向上は見込めます。この為、JRubyのパフォーマンスは凡その用途には極めて満足の行くものでした。18ヶ月前のバージョン1.1.6以来、実行スピードの向上については野放しといったような具合でした。この間中はユーザからの要望を優先させていました。Javaとのより良い統合性、Rubyとの互換性の向上、メモリ消費（稀にリーク）の改善、jruby-rackやactiverecord-jdbc等周辺ライブラリの充実、そしてシステム一般の安定化などです。ユーザにパフォーマンスは？と訊くと、「あれば良い」という意見が一般的で、特に問題があるという意見は極々稀でした。JRubyのパフォーマンスは極めて満足の行くものだったと言えるでしょう。

とは言うものの、最近になって幾つかの避けられない真実に直面せざるを得なくなってきました。

幾ら速くても速すぎる事はないし、スピードが上がっていかなければ相対的に遅くなっている印象を与えてしまう。
RubyのプログラムをCやJava並に速く動かしたいという要望は有るので、もし可能ならばそれを実現させるべき。
JRubyユーザは（当然の事ですが）Rubyでプログラムを書きたいので、出来るだけRubyで書けるようにするべき。その際、パフォーマンスで犠牲を払わずに済むようにするべき。
パフォーマンス向上にはとても時間が掛かるけれども、それが達成出来た時の悦びは一塩。

そう言った訳で、JRuby 1.6の俎上に上がっている項目に加えて、私はコンパイラをいじる事を決意しました。

取り掛かって間も無いので、その辺は了承して下さい。

JRubyのコールサイトについて

Rubyのコードで動的にメソッドが呼び出される場所それぞれに、JRubyはコールサイトと呼ばれるものを組み込みます。他のVMでは単にこの呼び出しが起こる場所の事をコールサイトと呼ぶ場合もありますが、JRubyではコールサイトはorg.jruby.runtime.CallSiteの実装を伴います。次のコードを例に挙げます。

def fib(a)
  if a < 2
    a
  else
    fib(a - 1) + fib(a - 2)
  end
end

このコードには全部で六つのコールサイトがあります。a<2の中の<、a-1とa-2にある二つの-、二つのfibメソッドの呼び出し、そして最後にfib(a-1)+fib(a-2)に見られる+です。余りよく考えずに動的なメソッド呼び出しをしようとする方法としては、それぞれのオブジェクトに問題のメソッドが有るかどうかをその度に確認して、あればそれを実行するというのが考えられます。（これは最もてぬきなリフレクションコードがやるようなやり方です。）他の動的な言語のVMの例に外れる事なく、JRubyでもコールサイトのキャッシュを用いる事でメソッドの有無の確認に掛かる費用を軽減しています。実装の立場から言うと、キャッシュされるCallSiteは全てorg.jruby.runtime.callsite.CachingCallSiteのインスタンスであるという事です。簡単でしょう？

ランタイムで集める事の出来る情報を利用する最も簡単な方法は、このようにキャッシュされたコールサイトをヒントにして、それぞれのコールサイトでどのメソッドが呼び出されるのかを知ることです。上に挙げた+をの場合を見てみましょう。ここで、+メソッドはその都度Fixnumオブジェクトに対して呼び出され、ここではfibの値はBignumへと溢れ出るくらい大きくならないとして、Floatとも無関係という事にします。JRubyではFixnumオブジェクトはorg.jruby.RubyFixnumというクラスで実装されていて、+メソッドはRubyFixnum.op_plusとして実装されています。こんな具合です。

@JRubyMethod(name = "+")
public IRubyObject op_plus(ThreadContext context, IRubyObject other) {
    if (other instanceof RubyFixnum) {
        return addFixnum(context, (RubyFixnum)other);
    }
    return addOther(context, other);
}

addFixnumの詳細は宿題という事にします。

ここで@JRubyMethod(name = "+")というアノテーションがある事に注意して下さい。JRubyで実装されているRubyのコアクラスのメソッドには全てこのようなアノテーションが付随していて、引数の数、Ruby側から見たメソッドの名前（ここで見る+はJavaでは許されないメソッドの名前です）等、メソッド呼び出しの詳細を指定します。また、このメソッドは二つの引数を取る事に注目して下さい。ThreadContext（このメソッドを実行しているスレッド特有のランタイムの情報）オブジェクトと、今まさに足されようとしているother（引数）です。

JRubyをコンパイルする際、全てのソースファイルを読み込んでJRubyMethodのアノテーションを抽出し、コアクラスのメソッド一つ一つにインボーカを生成します。このインボーカはorg.jruby.internal.runtime.methods.DynamicMethodクラスのインスタンスで、メソッドについての詳細及び呼び出しの際のシグネチャ等の情報を含んでいます。このようにインボーカを生成する理由は簡単です。JVMの殆どは、多数のコードパスを持つコードはインライン展開しないので、たった一つのインボーカで全てのメソッドに対処しようとすると、インライン展開は全く行われない事になるのです。ここまでの話をまとめてみましょう。プログラムの実行の際、Rubyのコードにあるメソッド一つ一つにCachingCallSiteインスタンスがあり、例えば+メソッドが初めて呼び出された時これに対応するメソッドのオブジェクトを取ってきて、これ以降の呼び出しの為にキャッシュします。キャッシュされたメソッドはDynamicMethodのサブクラスで、最終的にどのようにRubyFixnum.op_plusメソッドを呼び出して、返り値をどう扱えばいいのかも知っているのです。至極簡単です！

初めの一歩

暫くプログラムを走らせていると、どのメソッドが呼び出されるのか大体見当がつきます。私の手元で試しているコードではこの点に漸く着目しています。そして、どのメソッドが呼び出されるのか事前に判っているのなら、前提が満たされる限り呼び出しは動的でなくて構いません。（ここで言う前提とは、例えば「このメソッドは常にFixnumについて呼び出される」とか「これのメソッドは"+"のコア実装である」といったものです。）つまり、JRubyはJVMバイトコードへのコンパイルを遅らせる事で、動的なメソッドの呼び出しを静的な呼び出しへと換える事が出来るかも知れない、と言う事です。

このプロセスは実はとても簡単です。私もつい二日前に始めたばかりですので、この過程を追って見てみましょう。

第一段階：動的呼び出しを静的呼び出しに置き換える

まず初めに必要なのは、生成されたメソッドに直接呼び出しを可能にするだけの情報を持たせることです。もっと詳しく言うと、どのJavaクラスをターゲットにしているのか（+の例で言うとターゲットはRubyFixnumです）、Javaメソッドとしての名前（op_plus）、返り値及び引数の数と型（IRubyObjectを返し、引数はThreadContextとIRubyObject）、そしてメソッドがstatic宣言されているかどうか（モジュールメソッドの殆どはそうですが、op_plusはそうではありません）。これらの情報を一つに纏め上げてNativeCallという型に入れ込む事にし、これをこれを静的呼び出しが可能かもしれないすべてのインボーカに割り当てます。

public static class NativeCall {
        private final Class nativeTarget;
        private final String nativeName;
        private final Class nativeReturn;
        private final Class[] nativeSignature;
        private final boolean statik;
        ...

コンパイラにも似通ったロジックを付けました。動的な呼び出しをコンパイルする際、まずコールサイトが何らかのメソッドを既にキャッシュしているかを調べます。もしキャッシュしているのならば、そのメソッドに相応のNativeCallが有るかどうかを確認します。有るのなら、いつもの様に動的にメソッドの呼び出しをするのではなく、JVMのごく普通のメソッドのようにコンパイルします。こうすると、今まで

INVOKEVIRTUAL org/jruby/runtime/CallSite.call

だったものが

INVOKEVIRTUAL org/jruby/RubyFixnum.op_plus

となり、"+"メソッドの呼び出しはRubyFixnumクラスを扱うJavaコードを書いているのと実質同じになります。

これで第一段階（コンパイラに、ここまでに見たような動的なメソッド呼び出しを認識させ、静的呼び出しにする）は終了です。この試験的な手法はコアクラスのメソッドの殆どに今すぐ使えますし、あらゆる呼び出しに使えるようにするのは難しくないでしょう。

鋭いVM実装者は既にお気付きかも知れませんが、後に実際は別のメソッドを呼び出す必要がある時のために備えるためのガードの挿入や事前のテストに、ここまでは言及していません。これは意図したものです。この話は後で触れます。

第二段階:Fixnumの使用を抑える

次に私がやったのは、ボックス化されたRubyFixnumではなくプリミティブ型の使用を許す事でした。JRubyではRubyFixnumは常に64ビットlongですが、メソッドの呼び出しの時にはIRubyObjectを使わなければならず、動的メソッドの呼び出しの際にはRubyFixnumオブジェクトを新たに作り出す必要が有ります。この時に作り出されるオブジェクトはとても小さく、直ぐに要らなくなるのでGCへの影響は問題では有りません。でもアロケートする時の速度には勿論影響があります。RubyFixnum一つ一つにメモリを確保しなければならず、その為にメモリ帯域幅を食い潰してしまいます。

このようなオブジェクトの割当を無くしたり軽減させる手段としては、スタックアロケーション、値型、即値、エスケープ解析等があります。このうち現存するJVMで使えるものはエスケープ解析だけで、しかも非常に扱い辛いです。と言うのも、あるオブジェクトを利用するすべてのパスがインライン展開されていなければならず、さもなくばそのオブジェクトを（エスケープ解析によってはにより）省略できません。

そこで、JVMへの負担を減らす為、ボックス化されたlongまたはdouble（Rubyで言うところのRubyFixnum及びRubyFloat）を一つだけ渡しているのが確実な場所に、プリミティブのlongまたはdoubleを受け取る呼び出し先を追加します。つまり、第二段階と言うのは、このようなメソッドをRubyFixnumについて幾つか実装する事でした。op_plusをlongに対応させたのがこれです。

public IRubyObject op_plus(ThreadContext context, long other) {
    return addFixnum(context, other);
}

ここまででは、或るオブジェクトが常にFixnumであるという事を証明するような手段は未実装なので、コンパイラには今の所100とか12.5といったようなリテラルを引数にしてメソッドの呼び出しをしているようにしか見えません。幸運にも、上のfibの例では丁度そのような場面が三つありました。一つは<、そしてもう二つは-です。「どのメソッドが場面場面で実際に使われているか」という知識と「RubyFixnumを介さずにメソッドをどう呼び出すか」とを合わせる事により、実際のバイトコードはこのように簡単になります。

INVOKEVIRTUAL org/jruby/RubyFixnum.op_minus (Lorg/jruby/runtime/ThreadContext;J)

（この表記に不慣れな読者の為に添え書きしておきますと、引数の最後のJは、この呼び出しが第二引数でプリミティブであるlongを要求している事を示しています。）

これでメソッド呼び出しを効率良く行う為の準備が出来ました。勿論、この例はとても単純ですが、RubyからJavaで書かれた恣意のコードの呼び出しに使える可能性を示しています。RubyからJavaのコードを呼び出す時、独自の複雑なマルチメソッド呼び出しロジック及び何層もあるJavaのリフレクションAPIを経る事なく、直接Javaのコードを呼ぶ事が出来るという事です。中間に有るコードがなければJVMはJavaのコードをRubyのコードの中にインライン展開する事が出来、全体を最適化するのです。ワクワクしてきたでしょう？

第三段階:極小最適化をちょこちょこと

さて、fibには後二つ厄介なメソッド呼び出しが残っています。fibの再帰呼び出しです。これを上手く片付けるやり方としては、既にjitコンパイルされているRubyコードから呼び出される、未だjitコンパイルされていないRubyコードが存在することをコンパイラに教えると言う事が考えられます。例えば、そうしたメソッドを強制的にコンパイルさせて、そのコンパイルされたメソッドから呼び出されるメソッドをもコンパイルさせて…という風にやっていって、ホットなメソッドから順々に或る程度の閾値まで最適化を行っていく訳です。「例え」とは言いましたが、これが多分実装になると思います。JRubyでRubyメソッドをjitコンパイルするのは容易い事なので、これをコンパイラに実装するには数分で充分です。でも、木曜日から考え続けて、もう一捻りやる事にしました。

コンパイラに「入れ知恵」する替わりに、非常に簡単な単一の最適化の方法を取り入れる事にしました。つまり自己再帰を検出し、その場合に限って最適化をする訳です。JRubyの場合で言うと、fibに相応するCachingCallSiteオブジェクトが、今まさにコンパイルしようとしている同じfibメソッドを呼び出していることを割り出すという事。このメソッドを動的メソッド呼び出しのパイプラインに流し込むのではなく、直接の再帰呼び出しに換えてしまう訳です。丁度、コアメソッドである<と-と+を換えた様に、です。バイトコードレベルではfibの呼び出しはこのようになります。

INVOKESTATIC ruby/jit/fib_ruby_B52DB2843EB6D56226F26C559F5510210E9E330D.__file__

ここで、B52DB28云々という所はfibメソッドのSHA1ハッシュ、そして__file__というのはjitコンパイルされたメソッドのデフォルトのエントリーポイントです。

ここだけの話ですが…

実験的なコードには付き物の話ですが、ここでは、互換性を多少犠牲にすればどれくらいのパフォーマンス向上が謀れるかを示しています。
ですから、ここで挙げた最適化の手段には幾つかの注意点が有ります。

まず、インボーカを素通りするのでRuby独自のバックトレース情報（現在のメソッド名、ファイル名、行番号など）をヒープで保持する事が無くなり、Rubyのバックトレースが滅茶苦茶になってしまう、という点。この点はJRubyが、JavaとRuby両方のバックトレース情報を保持する為にパフォーマンス劣化を余儀なくされる所です。JavaのバックトレースでRubyの関係のある情報を保持出来るようにするか、またはRubyのバックトレースをJavaのバックトレース情報から掘り出す（現存する--fastオプションでこれは可能です）ようにするにはまだまだ課題は山積しています。

次に、ここではbackrefやlastlineに当たるもの（$~と$_に相当するもの）を扱う為の情報を管理していません。つまり、正規表現や行単位の処理などでは機能の低下が有る事になります。（とは言うものの、これらの値を使うのは推奨されていないので、この事は余り苦にならないかも知れません。）スレッド固有のスタックを上手く使う（つまり、このような変数を扱うかも知れないメソッドに出くわした時にだけスタックに変数を押し込む）事で、この機能は取り戻せるでしょう。理想的には、或るコールサイトが$~や$_を読み書きするかは判るので、実行時にプロファイリングする事で賢くこういった判断を行える筈です。

最後に、直接呼び出しするか、普通の動的なメソッド呼び出しをするかで枝分かれする所にガードを置いていません。これは実験を素早く進める為に執った実利的な決断です…と同時に興味深い問題を提示するものでも有ります。もしも、このメソッドが見得る全ての型とメソッドを見てしまったと解るのならどうでしょうか。「死ぬほど最適化して」と言い放つ事が出来れば、そして、実際JVMがそうしていると知ることが出来ればと思いませんか。個人的にはそのようなガード（理想的には、パフォーマンスに余り影響のない簡単な「メソッドID」の照合）無しにJRubyがリリースされるとは到底思えませんが、そうした「静的化」による最適化は、ユーザの意思でスイッチを入れることが出来るようになると思います。更に、もしもJRubyの実装のより多くをRubyで書かれたコードに移行する事になれば、こうした「完全な」最適化を利用するであろうと思われます。

さて、こうした注意点に留意しながら実測値を見てみる事にしましょう。

それでは、フィボナッチ数の計算のためにJRubyを利用されている皆様以外には無意味な数値をご覧にいれましょう。

fibメソッドはベンチマークにおいて恐ろしく乱用されています。ほとんどの呼び出しが少なくとも2つの再帰的呼び出しと、数値演算によるその他いくつかの呼び出しを生じさせるため、主にメソッド呼び出しのベンチマークになります。またJRubyでは処理時間の大半が、Fixnumオブジェクトの生成か、呼び出し毎の実行時データ構造の更新に取られるため、このベンチマークは、メモリ割り当て率またはメモリ帯域幅のベンチマークを兼ねることになります。

しかしベンチマークとしては結果が解り易いので、今一度これを乱用することにします。どうか、以下の数値は、互いの数値を比較するのでない限り無意味であることを肝に銘じておいてください。JRubyは未だに、即値や値型での実装よりも遙かに多くのオブジェクトを生成しており、その為、JVMはこのベンチマークの一部分を最適化し過ぎていると思われます。しかしもちろん、そこがポイントの一つです。我々はJVMを加速させ、潜在的に不必要な計算の排除を実現しようとしており、また実行時コンパイルの改良に実行時データを利用することで、それらが可能になってきています。

使うのは、2.66GHzのCore 2 Duoプロセッサを搭載したMacBook Pro。OS XとJava 6 (1.6.0_20) 64-bit Server VMで動作する、JRuby 1.6.dev (masterに私的なハックを入れたもの)です。

まず、フル機能のRubyバックトレースと、動的呼び出しでの、基本的なJRubyでのfib測定値です。

0.357000   0.000000   0.357000 (  0.290000)
0.176000   0.000000   0.176000 (  0.176000)
0.174000   0.000000   0.174000 (  0.174000)
0.175000   0.000000   0.175000 (  0.175000)
0.174000   0.000000   0.174000 (  0.174000)

次に、Javaバックトレースに基づくRubyバックトレースと、若干インライン化し易くした、しかしまだインボーカ経由での動的呼び出しと、限定的なプリミティブ型呼び出し最適化によるものです。本質的には、完全な互換性を損なわずに（しかし実際には多少損ないつつ）我々が得られるJRuby 1.5としては最速です。

0.383000   0.000000   0.383000 (  0.330000)
0.109000   0.000000   0.109000 (  0.108000)
0.111000   0.000000   0.111000 (  0.112000)
0.101000   0.000000   0.101000 (  0.101000)
0.101000   0.000000   0.101000 (  0.101000)

次に、ここまで述べたすべての実行時最適化を行ったものです。これらの数値は、適切なガードにより低下するだろうことを覚えておいてください（それでもまだ非常に素晴らしいですが）:

0.443000   0.000000   0.443000 (  0.376000)
0.035000   0.000000   0.035000 (  0.035000)
0.036000   0.000000   0.036000 (  0.036000)
0.036000   0.000000   0.036000 (  0.036000)
0.036000   0.000000   0.036000 (  0.036000)

そして、主に再帰を用いた、非常に乱用されているもう一つのベンチマーク: tak関数の比較です。

静的な最適化のみで、可能な限りの高速化:

1.750000   0.000000   1.750000 (  1.695000)
0.779000   0.000000   0.779000 (  0.779000)
0.764000   0.000000   0.764000 (  0.764000)
0.775000   0.000000   0.775000 (  0.775000)
0.763000   0.000000   0.763000 (  0.763000)

そして実行時最適化:

0.899000   0.000000   0.899000 (  0.832000)
0.331000   0.000000   0.331000 (  0.331000)
0.332000   0.000000   0.332000 (  0.332000)
0.329000   0.000000   0.329000 (  0.329000)
0.331000   0.000000   0.331000 (  0.332000)

以上のように、これらの小さなベンチマークでは、JRubyコンパイラの2～3時間のハックにより、これまでに達成した最も速いJRuby性能値よりも2～3倍速い数値を達成しました。

頑張れJVM

まだ説明していないトリックがあります。JVMは今も、大部分の仕事をこなしています。

古き良き動的呼出しの事例と、静的に最適化された事例では、JVMは従順に、与えられたすべてのものを最適化します。それはRubyのメソッド呼び出しを受け取り、インボーカとその最終的なメソッド呼び出し群をインライン化し、コアクラスメソッドをインライン化し（そうです。これは、JRubyがいつでも、RubyからRuby、JavaからRuby、またはRubyからJavaへ、適切な調整を加えてインライン展開できることを表しています）、これらを非常によく最適化します。しかしここに問題があります。JVMのデフォルトの設定は、Rubyではなく「Java」を最適化するのに調整されています。Javaでは、あるメソッドから他のメソッドへの呼び出しは確実に1ホップです。JRubyの動的呼び出しでは、最終的に目標に到達するまでにCallSiteとDynamicMethodをあちこち移動するため、3、4ホップかかるかもしれません。Hotspot（訳注: SunのJVM）はデフォルトでは高々9レベルまでの呼び出ししかインライン展開しないので、JRubyはその割当量をあっという間に消費してしまうことがわかるでしょう。それに加え、JavaからJavaへのメソッド呼び出しは中間コードを持たないため、バイトコードサイズのしきい値（訳注: HotSpotがメソッドのインライン化を始めるバイトコードサイズ）を消費しません。我々は本質的に、Javaのようなよりシンプルな言語に比べて、Hotspotの最適化能力のほんの一部しか利用していないのです。

次に、動的に最適化される事例を考えてください。今後多少のガードコードを追加しなければならないとしても、既に多くのメソッド呼び出しからCallSiteとDynamicMethodの両者を取り除きました。それは、9レベルのRubyメソッド呼び出し、またはRubyからコアメソッドまたはJavaを利用する9レベルのロジックがインライン展開できることを意味します。Hotspotに対して、最適化のための遙かによい全体像を与え、また滅多に利用されないデータ構造の更新のような、Rubyメソッド呼び出しを行う際の背景雑音を取り除きました。今後バックトレースを有効な形で取り出せるようにする必要がありますが、少なくとも二重のトラッキングはしていません。

つまり、我々がしなければならない事といえば、インライン化のためのすべての困難な作業をJRubyのコンパイラにさせるのではなく、JVMにそれをさせ、現在のJVMの最適化コンパイラに蓄積された何年分もの仕事から利益を得ることだけです。難問を解決するための一番良い方法は、誰かにそれを解かせることであり、JVMはここに示した難問を解くために素晴らしい仕事をしてくれます。我々は、JVMに対して魚を与えたり魚釣りを教えるのではなく、湖の地図を与えています。JVMは既に一流の漁師だからです。

これらの最適化には別の側面があります。我々の継続的なインタプリタ整備が、上手く行き始めているということです。インタプリタモードを持たない他のJVM言語は、いかなる動的最適化をも行おうとすると遙かに苦労します。端的に言えば、そのバイトコードが最初にどのように生成されたかを明示的に取り出しておかない限り、既に読み込んでしまったバイトコードを置き換えるのは大変困難です。JRubyではメソッドは実行時にいつでもインタプリタモードとJITモードを切り替わらなければならないため、最適化の過程ではるかに自由に行ったり来たりできます。

今はここまでです。数カ月のうちにJRuby 1.6をダウンロードしたらすべてが3倍（もしくは10倍！さらに100倍）高速化されている、ということは期待しないでください。いつこれらの最適化が安全に行われ得るか、必要であればユーザがどのようにすべての最適化を選択できるか、またコアコード（訳注: JRubyにおいてJavaで実装されたRubyのコード）をRubyに置き換え始めるのに十分な高速化ができるかどうかについて、まだまだやらなければいけないことの細かい部分が沢山あります。しかし、初期の結果は非常に有望であり、一部をすぐにリリースするだろうことは確実です。

謝辞

今回の記事ではnahiさんにご協力を頂きました。文責は訳者にあります。

JRuby 1.5.0 リリースのお知らせ

2010-05-12T16:36:00.001-05:00

原文：トム＝エネボ

JRuby バージョン1.5.0

JRubyのバージョン1.5.0 のリリースを発表いたします。

ホームページ: http://www.jruby.org/
ダウンロード: http://www.jruby.org/download

今まで最長のリリース期間（凡そ五ヶ月）を経た今回のリリースは不具合の修正の数も最多になりました。加えて、以下に示す通り、多くの新しい機能も含んでいます。不具合の内訳としてはRubyのメソッドの細かい仕様の修正が殆どです。その点から申しますと、JRuby 1.4.0から1.5.0へのアップグレードは容易でしょう。また、「JRubyから暫く遠ざかっていた」と仰るあなたも、この機会に是非JRubyを今一度試してみて下さい。

主な特長

高パフォーマンスなネイティブアクセスフレームワークと、FFIライブラリのサポート

*NIX用ネイティブ起動コマンド

JavaのビルドツールであるAntのサポート、及びAntとRakeの統合の実現

Windowsサポートの強化

RubyからJavaの呼び出しの性能向上（バグ修正、メモリ消費の低下、スピードの向上）

JSR-223,BSF,RedBridge等による組み込みAPIの強化

Ruby標準ライブラリ　1.8.7p249、RubyGems 1.3.6、RSpec 1.3.0

ruby-debugを標準で装備

Rails 3向けの修正

起動時間の短縮

Object#object_id、Object#__id__の強化

Javaクラスのメモリ消費量の削減とJavaクラスのロードの高速化

クラスローダが、jarを内包するjarに対応

open4ライブラリのバグを修正

jruby.jit.codeCache=dirオプションによりjitコンパイルされたスクリプト、メソッドなどをディスクに書き込み可能

Javaクラスを生成するインターフェイスの新実装

jruby.ji.objectProxyCacheオプションによりOPCの無効化

JRuby::Synchronizedモジュールにより、クラスに属するオブジェクトのメソッド呼び出しを同期化可能

コアクラスの性能向上とJITコンパイラの向上

IRBでObjectSpaceの無効化

mavenアーティファクトの修正

64ビットWindows、及びWindows 7用インストーラーのバグ修正

JRuby 1.4から数えて1250を上回るコミット

謝辞

コミュニティーからの貢献には常に感謝しています。今回のリリースでは特に以下の人々からの貢献がありました。（順不同）

David Calavera, Stephen Bannasch, Daniel Luz, Ian Dees, 大場光一郎さん, Hongli Lai, Hiroshi Nakamura, Colin Jones, 佐々木竹充さん, Roger Pack, Matjaz Gregoric, Joseph LaFata, Frederic Jean, Alex Coles, Lars Westergren

JRuby 1.5.0.RC3 がリリースされました。

2010-05-04T15:34:00.001-05:00

原文：トム＝エネボ
JRuby 1.5.0.RC3 のリリースをお知らせします。

ホームページ: http://www.jruby.org/

ダウンロード: http://www.jruby.org/download

RC2以降に修正されたバグを以下に示します。

JRUBY-3742: Java native threads are not added to ThreadService.rubyThreadMap after being adopted.

JRUBY-4264: threadContextMap leaks RubyThread on death of adopted thread

JRuby 1.5.0.RC2 がリリースされました。

2010-04-28T23:15:00.001-05:00

原文：トム＝エネボ
JRuby 1.5.0.RC2 のリリースをお知らせします。恐らくこれが最後のRCになると思われます。

ホームページ: http://www.jruby.org/

ダウンロード: http://www.jruby.org/download

RC1のリリース以降に修正されたバグを以下に示します。

JRUBY-3153: IO rubyspec failures under IBM JDK6 Linux

JRUBY-3208: ant task api-docs runs out of memory, patch included

JRUBY-4677: Java exceptions can't be rescued with "rescue Exception"

JRUBY-4680: jirb_swing broken: JRuby picking wrong constructor, with no obvious work around

JRUBY-4704: "Java wrapper with no contents" error when subclassing a Runnable class in JRuby

JRUBY-4710: Problems importing classes in default package

JRUBY-4715: FFI::StructByValue missing layout and struct_class methods.

JRUBY-4721: FFI::Platform::CONF_DIR looks in wrong location for PPC Macs.

JRUBY-4724: Java class equality operator is order dependent

JRUBY-4725: to_java_object no longer exists

JRUBY-4729: System properties to set bindir and default rubygems paths

JRUBY-4730: Unix jruby-1.5.0.RC1 distro includes rubygems/default/jruby_native.rb without native launcher

JRUBY-4731: Mismatched default compilation prefix

JRUBY-4733: Allow compilation of Ruby files for a specificic JVM version

JRUBY-4734: Reduce "multiple Java method" warnings in unambiguous cases

JRUBY-4735: install-gems ant target should not count on successful installation of jruby-launcher

JRUBY-4737: Compatibility issue with Spring property from 1.4.0 to 1.5.0.RC1

JRUBY-4738: test/testapp/testapp.exe appears twice in jruby-src-1.5.0.RC1.tar.gz

JRUBY-4742: File::Stat throws a NPE when it doesn't find a file into a jar

JRUBY-4747: read_nonblock error with couchrest

JRUBY-4749: require 'rbconfig' fails on GAE because of NullPointerException

JRUBY-4750: ant-to-rake: task does not work when classpath is defined via taskdef's attribute

JRUBY-4751: Java call to RubyBignum.to_s() returns generic object representation

JRUBY-4754: NotImplementedError: the MD5() function is unimplemented on this machine

JRUBY-4757: addressable gem doesn't work with --fast

JRUBY-4760: File.open throws Errno::ENOENT when file inside jar is accessed using ".." (doubledot) in the path

JRUBY-4761: 1.9.2: Thread#backtrace

JRubyのバージョン1.5.0.RC1がリリースされました

2010-04-15T17:23:00.001-05:00

原文：トム＝エネボ

JRuby バージョン1.5.0.RC1

JRubyのバージョン1.5.0.RC1を発表いたします。

ホームページ: http://www.jruby.org/
ダウンロード: http://www.jruby.org/download

今まで最長のリリース期間（凡そ五ヶ月）を経た今回のリリースは不具合の修正の数も最多になりました。加えて、以下に示す通り、多くの新しい機能も含んでいます。不具合の内訳としてはRubyのメソッドの細かい仕様の修正が殆どです。その点から申しますと、JRuby 1.4.0から1.5.0.RC1へのアップグレードは容易でしょう。また、「JRubyから暫く遠ざかっていた」と仰るあなたも、この機会に是非JRubyを今一度試してみて下さい。以前あった不具合が解消されている可能性大です。1.5.0の正規リリースをより良い物にする為にどうぞご協力下さい。

主な特長

高パフォーマンスなネイティブアクセスフレームワークと、FFIライブラリのサポート

*NIX用ネイティブ起動コマンド

JavaのビルドツールであるAntのサポート、及びAntとRakeの統合の実現

Windowsサポートの強化

RubyからJavaの呼び出しの性能向上（バグ修正、メモリ消費の低下、スピードの向上）

JSR-223,BSF,RedBridge等による組み込みAPIの強化

Ruby標準ライブラリ　1.8.7p249、RubyGems 1.3.6、RSpec 1.3.0

ruby-debugを標準で装備

Rails 3向けの修正

起動時間の短縮

Object#object_id、Object#__id__の強化

Javaクラスのメモリ消費量の削減とJavaクラスのロードの高速化

クラスローダが、jarを内包するjarに対応

open4ライブラリのバグを修正

jruby.jit.codeCache=dirオプションによりjitコンパイルされたスクリプト、メソッドなどをディスクに書き込み可能

Javaクラスを生成するインターフェイスの新実装

jruby.ji.objectProxyCacheオプションによりOPCの無効化

JRuby::Synchronizedモジュールにより、クラスに属するオブジェクトのメソッド呼び出しを同期化可能

コアクラスの性能向上とJITコンパイラの向上

IRBでObjectSpaceの無効化

mavenアーティファクトの修正

64ビットWindows、及びWindows 7用インストーラーのバグ修正

JRuby 1.4から数えて1250を上回るコミット

謝辞

JRubyの起動時間についてのヒント

2010-03-03T01:05:00.001-06:00

原文: チャールズ＝オリバー＝ナター

JRubyはRuby言語の実装の中では一際起動が遅い事で悪名高くなってしまいました。一部は、JITの生成品がなくてブートストラップして動き出すまでに時間がかかってしまうJVMを使っているせいです。起動の際のボトルネックが報告されて原因が解明されればそれを除く努力を我々はしていますが、JRuby自体にも問題があります。起動の問題は、実は簡単な設定問題である事もしばしばです。JRubyの起動を早くするコツを幾つか見ていきましょう。

注意。JRuby自体の起動は、他のJVM言語に較べると結構いい線いっていますが、MatzのRuby（一般的には最も速い実装とは言えない）の起動は素晴らしく早いです。

クライアント用のJVMを使う

これが何と言っても一番手っ取り早い方法です。OpenJDKとSunのJDKを動かしているJVMであるHotSpotには、「クライアント用」と「サーバ用」の二種類のバックエンドがあります。「クライアント用」はバイトコードをコンパイルする時、最適化は最小限に、始めのうちにササッとやってしまうだけです。一方、「サーバ用」は大規模にしかも全体的に最適化をする訳ですが、これが出来るようになる時点に到着するには長い時間が掛かりますし、最適化の為には多くのリソースが必要です。

ごく最近まではJVMのインストールの多くは、この「クライアント用」を好む傾向にありましたので、JVMの起動時間は早かったのです。しかしながら、多くのオペレーティングシステムに最近使われているJVMに於いてデフォルトで使われるのは「サーバ用」か、或いは（「サーバ用」しかない）64ビットのJVMです。これによって、あなたもJRubyも何もしなくても起動時間が悪くなってしまいました。

以下に例を挙げます。jruby -vを「サーバ用」のJVMで起動させ、RubyGemsをrequire（RubyGemsを多く使うアプリケーションで一番長く掛かる部分です）してみます。

~/projects/jruby ➔ jruby -v
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2010-03-01 6857a4e) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_17) [x86_64-java]

~/projects/jruby ➔ time jruby -e "require 'rubygems'; require 'active_support'"

real 0m5.174s
user 0m7.643s
sys 0m0.422s

~/projects/jruby ➔ time jruby -e "require 'rubygems'; require 'active_support'"

real 0m5.068s
user 0m7.662s
sys 0m0.449s

なんと、RubyGemsとActiveSupportをロードするのに5秒以上も掛かってしまいました。この場合にはJVMが「64ビット、サーバ用」のJVMが使われています。このバックエンドはランタイムの性能はいいのですが、起動は酷いものがあります。-vのフラグを出した時にこのような結果が出るのならば、普通32ビットの「クライアント用」のJVMを「-d32」と言うフラグを使って走らせる事が出来ます。このようにします。

~/projects/jruby ➔ export JAVA_OPTS="-d32"

~/projects/jruby ➔ time jruby -e "require 'rubygems'; require 'active_support'"

real 0m2.320s
user 0m2.583s
sys 0m0.207s

~/projects/jruby ➔ time jruby -e "require 'rubygems'; require 'active_support'"

real 0m2.275s
user 0m2.580s
sys 0m0.207s

私の手元の、OS X 10.6を載せたMacBook Proでは、「クライアント用」JVMに切り替える事で50%を優に超える向上が観測出来ました。「-client」も試してみて下さい。32ビットのコンピュータでは「サーバ用」を優先する場合も有り得ますので、これと「-d32」とを組み合わせる必要があるかも知れません。色々試してみて、あなたの環境にあったフラグ組み合わせを見つけたら、プラットフォーム、-vの出力結果、そしてどれ程の効果があったかを報せて下さい。

JVMの共用アーカイブを再生成する

Java 5以降のHotSpot JVMではクラスデータシェアリング（CDS）というフィーチャが使えます。元々アップル社によってMac OS X用に開発されたこのフィーチャにより、一般的試用されるJDKのクラスを一つのアーカイブに集め共用メモリの場所にロードします。一度これを使うと、後からJVMを使った場合には、同じデータをリロードせずに、この読み込み専用の共用メモリを使う訳です。これが、ウィンドウズやMac OS XでJVMの起動時間が近年大幅に改善された大きな理由の一つです。この二つのオペレーティングシステムを使っている人はこのヒントは無視してもいいでしょう。

しかしながら、インストーラが、アーカイブを最終的に試用する場所に解凍するだけのLinuxでは共用アーカイブが生成される事はまず無いと考えていいと思います。システムに、この共用アーカイブを再生成させるには、以下のコマンドと同等のものを走らせて下さい。


headius@headius-desktop:~/jruby$ sudo java -Xshare:dump
Loading classes to share ... done.
Rewriting and unlinking classes ... done.
Calculating hash values for String objects .. done.
Calculating fingerprints ... done.
Removing unshareable information ... done.
Moving pre-ordered read-only objects to shared space at 0x94030000 ... done.
Moving read-only objects to shared space at 0x9444bef8 ... done.
Moving common symbols to shared space at 0x9444d870 ... done.
Moving remaining symbols to shared space at 0x945154e0 ... done.
Moving string char arrays to shared space at 0x94516118 ... done.
Moving additional symbols to shared space at 0x945ac5b0 ... done.
Read-only space ends at 0x94612560, 6169952 bytes.
Moving pre-ordered read-write objects to shared space at 0x94830000 ... done.
Moving read-write objects to shared space at 0x94ea64a0 ... done.
Moving String objects to shared space at 0x94ee3708 ... done.
Read-write space ends at 0x94f27448, 7304264 bytes.
Updating references to shared objects ... done.

多くのユーザにとって、JVMのクラスの多くがメモリに残る為、これで起動時間に大きな差が出る事が有ります。「-Xshare」は「-d32」または「-client」と一緒に使ってみる必要が有るかも知れません。他の「-Xshare」オプションなども試してみて下さい。

JRubyのJITのスタートを遅らせるか、無効にする

JRubyのJITコンパイラの興味深い副作用の一つは、動いている時間が短い時など、場合によっては、アプリケーションの実行を遅くさせてしまう事が有るという事です。コンパイラを使うのは勿論無料では有りませんし、コンパイルした結果として出来たバイトコードをロード、チェック、リンクするのにも何らかのコストが掛かります。多くのコードを使うにも関わらず短いコマンドの場合には、JITを無効にするか、そのスタートを遅らせるのを試してみて下さい。

これで見込める効果には限りがありますが、気が狂いそうになった時はやってみて下さい。

他のRubyプロセスの呼び出しを避ける

Kernel#system、Kernel#exec、及びバッククォートを用いて他のRubyプロセスを呼び出すのはRubyist一般によく見られるパターンです。例えば、テストを実行するのに綺麗な環境を用意する必要がある場合などは頷けるのですが、このようなプロセスの呼び出しはランタイム全体に大きな影響を及ぼします。

JRubyが#system、#exec、或いはバッククォートに出くわすと、まず最初に今現在走っているJVMを使って処理を行おうとします。JRubyは昔から（複数のRuby環境が同じプロセスないで動くという）所謂「マルチVM」による実行をサポートしていましたので、こうする事でサブプロセスの呼び出しを素早く行う事が出来ます。実際、Nailgun（これについては後にもっと詳しく触れます）はこれの応用によって複数のJRubyのコマンド実行環境を隔離しているのです。これでパフォーマンスの向上は見込めますが、それでも尚そのようなJRubyプロセスは新規の綺麗なクラスとランタイムを必要としますので、起動には時間が掛かります。

最悪の場合、（例えばsystem 'ruby -e blah > /dev/null'の様に）シェルのリダイレクトを含むなどするとJRubyを同じJVMで起動させる事が出来ません。この場合、JRubyは全く新しくJVMを起動せざるを得ず、JRubyの起動時間というコストを、もう一度全部払う羽目になってしまいます。

出来る事ならば、このようにRubyを呼び出すのを避けるか、Nailgunの様なツールを使うか、specサーバ等を使って同じプロセスを何度も何度も再利用するのが良いでしょう。

起動時の処理をなるべく少なくする

自分で書かなかったコードが起動時に色々とやってしまう場合が多い（凡その場合それはRubyGemsそのものです）でしょうから、このヒントはあまり参考にならないかも知れません。JRubyが直面する悲しい事実の一つはJVMの上での実装であるという事、そしてJVMのエンジンが温まるまでに時間が掛かり、開始当初のコードは後からのコードに較べて遅いという事です。加えて、JRubyが、RubyのコードをJITコンパイルしてバイトコードにするまでには件のコードを何度か実行するという事を考慮すると、JRubyは立ち上がりがあまり良くないという事が解るでしょう。

不可避なものを後回しにしようとしているように見えるかも知れませんが、起動時にあまり何もしない事で思いがけず良い結果が得られる場合もあります。ウィンドウが表示されるまで、或いはサーバの準備が出来るまで、重い処理を無くす事が出来れば、立ち上がりには付き物のパフォーマンス低下から逃れる（またはその低下を分散させる）ことが出来るかも知れません。ディスクに置いたキャッシュを上手く使とか、殆ど読み込むだけのデータはキャッシュとしてセーブしておいて起動時にはこれをリロード、再処理する、といったように、立ち上がりのアルゴリズムの改良も効果的です。

Nailgunを試す

JRuby 1.3ではNailgunのサポートを実装しました。Nailgunは、一つのJVMを複数回に渡る呼び出しに再利用出来るようにする小さなライブラリとクライアント用ツールです。これを使うと、ちょっとしたJRubyのコマンドの起動は何十倍も早くなるかも知れません。詳細はこの記事を読んで下さい。

Nailgunは魔法の弾丸のように見えるかも知れませんが、残念な事に、RubyGemsの起動、或いはRailsアプリケーションの立ち上がり等、或る種のよく見受けられる使用例ではあまり効果がありません。Rubyプロセスを何度も呼び出しするような場合にも効果は期待出来ません。いずれにしても、試してみて、効果があったかどうか報せて下さい。

JVMのフラグを色々試してみる

JVMには起動時間の短縮（或いは延長）に役立つフラグが数多くあります。試してみるべきフラグのリストは私の書いたこの記事を、ヒープのサイズとガーベージコレクターに影響を及ぼすフラグに特に注意して、読んで下さい。特別に効果のあった組み合わせが見つかったら、是非報告をお願いします。

ボトルネックの発見に協力をお願いします

JRubyの起動時間の短縮には、あなたのようなユーザからの起動時間についての調査が大きく貢献しています。ちょっと弄くってみて、或るライブラリのロードに法外な時間が掛かる（又は起動時に膨大な処理をする）と判明した場合、（ハードディスクがスラッシングする、メモリバスが飽和する等）CPU以外の何かがネックになって起動が遅いのならば、JRubyや、ロードしようとしているライブラリのコードに何か改良の余地が有るのかも知れません。ちょっと掘り下げてみて下さい。思わぬ発見が有るかも知れません。

調査の際に役立ちそうなフラグはこういったものが有ります。

--sampleはJVMのサンプリングプロファイラーをオンにします。特に正確ではありませんが、桁外れのボトルネックとなるようなものはリストの上に出てくる筈です。
-J-Xrunhprorf:cpu=timesはJVMのhprofプロファイラーをオンにして、結果をjava.hprof.txtにセーブします。コードの実行は格段と遅くなりますが、JRubyやJDKのコードの低いレベルでのタイミングをより正確に知ることが出来ます。
-J-Djruby.debug.loadService.timing=trueは、起動時間の大部分を占める、requireに掛かった時間を、程々の精度で書き出してくれます。
ウィンドウズではtimeコマンドに当たるものがありませんが、-bをJRubyに渡す事で（'jruby -b …'といった具合です）これと同様の結果を（JVMの起動に掛かった時間を除いて）得る事が出来ます。

私たちがお手伝いいたします

時として、JRubyにある明らかな設定ミスやバグによってアプリケーションの起動が遅くなってしまう事があります。起動時間がここに挙げて或る例と余りに違いすぎるのは、あなたが使っている環境に問題が有る可能性が大です。そんな場合にはJRubyのメーリングリストに投稿するか、IRCに参加するかして下さい。私たちが、他のJRubyユーザと共に、お手伝いします。

JRubyとRails 3を仲良くさせる方法

2010-02-24T07:56:00.001-06:00

原文ニック＝シーガー

概要

jruby -S rails newapp -m http://jruby.org/rails3.rb

Rails 3のアプリを生成する際にはJRuby専用のテンプレート(-m http://jruby.org/rails3.rb)を使用して下さい。

詳細

rubygemsのバグの為、bundlerはバージョン0.9よりも古い物全てをアンインストールする必要があります。

$ jruby -S gem install rails --pre --no-rdoc --no-ri
Successfully installed i18n-0.3.3
Successfully installed tzinfo-0.3.16
Successfully installed builder-2.1.2
Successfully installed memcache-client-1.7.8
Successfully installed activesupport-3.0.0.beta
Successfully installed activemodel-3.0.0.beta
Successfully installed rack-1.1.0
Successfully installed rack-test-0.5.3
Successfully installed rack-mount-0.4.7
Successfully installed abstract-1.0.0
Successfully installed erubis-2.6.5
Successfully installed actionpack-3.0.0.beta
Successfully installed arel-0.2.1
Successfully installed activerecord-3.0.0.beta
Successfully installed activeresource-3.0.0.beta
Successfully installed mime-types-1.16
Successfully installed mail-2.1.3
Successfully installed text-hyphen-1.0.0
Successfully installed text-format-1.0.0
Successfully installed actionmailer-3.0.0.beta
Successfully installed thor-0.13.3
Successfully installed railties-3.0.0.beta
Successfully installed bundler-0.9.7
Successfully installed rails-3.0.0.beta
24 gems installed

続けて

$ jruby -S gem install activerecord-jdbcsqlite3-adapter --no-rdoc --no-ri
Successfully installed activerecord-jdbc-adapter-0.9.3-java
Successfully installed jdbc-sqlite3-3.6.3.054
Successfully installed activerecord-jdbcsqlite3-adapter-0.9.3-java
3 gems installed

最後に

$ jruby -S rails newapp -m http://jruby.org/rails3.rb
      create
...(app creation)...
       apply  http://jruby.org/rails3.rb
       apply    http://jruby.org/templates/default.rb
        gsub      Gemfile
         run      jruby script/rails generate jdbc from "."
...(warnings omitted)...
       exist  
      create  config/initializers/jdbc.rb
      create  lib/tasks/jdbc.rake
$ cd newapp
$ jruby script/rails server
...(warnings omitted)...
=> Booting WEBrick
=> Rails 3.0.0.beta application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2010-02-23 19:44:26] INFO  WEBrick 1.3.1
[2010-02-23 19:44:26] INFO  ruby 1.8.7 (2010-02-23) [java]
[2010-02-23 19:44:26] INFO  WEBrick::HTTPServer#start: pid=16449 port=3000

おさらい

最善の結果の為、RubyGems 1.3.6を搭載しているJRuby 1.5.0devのスナップショットを使用して下さい。JRuby　1.5ももう少しでリリースされます。加えて最新のactiverecord-jdbc-adapter 0.9.3がRails 3との互換性の為には必要です。

JRubyでのRailsの使用感はどんどん良くなって行きます。

RakeとAntを一緒に

2010-02-23T01:22:00.001-06:00

原文: トム＝エネボ

JRuby 1.5リリースに含まれる新しいライブラリをレポジトリーに先日コミットしました。これについて述べる前にこの下にでている写真を見て色々と思いを巡らして下さい。そう！私たち皆の模範となるミスター・ポテトヘッドです。ミスター・ポテトヘッドは私たちを数時間に渡って楽しませる（少なくともおそらく楽しませてくれていたであろう）、柔軟なただのオモチャではなくて、澱粉質を多く含む食べ物でもあるのです。

ミスター・ポテトヘッド

(MyMollyPopさんの写真)

ちょっとトンチンカンな事を言っているな、と思う前にちょっと考えてみて下さい。実際のところ、私たちがプログラマとして日常やっているのは、ミスター・ポテトヘッドを造り上げているようなものではないですか。ソフトウェアを造り上げるという問題に私たちが直面した時、求められているのは、さまざまな部品をくっつけるだけではなく、部品を最も綺麗に組み合わせる事です。ソフトウェアデザインとは正しくジャガイモを飾り付けるようなものです。この記事の「ジャガイモ」はソフトウェアです。

ビルドのためのツール

Javaにおいて、Antは800ポンド（360㌔強）のジャガイモと言える位のビルドのためのツールの「重鎮」です。AntはJavaをビルドする環境の殆ど全てにあると言っていいでしょう。私は、Antを「心の底から好きだ」と言ってのける人には今までにたった一人しか出会っていません。

大抵は、Antは構文的には見苦しいが与えられた仕事をきちんと成し遂げてくれる信頼出来るツールとして一目置いてるというところでしょう。命令型プログラミングにあまり適さないのにも不平があると思いますが、これは元来の仕様としてそうであるように思われますが、これを歓迎するプログラマはそう多くはないでしょう。

RubyではRakeを使います。Antとは対照的に、Rakeの構文は綺麗です。RubyでDSLのような物を書く為のAPIであるRakeにおいてはRubyで使える物ならば何でも使えます。その一方で、Javaの世界ではよくやるような作業をするのにはAntにあるようなプラットフォームに依存しないタスクを持ち合わせていません。その為、シェルを使ったりする羽目になってしまって、これもある程度は動くのですが、Windowsで動かそうとすると悲しい目に遭ってしまいます。

現実的に言うと、Javaをよく使っている人たちは他のビルド法に関心を示しはするものの、挙って数多くのプロジェクトをAnt以外のツールに移行はしないでしょう。仮にRakeに心惹かれていても、Antで当然の事としてやっているような事をRakeで成す為に四苦八苦する事になるのです。…今までは。

ユースケース

JRubyにおけるRakeとAntの統合では以下のユースケースを扱います。

RakeでAntで定義されているタスクとタイプを呼ぶ。

AntからRakeを呼べるようにする。

RakeのタスクをAntのターゲットとしてインポート出来るようにする。

RakeからAntを呼べるようにする。

AntのターゲットをRakeのタスクとして呼べるようにする。

一つずつ見ていきましょう。

RakeでAntで定義されているタスクとタイプを呼ぶ

実を言うと、AntはJRubyでは組み込みのライブラリに過ぎません。Rakeで使わないで、スクリプトを書いてしまう事も可能です。

require 'ant'
 
ant do
  build_dir = "java_build" # Regular Ruby variables interact fine
 
  # But defining and consuming Ant properties is fine
  property :name => "src.dir", :value => "java_src"
 
  path(:id => "project.class.path") do
    pathelement :location => "classes"
  end
 
  mkdir :dir => build_dir
 
  javac(:destdir => build_dir) do
    classpath :refid => "project.class.path"
    src { pathelement :location => "${src.dir}" }
  end
 
  jar :destfile => "simple_compile.jar", :basedir => build_dir
end

この例では、Antクラスのオブジェクトを生成して、ディレクトリを作り、Javaのソースコードをコンパイルし、最後にその結果をjarに入れます。これは皆Antのタスクで、全てのプラットフォームで動きます。凄いでしょう。しかしまだ依存関係の管理が欠けています。これはRakeにやらせましょう。

require 'ant'
 
build_dir = "java_build"
file build_dir
 
task :setup => build_dir do
  ant.property :name => "src.dir", :value => "java_src"
  ant.path(:id => "project.class.path") do
    pathelement :location => "classes"
  end
end
 
task :compile => :setup do
  ant.javac(:destdir => build_dir) do
    classpath :refid => "project.class.path"
    src { pathelement :location => "${src.dir}" }
  end
end
 
task :jar => :compile do
  ant.jar :destfile => "simple_compile.jar", :basedir => build_dir
end
 
task :default => :jar

（ここで一つ注意。RakeとAntを両方使える訳ですからAntのプロパティを設定する必要はありません。Rubyの変数や定数を使えばいいんです。十人十色ですね。）

Rakefileの中でAntのタスクを使用するのが如何に簡単かが判ると思います。JRubyのAntライブラリは、Antの元の構文に素直に対応するAPIの集合です。何をどうすればいいのかは直ぐに理解出来るでしょう。

Rakeでは命令型プログラミングが出来るという長所があると既に述べました。このようなAntのコード片について考察してみましょう。

      <java classname="${mainclass}">
        <arg value="--command"/>
        <arg value="maybe_install_gems"/>

        <arg value="--no-ri"/>
        <arg value="--no-rdoc"/>
        %lt;arg value="--env-shebang"/>
      </java>

これを命令型に直すとこんな感じ

command = "--command may_install_gems --no-ri --no-rdoc --env-shebang"
ant.java :classname => "${mainclass}" do
  command.split(/\s+/).each { |value| arg :value => value }
end

もしもあなたがRakeのユーザであるならば、こちらの方を使おうと決断するのは用意でしょう。その他のAntのタスクの中にはJavaらしい事をするのでなくたって便利な物というのもあります。

AntからRakeを呼べるようにする

或るAntプロジェクトと同等の物をRakeを使う事で書けるとしたら、そのプロジェクトをRake主導でやりたいと思うかもしれません。ところが、それでも尚AntからRakeを呼ぶ必要があるかも知れません。そういう時はこのRakeという名前のタスクで切り抜けましょう。

上に挙げたRakefileとbuild.xmlとが共存するという事にすると、そのbuild.xmlの中ではこのようなコード片を使う事が出来ます。

<?xml version="1.0" encoding="UTF-8"?>
<project name="foobar" default="default" basedir=".">
  <description>Builds, tests, and runs the project foobar.</description>

  <target name="load-rake-task">
    <taskdef name="rake" classname="org.jruby.ant.Rake"/>

  </target>

  <target name="default" depends="load-rake-task">
    <rake task="jar"/>
  </target>

  ...
</project>

このAntスクリプトでdefaultターゲットを呼ぶと、まず始めにRakeのタスクが読み込まれ、それがRakeを呼び（ここではデフォルトであるRakefileをインプットとして使います）、それがRakeのデフォルトであるdefault、即ちjarタスクを呼ぶ訳です。これを元にしたシナリオは二つ考えられます。

1. Rakeを少しずつ試用する事が出来る

これは、あなたはRakeが好きだけれども、あなたの所属する開発チーム全体でRakeに移行するよう説得するのは難しいと思われる場合に有効です。何か新しい機能を入れる際にRakefileをプロジェクトの一部として忍ばせておいて、チームの他のメンバーに評価をしてもらうのです。もし気に入ってもらえれば残りを導入すればいいです…よね。Javaを主に使用している部署がビルドのシステムを一気に変えてしまうというのはとても考えられませんから、このように少しずつ導入していくのがよいでしょう。

2. 他のJavaのツールとうまく統合する

もしもあなたがRakeに惚れ込んでいたとしても、NetBeans等のソフトウェアは、あなたのプロジェクトとうまくやって行くためにはbuild.xmlがある事を大前提としています。このような繋ぎがあれば、あなたのプロジェクトとAntを前提としているツールとの相性はばっちりです。

RakeのタスクをAntのターゲットとしてインポート出来るようにする

上のRakeのタスクの大きな欠点は、それが一方通行であるという点です。Rakeを呼ぶ事は出来ますが、Rakeの側からはAntとは大した接触が有りません。Antのタスクを呼べはしますが、プロパティや他にどのようなAntのターゲットがbuild.xmlに定義されているのか等はさっぱり判りません。

よりよい相互運用の為にはRakeImportというもう一つのAntタスクを使います。RakeImportを使うには、定められたRakefileと、それにより定められているタスクをAntの依存管理システムに登録する必要が有ります。例を見てみましょう。

<?xml version="1.0" encoding="UTF-8"?>

<project name="foobar" default="top-level" basedir=".">
    <description>Builds, tests, and runs the project foobar.</description>

    <taskdef name="rakeimport" classname="org.jruby.ant.RakeImport"/>

    <rakeimport/>

    <target name="top-level" depends="its_in_rake" />

    <target name="its_in_ant">
      <echo message="ant: its_in_ant"/>
    </target>

</project>

このファイルでRakeImportを用いる事を明示して、その後直ぐにこのタスクを呼びます。これにより以下に示すRakefileを読み込むと、そこに書かれているタスクの全てがAntに登録されます。

task :its_in_rake => [:setup, :its_in_ant]  do
  puts "it's in Rake"
end

task :setup do
  puts "setup in Rake"
end

ここでant top-levelを呼ぶと、以下のような結果が画面に出ます。

Buildfile: build.xml
[rakeimport] (in /Users/enebo/work/akakamiari/samples/rake_import_example2)

setup:
setup in Rake

its_in_ant:
     [echo] ant: its_in_ant

its_in_rake:
it's in Rake

top-level:

BUILD SUCCESSFUL
Total time: 7 seconds

これを見ると、AntのターゲットとRakeのタスクの両方が好ましい順序で実行されているのが解ります。its_in_antはits_in_rakeの従属性として実行され、そしてits_in_rakeはAntのターゲットであるtop-levelの従属性として実行されているという具合です。

このレベルでの統合におけるシナリオは

1. 最適のツールを選べる

Rakeは命令型プログラミング環境を与えてくれますから、Antでは煩わしい（または自分でAntタスクをカスタマイズしなければ不可能な）事が非常に簡単に出来る事があります。そうしたものはRakeに移管しつつ、Antは残りの物に使う事が出来ます。

2. Rakeに完全に移行する

前の節で、開発チームにRakeの有用性を示す為にRakeタスクを使いました。これにより、Antの依存グラフにRakeの機能を頼みとするタスクを滑り込ませていく事が出来ているでしょう。あなたのグループは主なビルドのツールとしてAntを使っているのでしょうが、Rakeに任せる部分が大きくなってきています。

RakeからAntを呼べるようにする

ではここで反対側から見てみましょう。もしもあなたがすでにRakeのユーザであって、既存のAntファイルと拘わらなければならないならば、ここに良い解決策が有ります！先ず第一の方法ではAntをRakeから直接呼び出せます。

task :call_ant do
  ant '-f my_build.xml my_target1'
end

もう一つの方法では引数を渡す事も出来ます。

args = ['-f', 'my_build.xml', 'my_target1']
task :call_ant do
  ant args
end

信じられないかも知れませんが、ここでは`ant`を実行しているだけではありません。antは実際にJRubyの環境内部へと読み込まれているのです。JVMをもう一つ起動させる手間が要らないのが素晴らしいです。

この節の始めに書いた通り、Antを呼び出すだけでいいとあなたが思うのならばそれでも構いません。でももっと深く拘わりたいのなら…

AntのターゲットをRakeのタスクとして呼べるようにする

ant_importは、Rankeの依存管理システムにAntの最上層のターゲットを登録するという点に於いて、antに優っています。一度AntのファイルをRakeにインポートしてしまえば、Antのタスクを単なるRakeのタスクであるかのように呼び出す事が出来ます。簡単な例を挙げます。

task :ant_import do
  ant_import
end

task :compile => [:ant_import, :its_in_ant_setup] do
  # Do some compilation
end

この例ではcompileというRakeのタスクが実行されるとant_importというタスクを読み込み、それが今度はディレクトリにあるbuild.xmlを読み込み、そしてAntのターゲット全てを読み込んでいます。ant_importを最上部で使わないのは、Antを使う必要がない時にはAntのターゲットを読み込むような無駄を避ける為です。

細かい所を…

このコードはJRubyのトランクにコミットされたばかりです。この記事に書いてある例は全て動く筈ですが、何しろ新しいのでJRuby 1.5がリリースされるまでは多少の仕様変更があるかも知れません。ですから以下の二点を心に留めておいて下さい。

1. バグを発見して、このライブラリを改善する手助けをして下さい

もしこのライブラリに興味があるのなら、早いうちからプロジェクトに関わって、問題点を正したりライブラリを向上させる事が出来ます。この統合が凄いものになるか、ただ「良い」ものになるかはあなたの参加に掛かっているのかも知れません。

始める際の注意点を挙げます。現在の仕様ではjruby-complete.jarを$ANT_HOME/libにコピーするのが最善だと思います。jruby-complete.jarを含むようにクラスパスを設定する事でも可能ですが、コピーした方が手っ取り早く、間違える危険を低く抑える事が出来るでしょう。

2. 作りかけのソフトウェアを好まないのならJRuby 1.5をリリースを待って下さい

作りかけのソフトウェアを煩わしく思ったり、いじくったりする時間のない人たちも少なくありません。そうだとしても、ご心配は無用。1.5リリースまでには上手く動くようにします。中途半端な物をリリースして後味が悪くなったりしないように努力します。

最後に

始めにミスターポテトヘッドの話をしたのは、色々な部品を組み合わせるのが時として最善の策だという事を示す為でした。理論的には、一からやり直して一貫性のある純粋な物を造り上げる事が出来れば良いのでしょう。でも実際的には、実生活での細かい事が常に邪魔をするもの。そんな時、全部書き直してしまうよりは、新しい技術を噛み合わせるという手があります。古い物を長期的な視野で置換するのなら、少しずつ変えていくのも良いでしょう。私が過去に携わった大規模な書換えプロジェクトは悉く失敗しました。部品を一つ一つ変えていくほうが成功の確率は高いのです。

このRakeとAntとを統合するプロジェクトは、こうした小規模な変更を（或いは、二つのツールのそれぞれの良い部分を掻い摘んで使う事を）可能にします。また、この二つのツールはどちらも欠く事が出来ないのかも知れない、或いは、二つのツールのうちの一つをもう一つで完全に置き換えてしまうのは100%良い解決策ではないのかも知れない、という現実を具現化しています。

質問、コメントはいつも通り大歓迎します。

大忙しの一週間。アンドロイド、Maven、Rake、C拡張、そして…

2010-01-10T00:41:00.001-06:00

原文：　チャールズ＝オリバー＝ナター

（最後のブログ記事からどれ位経ったでしょうか?正解は「長い間」。カンファレンス続きで大忙しだった秋が終ったので、もっとブログを書くつもりです。これからは、一月に三つも会議に出かけないように忠告して下さい。）

やあ！この一週間はとても忙しかったです。でも、僕らは元気でせっせとコード書いてるって解るように、JRubyで何が起こってるかを見ていきましょう。

アンドロイド

今週の頭にJan Berkelの手伝いをやってRuboto IRBを最新のアンドロイド携帯環境で走らせる事に成功しました。細かい手直しが二つ三つ必要だったのと、Janが手伝うのに興味があるというので、この変更を追加して彼をRubotoのコミッタに追加しました。

Ruboto IRBのレポジトリはこちら→http://github.com/headius/ruboto-irb

最近、アンドロイド上で動くJRubyに対する私の興味が増してきました。極最近の事ですが、JRubyはJVMで動くメジャーな言語の内ではアンドロイド携帯で動いている間に新規のコードを作って動かす事が出来る凡そ唯一の言語なのだと思い至ったんです。GroovyやScalaやClojureでは双方向型のシェルを造るのは不可能。というのも、これらの言語はソースコードを一旦JVMのバイトコードにコンパイルする必要があって、JVMのバイトコードはDalvikのVMでは直接には動かないからです。

今週Ruboto IRBをいじくってて、もっと面白い事に気がつきました。以前にJRubyがアンドロイドで上手くいかなかった原因となっていたバグのほとんど全てが解消されていたのです!特筆すべきはandroid.*で現されるクラスにリフレクションが、アンドロイド1.6とアンドロイド2.0両方に備わった点が挙げられます。これがどうして凄いか、っていうと、Ruboto IRBを使うことでアンドロイドAPIの何でも弄くる事が出来るからです。

この例はアンドロイドActivity（Ruboto IRBの中のIRBクラス）にアクセスして、新しいWebViewインスタンスを造り、ちょっとしたHTMLをロードしてWebViewの中身を入れ替えています。それもユーザからのインプットを使って。携帯の上で。凄いです。

皆さんが、このRubotoの凄い力を悪用することなく、善の為だけに使ってくれると信じています。

RubyGemsとMavenの連携

JRubyの第一の使命はRubyの実装です。その結果、Javaプラットフォームとの統合を蔑（ないがし）ろにすることが時としてありました。でも、Ruby 1.8.7との互換性がガッチリとしてきて、1.9への取り組みが本格的になってきた今、Javaに再び目を向ける時がやって来ました。

プログラミング言語との統合を図る上で欠かせないのが、その言語を取り巻くツールをどうサポートするかです。そして、Javaでツールと言えば、必ずMavenが絡んできます。

一年ほど前、MavenのアーティファクトをRubyGemsに取り入れるプロジェクトを始めました。MavenのアーティファクトとRubyGemsの対応は簡単に解ると思います。どちらにも依存性、名前、叙述、個別ID、バージョン、そして各々のパッケージを記述する決まったフォーマットが有ります。maven_gemプロジェクトは、この二つの世界の融合が可能であることを証明するものです。

maven_gemのレポジトリはここ→http://github.com/jruby/maven_gem

このプロジェクトはこの秋に私が再び触れるまで埃を被ったままでしたが、Sonatypeの人たちに興味を持ってもらえたのをきっかけに、急速な進歩を遂げています。

SonatypeのTamas Cservenak氏の御陰で、不可能だと一度は諦めていた事も可能になりました。それは、RubyGemsと全てのMavenアーティファクトとの完全な融合です。

Nexus RubyGemsのレポジトリはここ→http://github.com/cstamas/nexus-ruby-support


~/projects/jruby ➔ gem install com.lowagie.itext-rtf
Successfully installed bouncycastle.bcmail-jdk14-138-java
Successfully installed bouncycastle.bcprov-jdk14-138-java
Successfully installed bouncycastle.bctsp-jdk14-138-java
Successfully installed com.lowagie.itext-rtf-2.1.7-java
4 gems installed
Installing ri documentation for bouncycastle.bcmail-jdk14-138-java...
Installing ri documentation for bouncycastle.bcprov-jdk14-138-java...
Installing ri documentation for bouncycastle.bctsp-jdk14-138-java...
Installing ri documentation for com.lowagie.itext-rtf-2.1.7-java...
Installing RDoc documentation for bouncycastle.bcmail-jdk14-138-java...
Installing RDoc documentation for bouncycastle.bcprov-jdk14-138-java...
Installing RDoc documentation for bouncycastle.bctsp-jdk14-138-java...
Installing RDoc documentation for com.lowagie.itext-rtf-2.1.7-java...

これを使ってRhinoをインストールし、それをirbで使うとこんな感じです。
http://gist.github.com/271764

この事がJRubyユーザにとって意味する事は重大です。JRuby 1.5以降では、公にアクセス出来るMavenレポジトリから、Javaのライブラリを、インストールまたは依存するライブラリの一つとして利用する事が出来るようになるのです。端的に言うと、6000を超える数の新しいライブラリをすぐに使えるということです。凄いでしょう?

このプロジェクトはもう幾つか不具合（例えば、RubyGems自体が6000ものgemを含む索引を生成するのに苦労する点）がありますが、テスト用のサーバは既に動いています。JRuby 1.5RC1がリリースされるまでにはこのような点は解消するつもりです。興味のある人はJRubyメーリングリストへ是非参加して下さい。

Rake?Ant?両方やろう！

Javaとの統合についてのもう一つ触れておきたいのがトム＝エネボ氏がやっている、Rake（Rubyにおけるビルドのツール）とAntをシームレスに、相互に統合するプロジェクトです。これには以下の三つの側面が有ります。

RakeのタスクをAntで、逆にAntのタスクをRakeで使う。

RakeのターゲットをAntから、逆にAntのターゲットをRakeから呼び出す。

RakeとAntの両方を混ぜ合わせたビルド方式の構築

トムの作業はこれまでの所、第一点に焦点を合わせていましたが、他の二点についても作業が進んでいます。近いうちに、AntのスクリプトをRake用に書き換えて何の修正も加える事なく使えるようになったり、AntからRakeを呼び出したり、RakefileをAntターゲットの一つとして使用したり、といった事が可能になります。

Rakeからbuild.xmlの内容を導いて、ターゲットに拠ってはAntのタスクを呼び出すような例がこれです。


require 'ant'

ant.load 'build.xml' # defines tasks :mkdir + :setup in ant!

task :compile => [:mkdir, :setup] do
  ant.javac(:srcdir => src_dir, :destdir => "./build/classes") do
    classpath :refid => "project.class.path" 
  end
end

理想的には、統合する上で考えられるあらゆる場合にも対応して、RakeとAntの境界線をあやふやな物にしたいと考えています。ゆくゆくはJRubyのビルドをRakeに移す事が出来れば、皆が喜ぶでしょう。これもJRuby 1.5でリリースする予定です。

C拡張の問題

後回し後回しにしてきたRubyの側面の一つが、C拡張です。C拡張のユーザやデベロッパへの悪意からそうしていたのでは決して有りません。何かのスイッチ一つでC拡張が魔法のように使えるようになったらどんなにか素晴らしいでしょう。問題なのは、RubyのC拡張のAPIがオブジェクトの内側を露呈し過ぎてしまって、そのようなAPIを小さいコストで提供するのが不可能であるという事。（なぜかというと、一つ一つの操作にメモリをコピーする必要が生じてしまうから。）

代替案として模索しているのは、「C拡張APIのうち、『安全』な物をサポートし、『危険』な物については、それに取って代わる物を提供しよう」というもの。これを実現する為、ウェイン＝マイスナー氏によりC拡張APIとの繋ぎとなるライブラリがgithubに発表されました。

レポジトリはここ→http://github.com/wmeissner/jruby-cext

昨晩ちょっとこれに時間を割いてMac OS Xで動かしてみました。自分でやって驚いたんですが、（非常に）些細な物を動かす事が出来ました!

Cで書かれている部分がこれ。MRI用に書くのとちっとも変わりません。


#include <stdio.h>
#include <ruby.h>
 
VALUE HelloModule = Qnil;
VALUE HelloClass = Qnil;
 
VALUE say_hello(VALUE self, VALUE hello);
VALUE get_hello(VALUE self);
 
void
Init_defineclass()
{
    HelloClass = rb_define_class("Hello", rb_cObject);
    rb_define_method(HelloClass, "get_hello", get_hello, 0);
    rb_define_method(HelloClass, "say_hello", say_hello, 1);
}
 
VALUE
say_hello(VALUE self, VALUE hello)
{
    return Qnil;
}
VALUE
get_hello(VALUE self)
{
    return rb_str_new2("Hello, World");
}

これを読み込んで実行するRubyのコードがこれ。ModuleLoaderについての部分は最終のリリースバージョンではrequire/loadとして隠してしまう予定である事に注意して下さい。


require 'java'
 
m = org.jruby.cext.ModuleLoader.new
m.load(self, "defineclass")
 
h = Hello.new
puts "Hello.new returned #{h.inspect}"
puts "h.get_hello returns #{h.get_hello}"

C拡張APIのうち、JRubyではサポートする予定のないのは、RSTRING、RARRAY、RHASH等の文字配列、配列、ハッシュの内側へのアクセスを可能にする物や、Rubyのスレッドやランタイムに関する物などです。つまり、JNI（JVMのC拡張API）にそぐわない物はサポートする予定はありません。

これはC拡張を使用するユーザが主導のプロジェクトです。JRubyにおけるC拡張APIの実現に興味があるのなら、是非僕らに協力して下さい。僕らはJavaとRubyのサポートに忙しいばかりでなく、C拡張を書く事自体にはあまり慣れていません。上に挙げたレポジトリを覗いてみて、JRubyのメーリングリストに参加してください。力を合わせてやっていきましょう。

2010年のJRuby

この他にも2010年のJRubyには目玉が一杯です。コンパイルしたり、シリアル化したり、注釈を付けたり、設定ファイルで指し示す事が出来る、「本物」のJavaクラスをRubyのコードで作り出す事が可能になるでしょう。JRubyを商用している人達向けに、サポートの提供（バグの優先順位の決定等の参考にします）も始める予定です。Engine Yard CloudからJRubyを使った（Ruby以外のライブラリや、Java、Scala、Clojureのコードをも使える）手軽なクラウド商品も発売されます。そして、漸くJRubyの本も書きます。これにはチュートリアルや、リファレンス一覧、トラブルシューティングのヒント等、JRubyを今使いこなす為に必要な事項を盛り込む予定です。

素晴らしく、そしてワクワクする一年になりそうです。

JRubyのJはJVMのJ

2009-12-01T20:01:00.001-06:00

原文：トム＝エネボ

現在JRubyの開発に携わっている面々は皆Ruby、Java、そして勿論JRubyを熟知している情熱的なハッカーばかりです。とは言うものの、このプロジェクトの創成に関わった者は一人も居ません。JRubyの先駆者たちはそれがいいアイディアだったと考えたに違いありません—私もJRubyのことを初めて耳にした時そう思いました。ところが多くの人にとってはこれはそう自明の事では無いのかも知れません。そういう人たちは「JVMの上でJRuby書いていい事なんかあるのですか」と訊きます。僕らJRubyチームはちょっとネジが外れてるか、狂気の天才なのか、それともJVMを使うのは至極実利的な決断なのでしょうか。

Javaは登場した当時、存在していたプログラム言語をちょっと良くしたような物でした。Javaはそこそこ簡単であり、かつ既によく使われていたCやC++を進化させたような物であるにも拘わらず、ハードウェアに中立なバイトコードを走らせる事の出来る仮想マシンでした。ガーベージコレクションがJavaには実装されていたので、メモリ管理やコアダンプに大して気を捕らわれなくなりましたし、加えて中々総括的なライブラリを持っていました。特に目新しい物は無かったのですが、既にあったアイディアを上手い具合に組合わせて使える物になっていたと言えるでしょう。

これは私見ですが、このように二つの異なる物をJavaと言う一つのブランドで売ろうとしたSunのマーケット戦略は長い目で見ると失敗でした。この戦略では、プログラム言語とランタイムが全く同一の物であるかのように同じ名前で呼ばれる事になっていたのです。この戦略は、ランタイム（それ自体で充分に利点の有ったJava仮想マシン）にとって非常に不公平な物でした。更に、JythonやJRubyの様にJVMを基にしたプログラム言語が、プログラム言語としてのJavaとの混乱を招く事無しにJVMの良さを説明する事が出来なくなるという結果にもなりました。

本稿ではJVMの良い点と悪い点について触れることにして、JVMの姿を読者が垣間見る事が出来ると良いと考えます。

本題に移る前にもう一言。本稿で扱うのはSunのJVMについて私の知っている事に限っています。Sun以外からもJVMはリリースされていますし、それぞれに良さが有ります。私が以下に挙げる点の多くはそうしたJVMにも当て嵌ると思われますが、私がそうしたJVMの詳細に暗い事は断っておきます。

短所

完璧なテクノロジーは存在しません。JVMも勿論例外ではありません。JVM上でJava以外の言語の実装をした事のある人ならば、その苦労は解ると思います。プログラム言語実装に便利な基盤をJVMは提供してくれますが、元々はそうした用途を想定してデザインされている訳ではありません。その為、独創的な問題解決を余儀なくされる事が時としてあります。

例えば、JRubyではフレームスタックの実装にヒープ領域から割り当てられたオブジェクトを使っています。融通が利くのならば、本物のフレームスタックを直接操作し、JRubyに必要なフィールドを加えるところです。JVMではフレームスタックをそこまでは操作できません。残念。

他には、RubyでのFixnumオブジェクトを造る際、これらの値をボックス化してJavaのオブジェクトに内包させています。RubyのC言語での実装では単にタグの付いたintを渡すだけで済みます。もっと高速のFixnumがあれば良いのですが、Javaの原始型では一般的なリストに入れる事が出来ませんから、これを使う訳には行きません。

ちょっと差し挟んで言うと、JVMの起動にはかなりの時間が掛かる事も問題です。

JVMで速いコードを書かなければならない人の中には、VMの中の動きがよく解らない事に業を煮やした経験のある人も居るかも知れません。一度バイトコードをロードしてしまった後は、ただスイッチを入れて良い結果が出る事を祈るだけです。どのような結果が出るのか予測する事は難しいです。

小言を並べてみました（勿論この他にも改良されるべき点は色々とあります）が、JRubyがJVMの上で実装されていると言う事に私はとても満足しています。何故でしょうか。それは…。

長所

HotSpot

先ず始めにHotSpotについて述べます。HotSpotには神秘的な物がありますが、一般に高いパフォーマンスの実現に一役買っている事は間違いありません。動的にプロファイリングを行うのは高いパフォーマンスへの近道です。HotSpotは我々などより遥かに賢く、しかも走っているアプリケーションのデータを使って最適化の一助とする事も出来るのです。

HotSpotには既に最適化されているコードを非最適化する機能もあります。奇妙に聞こえるかも分かりませんが、これが高いパフォーマンスを可能にする要因なのです。HotSpotが最適化をする時、始めに最適化された部分のコードの前に簡単なガードを置いて、最適化の為に用いた前提条件が本当に満たされているのかを確認します。このガードが満たされなかったりした場合、HotSpotはこの部分のコードを非最適化します。何故これが凄いかというと、この性質の為にJVMは、最適化にとても積極的になる事が出来るからです。もしHotSpotの「勘」が当たると、その配当はとても大きいです。「勘」が外れても、今一つズレている最適化を試してみたという多少のコストを払って、後々の最適化に役立つ情報を手に入れた後、最適化していた部分を元に戻すだけで済みます。

このHotSpotの働きを示すのが下のグラフです。

このグラフに示すのはマンデルブロ集合を描く作業を何度か繰り返した、その所要時間です。グラフの右側でJRuby1.4.0を見ると、Ruby1.8.7を明らかに凌駕し、またRuby1.9.2preview2といい勝負をしているのが解ります。JRubyのグラフを追うと、Ruby1.8.7にテスト開始直後こそ後れを取っているものの、HotSpotがその機能を発揮するにつれて急速に追いつき追い抜いていく様が手に取るように解ります。

六度目のテストでJRubyの結果が少し悪くなっています。これは先に述べたHotSpotの非最適化の結果です。七度目以降は結果が五度目程度まで回復しているのも判るでしょう。七度目以降の最適化で六度目のテストで発生した非最適化の部分を総て取り戻す事が出来たのです。

HotSpotに匹敵するものを書く事は私には無理でしょう。数多くの優秀なエンジニアたちによって十年近くの歳月を掛けてHotSpotは磨き上げられました。実際、Java４、５、６でHotSpotは見事な進化を遂げました。JRubyはHotSpotを何もせずにタダで使う事が出来るだけでなく、HotSpotがアップグレードされる度にその恩恵を浴びる事が出来るのです。これはJVMを使えばこそ。完璧なテクノロジーなど無いとは言いましたが、これはかなりそれに近いと思います。これはまだ小手調べ。ガーベージコレクションに言及もしていません。

ガーベージコレクション

Javaの開発者たちは、それこそ数世紀に値する時間を掛けて仮想マシンをデバッグし、テストし、改良してきました。15年もの間、ただガーベージコレクション（以下GC）の為だけに働くエンジニアが詰まった建物を想像してみて下さい。Java仮想マシンには沢山のガーベージコレクタが梱包されていますから、一つのコレクタで上手く行かなかったとしても、JVMではその他のコレクタを使う事が可能です。更に、コレクタを一つ一つ調節する事も出来ます。アプリケーションによってコレクタを自由に使い分ける事が可能なのです。
コレクタの数々にはとても具合の良い属性があります。コレクタの総てはコンパクションを行いますからメモリの断片化は問題ではありません。インクリメンタルでもありますからGCが実行される際にアプリケーションが止まる時間の長さも最小限で済みます。世代別ガーベージコレクタですので、短時間しか必要のないオブジェクトは直ぐに回収されてしまいます。

コレクタの幾つかは並行型でマルチコアの特性を活かす事が可能です。中には同時処理が出来るのでGCの為にアプリケーションを止める必要のないものもあります。こうした素晴らしいコレクタ等も数多のアプリケーションで既にその性能を実証済みです。JRubyではこうしたもの総てをタダで使う事が出来るのです。Java 7（及びJava 6u12）ではG1と呼ばれる新しいコレクタも登場しています。JavaのGCは今も尚改良が続いているのです。

JVMにおけるGCについて良い点をもう二つ挙げます。どちらもGCの視覚化とどのように作動しているのかに関するものです。一つはJavaで使われる-J-verbose:gcというフラグです。このフラグを使用すると、いつ、どれ位のメモリを、どれ位の時間を掛けて収集したかというGCに関するイベントを総て記録してくれます。これを使うとアプリケーションにおいてコレクタが上手く作動しているかを把握する事が出来ます。


[GC 16000K->3727K(82496K), 0.0396636 secs]
[Full GC 13021K->5802K(82496K), 0.1468975 secs]
[GC 21802K->9769K(82496K), 0.0292348 secs]
[GC 25769K->12535K(82496K), 0.0243674 secs]
[GC 28535K->13136K(82496K), 0.0169928 secs]
[GC 29136K->15498K(82496K), 0.0213308 secs]
[GC 31498K->16911K(82496K), 0.0213301 secs]
[GC 32911K->19413K(82496K), 0.0186457 secs]
[GC 35413K->20207K(82496K), 0.0146396 secs]

記録されたイベントを集計する事によってメモリの収集に全体でどれだけの時間を要したかが判りますし、もしかしたらアプリケーションが課す作業量にGCが着いて行ってない事も判るかも知れません。そうした場合、アプリケーションのデザインの見直しや、ヒープ領域の拡大などを試したりする事にもなるでしょう。

もう一つはjconsoleによってJVMの動きを見る事です。jconsoleにはJVMの内部を覗く為の様々な機能（JVMの動作を操作するものも有ります）がありますが、ここで触れるのはGCの作業具合を見る事の出来る、メモリのタブです。

ウィンドウ右下に、それぞれの世代のメモリの使用量が緑色の棒グラフで表示されています。例えば、上の図で左から三番目の棒が空になっていますが、これはこの世代のメモリが全く回収されずに済んでしまった事を示しています。GCが上手く作動していない事の証左ですので、アプリケーションの改良を検討する必要が有るでしょう。

移植性

HotSpotとGCはJavaを使える環境ならばどこでも使えます。つまり、JRubyは他の環境でもただ単に動くばかりでなく、とても上手く動くのです。このような素晴らしい環境を何もせずに手に入れる事が出来るのは素晴らしい事です。

更にJRubyはちょっと変わった環境でもJavaさえあれば動きます。バグ報告の中にはOpenVMSからの物さえあります。IBMメインフレームのCP/CMSで動くJRubyの話も耳にします。こうした環境で動くというのはちょっと「ヤバい」気がします。これも偏にJVMのお陰と言えます。

実際、Javaのソースコードが公開されてOpenJDKプロジェクトの発足を受けて、JVMは今後も色々なハードウェア環境へと伝播して行く事でしょう。このように、移植性という点でJVMはほぼ完璧と言えると思います。

成熟性

JVMは開発が始まってから15年を経て、大人向け映画を観に行けるような歳ではないかと思います。JavaOneカンファレンスでは、JVMのソフトウェアとしての長寿が、子供が成人して行く様に正しく喩えられていました。過去15年にJVMの安定化と高速化と普及の為に注ぎ込まれた膨大な努力の恩恵に、JRubyは全く何もせずにあやかる事が出来るのです。

JVMチームとの連携

JRubyとその他のJVM上で動く言語は、JVMに携わるエンジニア達にも知られています。一つ例を挙げますと、JSR292としても知られるinvokedynamicという仕様があります。この仕様は、JVM上で実装される新しい言語と、メソッド選択にJava以外の言語も念頭に入れる必要が有る事を明文化するものです。JVMが、JRubyのようなプロジェクトにとってより良いプラットフォームになりたいと考えていると言う事は大変良い事です。

MLVM（多言語仮想マシン）と呼ばれるプロジェクトではJVMでどのフィーチャが採用されるべきかの情報交換が行われています。そこは、野心的なデベロッパがJVMでのフィーチャの実装を試す機会を与えてくれます。JVMのエンジニア達も直接関って、様々な提案もしてくれます。これは新しいJVMフィーチャの培養器と言った感が有ります。

この二つの点は、JVMエンジニア達が、視野を広げ、またユーザーの声に耳を傾けている事を示している事の現れであるということで特に喜ばしいです。

まだまだ続きます

JVMはテクノロジー展望の一部となりました。オラクルによるSunの吸収合併と、それに伴ういざこざをめぐって、中には首を傾げるようなニュースも飛び交っていますが、真相は至ってありきたりです。オラクル、IBM、HP、SAP等々、多くの巨大な企業がJVMで動くミドルウェアの創造に莫大な投資をしているので向こう十年程度でJVMへの拘わり方が変わるとは考え辛いです。

これにより、JRubyの更なる性能の向上が見込めます。加えて、Rubyような言語、或いはRuby on Railsへと市場を導く機会がJRubyには有ると言えます。JRuby開発チームは全力でRubyist諸氏のRubyランタイムへの要望を満たす努力をしています。同時に我々は、Javaを使う人々に、アプリケーションによってはRubyがJavaに優り、しかも使用するプラットフォームを換える必要のない言語である事を伝えているのです。