From: Tanaka Akira Date: 2006-02-15T20:14:08+09:00 Subject: [ruby-dev:28336] Re: SEGV with zlib In article <20060209111748.A8E247F0.ocean@m2.ccsnet.ne.jp>, H.Yamamoto 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]