Nahi's Commit Logs

JRuby 1.6.1 Released

4/12にJRuby 1.6.1がリリースされました。

• http://jruby.org/2011/04/12/jruby-1-6-1.html
• http://jruby.org/download

このblogでは、1.6.0のリリースの紹介はしていませんでした。1.6.0の概略については、この記事にあるプレゼンを参照してください。

1.6.1は、1.6.X系列初のメンテナンスリリースで、全てがバグ修正です。1.6.0をリリースして一ヶ月、集まったバグ報告の中から、互換性に関する問題を中心に対処されています。「せっかくJRubyを試したのに互換性がない！」という声には弱い、というところでしょうか。などと偉そうに書いていますが、1.6.1での修正については私は一切絡んでいません。ここしばらく、JRuby以外のことばかりやってました。

それでは以下、修正点です。

実行環境

• JRUBY-5285 jruby-complete.jarを利用していた場合、jruby -Sによるスクリプト実行で、$JRUBY_HOME/binが検索されていなかったのを修正。irbやrakeの呼び出しでコケていました。
• JRUBY-5607 JRUBY-5609 rubygems mavenサポートのバグ修正。rubygems mavenサポートはまだexperimentalです。
• JRUBY-5608 1.6.0で、IBMのJ9 VMで動かなくなっていたのを修正。
• JRUBY-5651 1JVM内で、複数のRuby VMを同時生成したときにJavaプロパティへのアクセスで例外になっていたのを修正。

CRuby互換性

• JRUBY-2126 JRUBY-2488 JRUBY-4791 irbで、入力済み文字上でのCtrl-D（1文字削除）が効くようにしました。また、irbで1行入力するたびに6 fdがリークしていた（ただしGCでは回収される）のを修正。Javaでのreadline実装である、JLineを更新しました。どうやらCharlesがJLineのメンテナに加わったようです。
• JRUBY-5591 NKFで短い文字列を変換すると、NullPointerExceptionが発生していたのを修正。
• JRUBY-5596 nonblocking readでは、EAGAIN例外が多発します。JRuby 1.6では、スタックトレース保持方法の変更により、通常動作は高速に動作し、例外発生時（バックトレース生成時）に多少遅くなりました。結果として、1.6.0でnonblocking readを利用すると遅くなっていました。EAGAINは通常リトライのために用いられ、バックトレースは利用されないことが多いことから、EAGAIN発生時にデフォルトではバックトレースを生成しないように変更しました。
• JRUBY-5610 TCPSocket#accept_nonblockの修正。たぶん一度も動いたことがなかったものです。nonblock系はもう少し気合を入れて書き直さないといけません。
• JRUBY-5627 read openしたファイルにLOCK_EXでflockした時に、LOCK_SHとしてlockを取っていたのを修正。JVMではOSに寄らず例外です（なのでこれを回避する目的でLOCK_SHにしていた）。CRubyではOS依存で、Solarisだと例外。Railsがこれを使ってしまっていたので、Rails側にも修正を依頼しました（read openしたものをLOCK_EXしないように）
• JRUBY-5634 File.newに渡すオブジェクトがto_intを実装していた場合（例えば__FILE__）に、間違ったファイルを開こうとして刺さっていたのを修正。
• JRUBY-5640 Dir#pos=に負の値を与えた場合には何もしないように変更。
• JRUBY-5687 Process::Status#exitstatusの値が間違っていたのを修正。
• JRUBY-5688 Process::Status#pidを実装。
• JRUBY-5694 DATAをrootファイルでしか初期化していなかったのを、CRuby同様、ファイル読み込み毎に再初期化するように修正。
• JRUBY-5604 jruby -vの表示中のCRubyバージョン表示形式を、CRubyにあわせました。
• JRUBY-5629 バックトレースのmodule/class名表示方法をCRubyにあわせました。
• JRUBY-5637 Exceptionインスタンスがsingleton classを持っている時のデフォルトの例外メッセージがCRubyと異なっていたのを修正。

Java連携

• JRUBY-5597 byte配列に128以上の値を代入できなくなっていました（1.5ではできた）。ubyte_setというメソッドを追加。
• JRUBY-5602 Dir.globでjarに固められたディレクトリの一覧を取得しようとするとエラーになっていたのを修正。
• JRUBY-5649 プロファイラが使うJavaクラスのimportメソッドが、Rakeの同名メソッドと衝突していたのを修正（java_importに）。

