«前の日記(2004年02月03日) 最新 次の日記(2004年02月05日)» 編集

Matzにっき


2004年02月04日 [長年日記]

_ [言語]スクリプト言語のガーベージコレクション

もはやガーベージコレクション(GC)は必然だ。これから登場する言語でGCのない言語は考えられない。 世の中にはさまざまな(宗教上の?)理由でGCを毛嫌いする人がいるが、 そういう人はCやC++を使ってればいい。これらにGCが導入されることはないだろう。

では、Rubyのようなスクリプト言語のGCに対する要求にはどんなものがあるか。

Rubyの10年の経験からいうと速度に対する要求はさほどない。 Rubyインタプリタそのものが遅いせいかもしれないが、 10年間の間でGCが問題になったのは、

  • 数メガのファイルを読み込みながら、
  • 数十万個のオブジェクトをリンクした構造を作って
  • そのリンク構造をトラバースしてデータ処理

というlive objectが異様に多かったケースだけだ。報告があったのは数度だけ。 もちろん「GCが遅いなあ」って思った人はもっとずっとたくさんいるだろうけど。

だから、スクリプト言語のGCに対する要求はむしろ

  1. 拡張ライブラリが書きやすい(明示的なprotectが不要)
  2. 移植性が(そこそこ)高い
  3. embed環境やnative threadと相性が良い
  4. さまざまな状況でも落ちない
  5. 普段の性能を維持しつつ、大量のlive objectに対応できる

などだろう。実はGCの研究はトータルの速度や応答性などの性能が重視されていて(当たり前だけど)、 この辺はあんまり検討されていない。が、実際の処理系にはこういうのが必要なのよ。

ところが、これらの要求は実は実現するのが大変難しい。

たとえば、(1)を実現するためには、 Rubyも採用しているCスタックをスキャンするconservative GCが向いているんだけど、 これは移植性が低くなりがちだし、なによりpthreadがカレントスレッド以外のスタックアドレスが取れないので、 native threadとの相性は最悪だ。(5)についても、木山くんがやったような世代別GCで大量live objectに対応できるが、普段の性能はどうしても低くなってしまう。

こういう相反する要求にどう応えるかというのが、これからのスクリプト言語の実装に対する課題ではないだろうか。 もっとも、そんなことは考えないでBoehm GCを使っちゃうってのも、この際アリだけど。

でもって、数年間考え続けてやっと

  • conservativeで
  • pthread下でも実装でき
  • live objectが多くてもひどい性能低下がない

GC手法を考えついたような気がするんだけど、実装してみないと「普段の速度」は分からないなあ。 これが遅いとなんにもならない。

その手法の詳細を記述するにはこの余白は狭すぎる*1(続く)。

*1  期待させる口ぶりですが、たいしたことじゃありません

_ [METI]第二回高度IT人材早期発掘のあり方検討会

あいかわらず発散しぎみなのだが、 それぞれの分野で発散したまま議論が深まった。 今後、今までに出たいろいろなアイディアから取捨選択する必要があるのだろうなあ。

次回は3月5日(金)の予定。


«前の日記(2004年02月03日) 最新 次の日記(2004年02月05日)» 編集