[ruby-dev:28336] Re: SEGV with zlib

In article <[e-mail]>,
  H.Yamamoto <[e-mail]> writes:

> http://www.nminoru.jp/~nminoru/programming/boehm-gc3.html
>
> に Boehm GC がどうしているのかが載っていました。なるほど、
> gc_mark と gc_sweep の間で、「マークされていない T_DATA で、
> mark 関数と free 関数の両方が定義されているもの」に対して
> gc_mark_children を呼べば（自分自身はマークしない）ルートに
> 当たる T_DATA だけマークが外れた状態になるので、順序付けでき
> るんですね。（自分はマークしないというのは盲点でした）
>
> ただ、この方法にも問題があるらしく、それも記述されています。

まぁ、GC 側だけでどうにか解決しようとすればそんな感じになる
でしょうし、そういう問題が残るでしょうね。

また、現在の Ruby のように、GC はそんな依存関係はいっさいケ
アせずに拡張ライブラリ側がすべての責任を負うというのも、あま
り幸せとはいえないわけです。

なので、狙いは GC と他のコードがもう少し協調してどうにかする、
というところです。

[ruby-dev:28322] でちょっと触れた、依存関係を明示的に登録さ
せるというのもひとつのアイデアです。

また、他のアイデアとしては、オブジェクトが生成される場所を制
御するというものもあります。つまり、finalizer はヒープ内で順
番に起動されますから、先に finalizer が起動すべきオブジェク
トを生成するときには、先に起動する場所にオブジェクトをアロケー
トすればいいわけです。

例えば後者のアイデアについて考えると、利点は依存先が存在する
finalizer つきのオブジェクトを生成しない限り追加コストが発生
しないということです。逆に欠点は依存先が生成時に決定され、変
化してはならないということです。

GzipWriter だと、出力先が IO であれば原理的にはその制約を満
たせそうです。現実にはバッファとして String を使っているので
そこは変える必要がありますが。

また、bdb だと、env を db が参照しているという形についてはそ
れでどうにかなりそうな気もします。

このふたつの事例だけで good enough といえるかというとそこは
難しいわけで、どういうのがいいのかなぁ、と結論には至っていな
いんですが。
-- 
[田中 哲][たなか あきら][Tanaka Akira]