C拡張

• JRUBY-5044 JRubyでは、ある条件でsystemコマンドをインプロセスの別Ruby VMで実行します。特にrakeで多く使われます。cextを読み込んでいる場合、複数のVMでcextを読み込もうとして発狂するので、cextを読み込んでいる場合にはインプロセスでのsystem実行を禁止しました（別プロセスで実行します）
• JRUBY-5598 JRUBY-5601 JRUBY-5606 Solarisでもcextをbuild、利用できるようにしました。
• JRUBY-5628 FFI APIの修正。
• JRUBY-5690 cextで参照したmodule/classが、Java側でまだ使っているにもかかわらずGCされてしまう問題を修正。ただし「module/classはGCしない」という対処なので、今後問題になりそうです。

1.9モードの互換性

• JRUBY-5396 YAML解析のバグ修正（CRuby側で修正してJRubyに持ってきた）。
• JRUBY-5590 irb/completionを利用した場合、Java classのメソッド補完をしようとするとエラーになっていたのを修正。
• JRUBY-5624 Class.newに渡したブロックのselfが間違っていたのを修正。
• JRUBY-5632 to_aを持つオブジェクトに対するsplat演算子の挙動を修正。
• JRUBY-5641 Stringの行モード読み込みが壊れていたのを修正。
• JRUBY-5646 RubyString.newUnicodeString（Java拡張用API）の設定するencodingが間違っていたのを修正。
• JRUBY-5648 overrideしたメソッドのsource_location（1.9から）が間違っていることがあったのを修正。
• JRUBY-5680 Kernel.bindingでの"self"のeval結果がCRubyと異なっていたのを修正。
• JRUBY-5682 YAMLの解析エラー時に上げる例外が間違っていて、Bundlerが正しく動いていなかったのを修正。
• JRUBY-5686 -> operator（stabby演算子）の解析に失敗することがあるのを修正。
• JRUBY-5693 **の結果がFixnum範囲にもかかわらずBignumとして返ることがあったのを修正。
• JRUBY-5705 open3ライブラリの修正。

1.6.0のリリースに伴い、「C拡張対応」「1.9対応」（実際は、いずれもexperimental: 実験的ステータス）を謳ったためか、今までJRubyを使ってなかったユーザさんが多く試してくれています。おかげで上記「CRuby互換性」に書いたような、細かいバグ修正が増えた、というところでしょうか。

C拡張と1.9対応についてはバグが出始めて、今後の開発も進みそうです。ていうかお前がやれ、という感じですが。1.9はRuby Spec側の整備も道半ばなので、Ruby Specが通ったとしても、上記のような大きめな問題がごろごろ残っています。また並行して、新中間表現の開発も進んでいますが、こちらはRubyとしての機能には無関係なので、ユーザに見えるような変化は（まだ）ありません。

1.6.1のリリースの後、1.6.Xのメンテナンス用ブランチが作られました。私が作ったMersenneTwister対応など、大きめな開発ブランチもマージできそうです。少しまたJRubyの開発に戻りたいと思います。

Jenkins/HudsonのDroovyが面白い

先週2/24(木)、2/25(金)は、連日で以下の勉強会に参加してきました。

• 第15回 G*ワークショップ
• 第2回 Jenkins勉強会（旧Hudson勉強会）

前者はJVM言語であるGroovy他各種関連プロダクトの勉強会、後者はJavaのCIツール、というか汎用ビルド自動化環境Jenkins（旧名Hudson）の勉強会です。いずれも旬なプロダクトということもあり、発表者のみなさんも大変元気で、楽しませていただきました。JRubyもがんばらないといけませんね。

ちょうどJenkins/Hudson作者の川口さんが帰国されており（というより、それに併せて勉強会が設定されたこともあり）、ほぼ初めてお会いしたにも関わらず、勉強会本編、懇親会含めて、いろいろお話を伺うことができました。

