RHG 片手に Ruby 1.9 を読む集い（The RHG Strikes Back）に参加した

• 第2回 RHG の逆襲
• 第1回 RHG の逆襲
• 第3回 RHG の逆襲
• 第5回 RHG の逆襲
• 第4回 RHG の逆襲
• 第7回 RHG の逆襲

マーク＆スイープ vs リファレンスカウント

yuguiさんから「Ruby もそろそろリファレンスカウントを実装したいですねぇ」という発言から、少し議論になりましたので紹介します。

Ruby のマーク＆スイープの短所は、「GC の負荷が一点に集中する」というものです。リファレンスカウントは参照がなくなったときに解放できるので、GC の負荷は分散します。ただし、サイクル（循環参照）が存在すると、GC ではメモリを解放できないという弱点もあります。Python では、この弱点を補うためにマーク＆スイープとリファレンスカウントを併用しています。

この流れで、ささださんに「リファレンスカウントを採用すれば、マーク＆スイープよりも GC が走るタイミングが分散されて、GC が走った瞬間にアプリケーションが固まるということは減ると思うがどうか」という趣旨の質問をしてみました。ささださんによると、「定性的にはそのとおり」と前置いた上で、「リファレンスカウントは遅い」「バグが多い（※）」「カウンタをロックしないといけないから並列処理と相性が悪い」「処理が集中しないと保証できるわけでもない」「リファレンスカウントを使わないのは常識」などなどデメリットが多いようです。

※ バグが多いという話は、「GC のバグはどこで何が起こっているのか把握しにくい」という意味では、どの手法を採用しても悩ましい問題に思えますが。。。

既にいくつか上げたとおり、アプリが停止する時間を軽減する手法は他にもあるので、今後の大きな変更（マルチ VM など）などを考慮しながら改善を進めていくのでしょう。

また、Ruby の GC に関する問題点は、まつもとさんの日記（Matzにっき(2008-03-06)）に詳しく書いてあるので、参照するとよいでしょう。

Ruby がなぜ現在のような GC になっているか？

Ruby を使った開発の特徴として、パフォーマンスが必要な場合は C 言語で拡張ライブラリを記述することで、高速な処理を実現できることが挙げられます。リファレンスカウントなどを採用すると、カウンタの上げ下げを拡張ライブラリを実装するプログラマが気にする必要があるなど、拡張ライブラリが書きにくくなる可能性があります。Ruby はコアライブラリも C 言語で拡張ライブラリと同じ方法で記述されています。

ささださんによると、Java などのように自前の言語でコアライブラリを書いて、VMの性能向上を行う方が長い目ではトータルなパフォーマンスは向上するとのことです。90年代の Java が遅いと言われたのは Java でコアライブラリを記述したからです。しかし、現在の Java の HotSpot コンパイラは、C よりも高速な場合すらあるとのことです。

Ruby でも同様な戦略をとるべきかもしれません。Ruby の処理系である Rubinius はそれに近い戦略をとっています。その観点では JRuby は JVM を使えるので、一番うまくやっているとのことです。ただし、Java 程コストをかけても高速化には 10 年かかったことを考えると、今の Ruby のやり方は、費用対効果が良いということもできるそうです。

少し話がそれましたが、Ruby にとっては開発コストはそれなりに重要な問題です。ここまで賢い GC を開発するためのさまざまなアイディアを紹介してきましたが、Ruby では採用されていません。（これから採用されるものもあるでしょうが。）Ruby の GC はいくつか問題は抱えているものの、シンプルに開発されています。

まとめ

以上、第4回 RHG の逆襲でした。コミッタの方が数名参加されたことから、GC のコードを読むだけでなく、なぜ今のような手法が選択されたのか理解できる興味深い勉強会でした。

さて、次回勉強会では第6章 変数と定数と第7章 セキュリティの内容を抑える予定です。Ruby のオブジェクトモデルや構造に関する勉強会は次回で終了で、その次からは構文解析などが入ってくる予定です。

主催者の皆様、有意義な勉強会をありがとうございました。次回も参加することができたら、本ブログで紹介したいと思います。それでは！