RubyConf'08のビデオから: Ruby VMの内部構造について - YARV、Rubinius、MagLev

作者 Werner Schuster , 翻訳者 角谷 信太郎 - (株)永和システムマネジメント 投稿日 2008年12月18日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

コンパイラ ,

Ruby ,

テクノロジー ,

パフォーマンス&スケーラビリティ ,

ランタイム ,

動的言語

タグ

JRuby ,

Ruby1.9 ,

RubyConf ,

MagLev ,

RubySpec ,

IronRuby ,

Rubinius

RubyConf '08では、Ruby VMについての講演が数多くおこなわれた。その内容は実装技術の詳細に踏み込んだものから実装のデモ、Rubyのパフォーマンスの概要まで多岐にわたるものだった。

"The Future of VM"(リンク)と題された講演で笹田耕一氏は、RubyのC言語実装には、たとえば保守的GCのような問題があるとはいえ、近い将来までという視野においては現実的な解決策であるとの見解を述べた。
笹田氏は、それに続けてRuby 1.9の最適化への取り組みを紹介した。現状ではこうした最適化は有効になっていないが、1.9.2 では使えるようにするとのことだった。こうした最適化には、末尾呼出の最適化やスタックキャッシング、メソッドキャッシングの効率化や、Fiberのさらなる実装の効率化などが含まれている。

講演ビデオの20分頃に、笹田氏は自身の研究テーマのひとつであるRicsinを解説した。RicsinはRubyコードにCのソースコードを埋め込むことができる。講演スライドから借りてきた以下のサンプルを見たほうがRicsinの狙いは理解しやすいだろう。

def open_fd(path)
 fd = _C_(%q[
    /* C のコード */
    return INT2FIX(open(RSTRING_PTR(path), O_RDONLY));
 ]) 
 raise 'open error' if fd == -1
 yield fd
 ensure
  raise 'close error' if -1 == _C_(%q[
     /* C のコード*/
     return INT2FIX(close(FIX2INT(fd)));
  ])
end

RicsinとRubyInline(リンク)との違いは、RicsinではRubyのメソッド本体にCのコード片を記述できる点である。今のところ、Ricsinを利用するにはRicsin向けのYARVが必要になるが、そのためのSVNリポジトリは既に公開されているので、誰でも試すことができる。
「SVNリポジトリ」のリンク先は以下です:
http://svn.ruby-lang.org/repos/ruby/branches/ricsin/

これ以外にも、笹田氏はRubyからCへのコンパイラ(講演ビデオでは28分40秒頃)や、プログラムで必要のないRubyの機能を削ることのできるAtomic-Rubyといったプロジェクトを紹介した。

講演ビデオの41:00あたりでは、Ruby MVMプロジェクト(リンク)の現状が詳しく説明されている(InfoQでもRuby MVMについては既に報じた(参考記事))。


Evan Phoenix氏の講演(リンク)は、Rubiniusプロジェクトの現状とC++化されたVMについてである。
講演では旧来のCによるVMをC++で書き直した経緯についても説明があり、C++を採用した理由は、型安全性とコードがシンプルになるからだとう。C++にしたことで、数多くの自力によるコードチェックが不要になったと語った。
 

講演ビデオの18分04秒では、プリミティブの実装の現状が報告されている(Cでプリミティブを書く方法について)。続いて26分30秒頃には、メソッドディスパッチを速くするための戦略が語られている。ビデオの35分あたりからは MethodContext("スタックフレーム")の割り当ての解説がおこなわれている。旧バージョンのRubiniusではMethodContextはヒープに割り当てられていたが、現在のバージョンではスタックに割り当てられるようになり(このためのメモリ領域を確保している)、その結果として割り当てコストが削減された。しかし、MethodContextの寿命は、スタックを割り当てたメソッドよりも長くなることがある(たとえば、クロージャを使った場合)。この場合はMethodContextオブジェクトを残しておくことになるが、MethodContext用に割り当てているメモリ領域には限りがある。そのため、この領域が満杯になるとGCが実行され、その時点でどこからも参照されていないMethodContextは一掃される。
 

ビデオの38分40秒からは、RubiniusにおけるRubyのC拡張サポートについての話題だ。C拡張は、たとえばhpricotやmongrel、mysqlにsqliteドライバといったgemが利用しているので、重要なトピックだ。講演では、RubiniusでC拡張を扱う場合の問題についても説明があった(たとえば、世代別GCやセグメンテーション違反での問題など)。


同様の話題は他の講演でも取り上げられていた。Glenn Venderburg氏 による "How Ruby can be fast"(リンク)がそうだ。講演で言及されたのはVMの実装についてではないが、Rubyが遅い、あるいは遅くなりそうな要因について語られている。講演ビデオの7分頃では、ガベージコレクションの解説がおこなわれ、そこでは世代別GCの理論的な概要に続いて、メソッドディスパッチのパフォーマンス最適化が解説されている(ビデオの19分35秒頃)。

Bob Walker氏とAllan Ottis氏による"Ruby Persistence in MagLev"の講演では(リンク)、MagLevの現状が報告された。Bob Walker氏からはGemstoneの永続化モデルを使うことの利点の初歩的な解説がなされた。氏によれば、Gemstoneではリレーショナルモデルにオブジェクトをマッピングするのではなく、単にオブジェクトグラフを永続化するだけなので、オブジェクト・リレーショナル・マッピングのライブラリやツールが抱えるさまざまな問題を回避できるとのことだった。

ビデオの14分30秒頃からは、Allan Ottis氏がMagLevの内部動作の補足説明をした。これはオブジェクト永続化の実装の解説から始まり、18分50秒からのSmalltalkとRubyの相違点の概要へと続いている。そこではSmalltalkでRubyを実装する場合の問題点も語られている。22分29秒からは、コンパイルプロセスの説明がなされ、現状でのパージング戦略(RubyサーバがRubyコードをパーズするRubyサーバを用意して、gemのParseTreeのS式をASTとしてフォーマットしたものを返す)が解説された。

講演ビデオの25分からは2つの実行モードが説明される。インタプリタ実行とネイティブコード生成だ。30分30秒からは、Context("スタックフレーム")割り当ての実装に続いて、オブジェクトメモリ(ヒープ)とガベージコレクタの詳細が解説されている。

44分20秒からは質疑応答だ。会場の聴衆からは、分散キャッシングや、今後のパージング戦略(ruby_parserの利用)、分散オブジェクトメモリをまたいだトランザクションの振る舞いといった質問が出た。
 
デモを中心にしたRuby VMについての講演は次の3つだ。

• Charles Nutter氏とTom Enebo氏による"JRuby: What, Why, How...Try It Now"(リンク)の講演ではJRubyの現状や、Ruby1.9のサポート、FFIなどに言及している。
• Laurent Sansonetti氏による"MacRuby: Ruby for your Mac"(リンク)
• John Lam氏による"IronRuby"(リンク)

一連のRuby VM講演の最後を締めくくるのは、Brian Ford氏によるRubySpec(リンク)の話題だ。氏によればRubySpecプロジェクト(リンク) には現在、Rubyの振る舞いを定義した何万ものテストケースが用意されており、さまざまなRuby実装にとって非常に重要なツールとなっているとのことだった。

 

原文はこちらです：http://www.infoq.com/news/2008/12/rubyconf08-videos-rubyvms

• 次へ >