• lightweightな言語が流行っているけど、IDEサポートないとやはり厳しい。Groovyはその点よいが、closureになると型の推測が効かなくなるのが惜しい。
• Jenkins/Hudsonのpatch contribution licenseは？検討しなきゃとは思う。ASFのはやりすぎだし、効果ある？
• SonatypeはHudsonの1年後をどのように描いている？彼らは過去1年maven/hudsonをやってきた。先は読みにくい。
• オープンソースで成功するにはplugin周りに気を使うとよい（OpenRaveの作者さんがいらしていて、懇親会で議論されていました）

中でも特に面白かったのがDroovyです。以下、少し詳しくご紹介。

Droovy

JenkinsとGroovyというトークの中で紹介された、Jenkinsベースの分散計算プラットフォーム。Jenkinsの分散ビルド環境（マスターが全て管理、スレーブはスモールスタートして実行時に必要な情報をマスターからオンデマンド取得）を支えているJenkins remoting技術を使って、データ（serializeして転送）とコード（Javaのcustom class loaderで移送）を共有。さらにGroovyに手をいれてクロージャまで移送可能にして使い勝手を良くしたもの。こんな説明じゃわからないですね。すいません、半分自分向けのメモなので、このくらいで勘弁してください。

当日Droovyのビルドプロジェクトを見せていただいたところでは、Droovyそのものはそれほど大きい物ではなく、各種プロダクトのよいところをhackできれいに組み合わせたという感じに見えました。ソースコードは以前java.netで公開されていたように見えますが、今はいろいろな移転の関係か、見つからないようです。公開されたら是非見てみたい。 [追記] このツイートに気づいてませんでした。Droovyのリポジトリは https://svn.jenkins-ci.org/trunk/experiments/droovy/ ここにあるそうです。[/追記]

名前も似ているし、最初はRubyにおけるdRubyと似た環境なのかな、とも思ったんですが、以下の点が違います。

• dRubyはコードの移送はサポートしていない。
• Droovyではクロージャのリモート実行を、Groovyのクロージャオブジェクトのシリアライズ + 束縛変数群も一緒にシリアライズして転送して実行。

いや、断言してますが、ソースコード見ずに当日お聞きした話だけで判断しているので、嘘かもしれません。Groovyだからフレームオブジェクトにアクセスできるとは言っても、束縛変数群の転送って、そんなに簡単じゃない気がする。

ソースコードについては川口さんに再公開（もしくは、私が見失っているだけならリンク）をお願いしたので、見られるようになったら、Jenkins remotingと合わせて読んでみたいと思います。JRubyで似たようなことできるかな？

 

 

JRuby 1.6の新機能に見るJVM言語の魅力

前回の記事、「JRuby 1.6.0.dev update - cext, dynopt」を書いた後、年越し、会社の引越しなどでバタバタしていました。その間にJRuby 1.6はRC1、RC2とリリースされています。正式リリースまでもう少し。ここのところは新たな機能追加などはなく、RCの品質を高めるための作業が続いています。

そんな中、2/22日に、日本Javaユーザグループ（JJUG）のみなさんにセミナーの機会をいただき、「JRuby 1.6の新機能に見るJVM言語の魅力」というタイトルで発表させていただきました。以下、発表資料です。

JRuby 1.6の新機能に見るJVM言語の魅力 on Prezi

当日は7～80名くらい?の参加者があり、JJUGの影響力の大きさに驚きました。予定の公開後、特に積極的な宣伝もないのに、前週金曜日に参加打ち切り、会場サイズの都合で抽選により人数を絞ってこの人数だそうです。

これまでJRuby関連のプレゼンについては、いただいた20分の中にあれこれ詰め込んで駆け足になってしまう、というのを2度やってきました。今回は60分、ゆっくりと、と思っていたのですが。。。結局また詰め込みすぎて、予定していたデモのいくつかは断念しました。デモ用のソースコード、利用手順は、以下に置いてありますので、よろしければお試しください。

• https://github.com/nahi/jjug-jruby-2011/

デモのいくつかは、OpenJDK7のea版（Early Access版）が必要です。現在入手可能な最新版は、b130になります。ただ、ここのところのbuildは、（JRubyにとっては）肝心のinvokedynamic周りのinline化にバグがあって、残念ながらJRubyのinvokedynamicオプションをonにしても、通常のJRubyより速くなりません。dynoptとinvokedynamic、突き詰めるとどちらが速いでしょう、とかいう話も、いずれブログに書きたいと思います。

