もはやガーベージコレクション(GC)は必然だ。これから登場する言語でGCのない言語は考えられない。 世の中にはさまざまな(宗教上の？)理由でGCを毛嫌いする人がいるが、 そういう人はCやC++を使ってればいい。これらにGCが導入されることはないだろう。
では、Rubyのようなスクリプト言語のGCに対する要求にはどんなものがあるか。
Rubyの10年の経験からいうと速度に対する要求はさほどない。 Rubyインタプリタそのものが遅いせいかもしれないが、 10年間の間でGCが問題になったのは、
というlive objectが異様に多かったケースだけだ。報告があったのは数度だけ。 もちろん「GCが遅いなあ」って思った人はもっとずっとたくさんいるだろうけど。
だから、スクリプト言語のGCに対する要求はむしろ
などだろう。実はGCの研究はトータルの速度や応答性などの性能が重視されていて(当たり前だけど)、 この辺はあんまり検討されていない。が、実際の処理系にはこういうのが必要なのよ。
ところが、これらの要求は実は実現するのが大変難しい。
たとえば、(1)を実現するためには、 Rubyも採用しているCスタックをスキャンするconservative GCが向いているんだけど、 これは移植性が低くなりがちだし、なによりpthreadがカレントスレッド以外のスタックアドレスが取れないので、 native threadとの相性は最悪だ。(5)についても、木山くんがやったような世代別GCで大量live objectに対応できるが、普段の性能はどうしても低くなってしまう。
こういう相反する要求にどう応えるかというのが、これからのスクリプト言語の実装に対する課題ではないだろうか。 もっとも、そんなことは考えないでBoehm GCを使っちゃうってのも、この際アリだけど。
でもって、数年間考え続けてやっと
GC手法を考えついたような気がするんだけど、実装してみないと「普段の速度」は分からないなあ。 これが遅いとなんにもならない。
その手法の詳細を記述するにはこの余白は狭すぎる*1(続く)。
*1 期待させる口ぶりですが、たいしたことじゃありません
あいかわらず発散しぎみなのだが、 それぞれの分野で発散したまま議論が深まった。 今後、今までに出たいろいろなアイディアから取捨選択する必要があるのだろうなあ。
次回は3月5日(金)の予定。