BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Rubyのスレッディングとガベージコレクションの今後 - 笹田耕一氏インタビュー

Rubyのスレッディングとガベージコレクションの今後 - 笹田耕一氏インタビュー

ブックマーク

原文(投稿日:2009/7/31)へのリンク

Ruby 1.9.2は年末までにリリースされる予定だ。 InfoQは 1.9.2 Preview 1 のリリースに際して、Ruby 1.9.xのVMメンテナである笹田耕一氏とVM、スレッディングガベージコレクタの今後について話をする機会を得た。

InfoQ: RubyConf'08では、1.9.xのおける最適化について、デフォルトでは無効になっているところもあるが1.9.2では有効になるかもしれない、とおっしゃっていましたね。これについて、どうなっていますか?
笹田耕一氏
: 実のところ、1.9.2でも最適化は有効になっていません。こうした最適化を有効にするためには、もっと経験を詰む必要があると思っています。要するに、実験する時間がなかったんですよ。
ちょっとした最適化は入ると思います。もし時間が作れればですが、Proc#callの最適化などは実装したいところですね。

InfoQ: Ruby 1.9.2 Preview 1には、longlife GCパッチが取り込まれましたね。私の理解では、長寿命オブジェクト領域にあるオブジェクトは(長寿命オブジェクトも含めて、GCが完全に実行されるまでは)無視されるので、通常のオブジェクトに対するGC実行は高速になるはずです。この理解は正しいでしょうか?
笹田耕一氏: ええ、そうです。Nariさんがやりました。主に、ノードオブジェクトには旧世代オブジェクトに属するものがあります。VMパフォーマンスを改善するために、インラインキャッシュとして使われたノードもありました。このパッチの変更によって、GCでマークする際にインラインキャッシュオブジェクトなどは無視されます。
でも、私はインラインキャッシュのコードを書き直して、ノードオブジェクトにならないようにしました。つまり、インラインキャッシュのコードには、もはやノードオブジェクトは使われていないということです。そのため、もはやこのGC最適化には、ほとんど効果はありません。

InfoQ: longlife GCパッチは世代別GCへの第一歩のように見えます。特に、ライトバリア(write barrier)とremembered setを処理するコードが導入されたところなどは。1.9.2では世代別GCが可能になるのですか?
笹田耕一氏: いいえ。"uncovered" オブジェクトに限定されます。これは、C拡張ライブラリからさわれないオブジェクトを意味しています。もしコードのどこかで、このオブジェクトにさわってライトバリアするのを忘れると、SEGVを引き起こすような致命的なバグになります。CRuby(Matz)はこのような変更を許してはくれないでしょう。

ライトバリアを必要とするGC実装向けに、ライトバリア自動挿入に取り組んでいる日本人研究者(学生)もいます。これがうまくいけば、世代別GC(インクリメンタルGCも)も夢ではありませんね :)

InfoQ: Ruby 1.9.x VMのための世代別GCを作る上で、難しいのは何でしょうか?私は移動オブジェクトが課題であり、ネイティブ拡張で問題になるのでは、と思っているのですが?

笹田耕一氏
: 書いたように、問題はGC技術には完全性が必要であることです。もし誰かがライトバリアを追加するのを忘れると、深刻な問題になります。
こうした状況のなか、「mostly mark & compaction GC」を提案した日本人研究者がいます。この技術は保守的に実行され、完全性を必要とはしません(もちろん、GC実装は完全であるべきです。私の意味するところは、拡張ライブラリのインターフェイスに変更を必要としないということです。)

InfoQ: Unladen Swallowプロジェクトは、PythonからGILをなくすことを目的としていますね。GIL(もしくは、RubyにおけるGVL)について、1.9.2や今後のバージョンで何か計画はありますか?
笹田耕一氏: 1.9.2もしくは近い将来に、GVL(Giant VM Lock、YARV用語におけるGIL)をなくすことはできません。
遠い将来のことは、まだわかりません。GVLフリーなスレッドが利用可能になるのがうれしいことなのか、私にはわかりません。簡単に言うと、これはスクリプトを書くのを難しくしてしまうのです。

InfoQ: どのようにMacRubyがGIL問題を解決しているのか、調べたことはありますか?
笹田耕一氏: すごいですね。どうやってプログラムしたのか調べてみたいです。もしMacRubyユーザ全員が「うれしい」と言っているのなら、考えを変えなきゃいけませんね。:)

InfoQ: GVLはネイティブ拡張での問題を防いでくれるのですか?
笹田耕一氏: GVLはどんな問題も防いではくれませんよ :)

実は、私は博士論文でGVLフリーなRuby VMを提案したんです。これはCPUの数によってパフォーマンスを改善することができます。私の並列VMでは、非スレッドセーフな(Cで書かれた)メソッドがまず最初に実行され、VMがGVLを獲得して、メソッドなどのプロセスを処理して、GVLを開放します。この論文では、最適化と例外セーフ技術について書いています(残念ながら日本語です)。

私の並列VMでは、VM機能はスレッドフリーです。これは並列実行可能であることを意味しています。でも、StringやArrayといった多くのビルトインクラスには、スレッドセーフでないメソッドがたくさん残っています。これらをスレッドセーフにするのは単純な(でも大変です、バギーなコードなら簡単に作れますが)作業です(でも、かなりの労力が必要になります)。したがって、実装面からなら、私は「もちろん可能です」と言えます。

でも先ほど書いたように、言語設計面からは、これが私たちにとってうれしいことなのかはわかりません。

現在、Sun Microsystems社がスポンサーになって、MVM(マルチVM)プロジェクトが進行中です。このプロジェクトは、1つのプロセスで複数のVMを実行可能にします。すべてのVMは並列に動かすことができます。私はスレッドよりも並列性をコントロールする方が望ましいと考えています。もちろん、MVM操作が十分低コストである必要はあるのですが。このコストは研究目標の1つです。MVM側ではスレッドセーフであるかを気にする必要はありませんが、VM間通信について気にする必要があります。

これは研究プロジェクトにすぎませんが、実用的な実装をリリースしたいと思っています。

また別のプロジェクトとして、並列化の活用を計画をしています。まだ検討中ですが、次回のRubyConfでこうした技術をお見せできればと考えています。

この記事に星をつける

おすすめ度
スタイル

BT