JRuby 1.6.0.dev update - cext, dynopt

12/27、JRubyユーザ会の第4回のmeetupが、楽天さんの会議室をお借りして行われました。

日本JRubyユーザ会はHadoop Hapyrusの藤川さん（@fujibee）の幹事の元、楽天技術研究所のみなさんのご協力をいただくなどして場所をお借りし、2ヶ月に一度集まって発表と懇親会を行っています。まだまだ小さなコミュニティで、今回も20人弱程度の参加でした。ほどほどのタイミングで開催され、小規模で、しかしRuby方面やJava方面、Hadoop方面など多様な人たちが集まっているので、毎回濃い話が聞ける/できる、楽しい集まりです。

以下、最近のJRuby 1.6の開発動向について少し話してきたので、話し足りなかったことも含めてその報告を。

JRubyの現在の安定版は1.5.6ですが、時期リリース向けの1.6の開発も着々と進んでいます。正直、私がやってるのはほぼバグ修正ですが、大きな機能追加、大規模な改修が多数含まれます。

• cext - C拡張
• dynopt - 動的最適化
• backtrace - バックトレース
• IR - 新中間表現
• profilers - 各種プロファイラ

以下、それぞれについて説明します。

 

cext - C拡張対応

最初はC拡張です。JRubyから、CRuby向けに書かれたC拡張ライブラリを利用する仕組みです。利用しているのはFFIという、Cのライブラリを動的にバインドしてRubyから呼び出すための仕組みで、CRubyでも使われています。JRubyのcextではこれをJavaのJNI経由で呼び出せるようにし、また、gemインストール時に適切にビルドできるよう調整します。

C拡張機能を利用するには、現時点では自分でビルドする必要があります。以下の例の先頭にあるように、gitからmasterブランチをcloneしてきて、"ant jar"でJRuby本体をビルドした後、"ant cext"でC拡張をビルドしてください。これでC拡張が使えるようになります。

curbという、curlライブラリをwrapしたCRuby用拡張ライブラリがあるのですが、これをJRubyのgemとしてインストールしています。JRubyでgemをインストールしていて、"Building native extensions.  This could take a while..."を見たら、エラーでストップして挫折を味わうところでした。これからはなんとかなります。

その後、C拡張のcurbと、Rubyで書かれたhttpclientでベンチマーク比較をしています。3Gの遅い回線でのテスト、かつ一セット実施しただけなのであまり参考になりませんが、JRubyとCRuby（1.9）で、curbの速度は変わっていないのがわかるでしょうか。以下がベンチマークスクリプトです。

まだ、うまく動かないC拡張も報告されているので、成熟してくるのはまだ先です。JRubyだと、FFI側でのメモリリークも心配ですが、今までJRuby移行の壁になっていたC拡張に解決の兆しがあるのはいいことです。

 

dynopt - 動的最適化

次は動的最適化の例。ただしこの例は、日本語JRubyの記事「JRubyのパフォーマンスの更なる向上を目指して」と変わりません。この分野についての進捗は、リンク先の記事を書くためにCharlesがガーっと実装してから、機能的にはあまり変わってません。もちろん洗練化はされましたが、現時点ではデフォルトでは無効にされている機能ですし、1.6正式リリースでの扱いがどうなるか。私もこのあたりまで手を出せるともっと面白いんでしょうが、さすがに趣味の範囲だときつい。

上記事例では、フィボナッチ数の計算を、再帰で実装したもの（fib_recursive.rb）とループで実装したもの（fib_iterative.rb）を、動的最適化有効の場合（-J-Djruby.compile.dynopt=true）と、無効の場合（デフォルト）で比較しています。再帰の場合には速度が倍になり、ループの場合にはほとんど変わらない、という結果になっていることがわかるでしょうか。実際のスクリプトは以下の通り。

再帰だと効果が出てループだと効果が出ないということから、動的最適化に関して今の私に推測できるのは、以下のことです。

• リンク先記事の「第一段階：動的呼び出しを静的呼び出しに置き換える」と「第二段階:Fixnumの使用を抑える」は、今回の例のような小さなスクリプトだと、JVM側での最適化でも十分効果がある。もしくは全然効果がない。
• リンク先記事の「第三段階:極小最適化をちょこちょこと」に含まれる、末尾再帰のショートカットは大変に効果がある。

動的最適化については、とりあえず概念実証ができたものの、効果的な実装のためには、後に述べるbacktraceやIRが先行しないと厳しい、といったところです。長い目で見てやってください。

と、2ネタ書いたところで力尽きました。その他については次の記事で。

httpclient 2.1.6 released

httpclient/2.1.6をリリースしました。

• RubyGems
• 2.1.6変更点
• リリースノート

2.1.5のリリースが2009年6月なので、1年以上ぶりのリリースです。1年前、JRubyでhttpclientのSSLがうまく動かず、調べて直しているうちにjruby-opensslのコミッタになり、gzip/zlib/digest/Threadがうまく動かず、調べて直しているうちにJRubyのコミッタになり、CRubyも完全にほうっておくわけにいかず、などとやっているうちに1年たってしまいました。

httpclientは、RubyでHTTP通信を行うのに必要な機能を実装したライブラリです。Rubyのみで書かれており、標準添付のnet/httpに比べて機能が豊富にも関わらず、Cによる実装を含めた各種実装とほぼ同等の速度で動作します（動作しなかったら教えてください。がんばります）。ある時期、Ruby 1.9ではcurlをwrapしたcurbより速かったんですが、今はどうかな。。。

httpclient固有の機能としては、HTTP-Cookiesサポート、真のSSLサポート（信頼する証明書同梱）、スレッドセーフ、HTTP Keep-Alive利用による低リソース高速動作、非同期API、DigestAuth/NTLM/OAuthなどの認証サポート、IOによるstreamingリクエスト送信などがあります。CookiesやKeep-Alive、認証、streamingは内部で透過的に行われ、ユーザが意識する必要はありません。必要になれば、各種プロパティで挙動を制御できます。また、通信フィルタを利用して独自拡張することもできます。各種利用方法については、APIドキュメントを参照してください。

今回のリリースでは、OAuth対応を行いました。以下は、Twitterにアクセスするためのサンプルです。

関係オブジェクトが出たり入ったりするOAuth gemに対し、OAuthClientオブジェクトを中心にした利用方法になっています。OAuthClientはHTTPClientのサブクラスなので、セットアップが済めば、HTTPClientと同じように、get/post/deleteを利用できます。

この他、Google BuzzやFriendFeedにアクセスするためのサンプルコードも含まれています。私自身は試していませんが、FoursquareやHatenaなどもOAuth認証によるAPIを持っているので、サンプル先頭のURLを変更するだけで使えるはずです。ざっと作るにはOAuth gemやTwitter gemを利用するほうが手軽ですが、通信ログを取りたい、通信リソースを自分で管理したい、SSLを安全に利用したいなどの場合には役に立つはずです。

その他、Keep-Aliveでの接続管理のバグが修正されていますので、旧バージョンを利用されている方は、是非バージョンアップをお願いします。

これまで、httpclientについては、日本語での情報をほとんど出していませんでした。私自身が各種重宝していることもあり、まだしばらくメンテナンスしてきます。この機会に質問などあれば、聞いてください。可能な限り答えます。

JRuby+Twitter4J

JRubyでTwitterのAPIにアクセスしてみましょう。RubyであればTwitter gemというライブラリがありますが、これがJRubyでも動くのは当たり前。そこで、Javaで使われるTwitter4Jというライブラリを使います。

OAuthの説明はここではしません。まずはアクセストークンを取得して、twitter.cfgというファイルに保存するコード。先にhttp://twitter.com/appsにアクセスして、コンシューマートークンを取得しておいてください。

JRubyからJavaのライブラリを使う場合、まずrequire 'java'しておいて、jarファイルをrequireします。またJavaのクラスを利用するには、'twitter4j.TwitterFactory'などの完全修飾名を使いますが、java_importメソッドを使うと、定数名としてインポートすることができます（Javaのimport宣言に似ています）。

次にタイムラインを取得して（デフォルト20件）、画面に表示します。先ほど保存したtwitter.cfgファイルを読み込んで使います。

Javaのメソッドは通常camelCaseですが、snake_case形式で呼ぶことができます。例えばgetAuthorizedOAuthInstance→get_authorized_oauth_instanceなど。手を入れたい場合は、Twitter4JのJavaDocを眺めつつ、本家のドキュメントを読みましょう。Twitter4Jのメソッド名などは本家APIに揃っているため、本家のドキュメントを読めばたいていのことはわかります。

速度を見てみます。Twitter gemとの比較です。

これをCRubyとJRubyで走らせた結果。

Twitter4J、速いですね。Twitter gemはCRubyでも遅いのですが、JavaとRubyで倍以上、となるとさすがに何か、構造的な問題がありそうです。そのうち調べてみましょう。

JRuby 1.5.6 Released

先週末、JRuby 1.5.6がリリースされました。

• http://jruby.org/2010/12/03/jruby-1-5-6.html
• http://www.jruby.org/download

今回も基本的にバグフィックスリリースで、以下の修正が入ってます。今回は大変細かい修正です。

• JRUBY-4352 [Windows] Windows 2008 Server上では、rbconfigライブラリのConfig::CONFIG['host_os']が"Windows Server 2008"になっており、"mswin32"ではなくなっていました。Windowsかどうかを判定するイディオムとして「host_osにmswin32またはmingwが含まれている」というものがあり、これに該当しないためにWindowsとして認識されていなかった、という問題がありました（具体的にはrackなど）。"mswin32"になるように修正されました。
• JRUBY-4774 classpathまたは$LOAD_PATHに空白を含むパスが入っている際、jarファイルの読み込みがエラーになっていたのが修正されました（通常のRubyの範囲では問題ありません）。URLのエンコーディングの扱いの修正なんですが、結構広範囲に効きそうな変更なので、1.5.6でjarファイルの読み込みの挙動が変わったらこれを疑ってください。
• JRUBY-4898 ObjectSpace.each_objectにModuleを指定し、そのModuleをincludeしているオブジェクトをiterateする際、与えられたblock内で新たにModuleを定義するとConcurrentModificationException例外になっていたのを修正しました。VMが保持している全モジュールがWeakHashSetになっており、そこへの書き込みで発生します。修正は、全オブジェクトを検索し終えてから個別に与えられたblockを評価するようにする、というものです。正直なところ、それもどうなのかという感じではありますが、元々「Rubyの暗黒面」と呼ばれる機能ですのでよいことにしましょう。何か問題があるようであれば報告してください。 
• JRUBY-5127 require ‘java’およびrequire ‘jruby/core_ext’すると使える、Class#become_java!というJRuby固有メソッドがあります。これは、Rubyで定義したクラスをJavaのクラスとして定義する（そのようなバイトコードを生成して.classファイルを書き出す）メソッドです。このbecome_java!が、Rubyで定義したクラスのシングルトンメソッドを、Javaのstaticメソッドとして定義するようになりました。ちなみに、self.fooとfooが定義されていると衝突してエラーになるとか、未だ微妙なので、この機能を利用する時は慎重に。しかし、この修正はTorqueBox（JBoss上のRails実行環境）からのものなんですが、一体彼らはこの機能を利用して、何をやっているんでしょうか。
• JRUBY-5142 JRubyではRuby側からJavaオブジェクトを操作できますが、Marshal.dumpすることもできます。もちろんMarshal.loadすると元のJavaオブジェクトに戻ります（内部の実装は、Java側のオブジェクトシリアライズ機能を呼び出しています）。この時、Marshal.loadで、Java側のオブジェクトをデシリアライズするときに利用するクラスローダーが適切でなく、本来読み込めるべきオブジェクトが読み込めずにエラーになっていたのを修正しました。これはGAE/JでJRubyをやっているチームから。。。というより、JRubyを使って実装されているMirah言語向けの修正のようです。一体彼らは（略）
• JRUBY-5223 Kernel.readメソッドが定義されていると、Marshal.loadでエラーになる、という問題を修正しました。@ykfさんに見つけていただいたものです。ありがとうございました。 
• さらに、JRubyからantタスクを利用するantライブラリをrequireした際、javac実行用のライブラリ群があればデフォルトで読み込むようになりました。javacタスクを使いやすくしています。

今回のリリースサマリ作成には、大変時間がかかりました。どの修正も、大変微妙（用途限定、環境限定）で。。。1.5系は熟成が進んできた、という感じ。ということで、そろそろ1.6のRCが出て欲しいところですが、いつになるかなあ。

なお、年末の12/27に、日本JRubyユーザ会 第4回 & 忘年会が開かれます。私も最近のJRuby開発のトピックについて、短い紹介をさせていただく予定です。まだまだ小さいコミュニティーなので、興味のある方は、気張らずお気軽にご参加ください。お待ちしています。

Array#<< is MT-unsafe in JRuby

RubyのArrayオブジェクトの同期性についてのお話。

タイトルそのままですが、JRubyではCRubyとは異なり、Arrayがスレッドセーフではありません。ここでいう「スレッド」とはRubyレベルのThreadのことです。（※ただしJRubyでは、RubyのThreadとJavaのThreadが1対1対応なので、JRubyにおいては、JavaレベルでのThreadを考えた場合でもスレッドセーフではありません）

実験。

10のスレッドが1000回ずつ、Arrayオブジェクトへの要素追加を行っています。p a.sizeは、10 * 1000で10000を表示してほしいところですが、ConcurrencyError例外になっています。

ConcurrencyError例外はJRuby固有の例外で、Javaでの実装上、Array用に内部で持っているJavaレベルの配列に対してArrayOutOfBoundExceptionが上がった時などに通知されます。勘のいい人はわかるかもしれませんが、つまりObject[] valueに対し、value[length++] = itemみたいなことを同期なしでやっているわけで、今回のように配列のreallocationの結果ArrayOutOfBoundExceptionになって止まればいいほうです。現に、上記サンプルを動かすと、p a.sizeに対して3671みたいな想定外の数字が出る（挿入した要素が失われている）人も居るかもしれません。

CRubyで上記実験を行うと、1.8、1.9のいずれでも10000が帰ります。これはCRubyがGIL（Global Interpreter Lock）という、実行処理系全体で排他制御するためのロックを保持し、上記のようなスレッド競合問題を避けているからです。

JRubyのこの挙動は、現時点では意図的な挙動です。もしArrayを同期的に使いたい場合、Rubyレベルで排他制御をする必要があります。あるいは、JRuby固有の対応になりますが（つまりCRubyとの互換性が失われる）、JRuby::Synchronizedというモジュールを使うこともできます。末尾に「# !!!!」がある2行を追加しました。

期待通り、10000が表示されるようになりました。

JRuby::Synchronizedモジュールは、Objectにextendすると全てのメソッドがJavaレベルでsynchronized定義される（かのように動作する）ものです。実際にはJavaのbytecodeレベルで全メソッドにlock命令が入るので、性能を考慮しつつ使いどころは慎重に。そのうち性能測定もやってみましょう。

JRuby、怖いですね。CRubyからの移行を考える時のネックの一つです。今のところは、代わりに得られるスケーラビリティーとのトレードオフです。できればスケーラビリティーを保ったまま、この問題を回避する方法を見つけたいと、JRuby開発者はみんな思っています（みな、呆れるほどCRubyとの互換性を尊重しています）。個人的には、IRに期待しているんですが、IRって何？などについては、またいずれ。

「HSM超入門講座」セミナー

先週木曜日（2010年11月18日）に、弊社とタレスジャパン社の共催でHSMのセミナーが開催され、そこで「HSM超入門」と題してしゃべってきました。「HSMとは」からはじまり、「HSMの機能」、「HSM導入の利点」を整理し、最後に、情報システムにおける「HSMの利用パターン」4パターンをまとめています。

資料はこちらです: http://slidesha.re/gq0CYl

当日は53名の方にご参加いただきました。おいでいただいた皆様、ありがとうございました。

数多くの開発案件でHSMを扱ってきましたが、HSMは未だに、必要なところの多くにリーチできていません。多くの情報システムにHSMは不要です。しかしHSMを適切に使えば不要な業務、不要な投資もあります。まずはHSMとその使いどころを理解し、適切に使っていただくために、この資料が入り口になればと思っています。

なお「利用パターン」の最後、「プログラム保護」のために利用可能な技術の一つに、Thales社のnCipher HSMが持つSEE技術があります。これについては以前、別のセミナーで「HSM用ミドルウェア Conduit Toolkitの概要と使い方」としてお話したことがあります。資料はこちらから: http://www.sarion.co.jp/reference.html

「超入門」とはうって変わって技術ばりばりのハードな内容ですが、HSM用ファームウェア開発の雰囲気だけでも伝わると思います。こちらもぜひご覧ください。

HSM超入門講座

View more presentations from Hiroshi Nakamura.

HSM用ミドルウェア Conduit Toolkitの概要と使い方

View more presentations from Hiroshi Nakamura.

JRuby 1.5.5 Released

JRubyの記事ばかり書いてますね。ここのところJRubyばかりやっています。大仕事が一つ残っていて、それが片付いたらCRubyに戻ろうと思ってるんですが、なかなか。。。いずれ詳しく書きます。

RubyConfを目前に、JRuby 1.5.5がリリースされました。

• http://jruby.org/2010/11/10/jruby-1-5-5.html
• http://www.jruby.org/download

1.5.3の次が1.5.5になり、1.5.4が飛ばされていますが、リリース上の都合というだけで深い意味はありません。基本的にバグフィックスリリースで、以下の修正が入ってます。

• JRUBY-4940 .rbファイルに非ASCII（Cucumberの日本語等スペック等）が入っていると正しく解析できないことがあり、修正されました。Naoto "Kevin" IMAI TOYODAさんgood job!
• JRUBY-4865 [Windows] antモジュールが動作していませんでした。
• JRUBY-5110 [Windows] Kernel.systemが動作しないバグが修正されました。（JRUBY-5112, JRUBY-5133）
• JRUBY-5122 [Security] WEBrickがbusy loopでCPUリソースを無駄に消費するのを修正しました。
• JRUBY-5064 Marshal.loadで、Fixnumを正しく読み込めないことがあるのを修正しました。具体的には、IOとして読み込んだ時にbuffer cacheに乗らなかった部分で発生します。
• JRUBY-5123 Marshal.loadでインスタンス変数（具体的にはTYPE_IVAR）を正しく読み込めずにエラーになることがあるのを修正しました。ActiveRecordのモデルをdumpしてエラーになっていた人は、試してみてください。
• JRUBY-5132 RubyからJavaを呼ぶJava integrationインターフェースで、"instance_of?"が予約名に追加されました。java.awt.Component.isInstanceOfを自動変換してぶつかっていました。なんという偶然。
• JRUBY-5168 Java integrationインターフェースで、JRuby::Synchronizedモジュールをincludeした後でJava側定義のinterfaceをincludeすると、エラーになっていたのが修正されました。JRuby::Synchronizedモジュールは、Objectにextendすると全てのメソッドがJavaレベルでsynchronized定義される（かのように動作する）ものです。bytecodeレベルで全メソッドにlockコードが入るので、性能を考慮しつつ使いどころは慎重に。
• JRUBY-4766 YourKitというCPU/メモリプロファイラで正しくプロファイルできるように、jafflライブラリが更新されました。jafflライブラリは、jffiモジュールと一緒に使うユーティリティレイヤです。まあ、知らなくてもかまいません。私もよく知りません。
• JRUBY-5138 ffiモジュールをrequireすると、誤ってModule.errorというモジュール関数が定義されていたのが修正されました。

JRUBY-5064, JRUBY-5123, JRUBY-5122は私が対応したもので、JRuby開発では今のところ、こういうCRuby絡みっぽいところを拾って対処してます。まだまだ手は足りてないので、誰か、JavaのできるCRuby開発者が増えるといいんですが。

JRUBY-5122のWEBrickのbusy loopはDoSなので、万が一WEBrickを外部向けサービスに使っている人は手当てしてください。patchは1行、NONBLOCKを外しているだけなので、手元で手動patchでも構いません。

なお、おまけとして、組み込みのRubyレベルプロファイラが新しくなり、出力がprofile.rbに近く、またより正確になっています。コマンドラインに--profileオプションを渡すと利用できるので、是非使ってみてください。CRubyのprofile.rbとは違い、組み込みなので速いですよ。