From: matz@... (Yukihiro Matsumoto)
Date: 1997-04-10T11:41:17+09:00
Subject: [ruby-list:2743] Re: tk etc.

まつもと ゆきひろです．

In message "[ruby-list:2737] Re: tk etc."
    on 97/04/10, 石塚圭樹 <keiju@shljapan.co.jp> writes:
|
|けいじゅ＠SHLジャパンです. 
|
|In [ruby-list :02727 ] the message: "[ruby-list:2727] Re: tk etc. ",
|on Apr/09 20:33(+0200) matz@caelum.co.jp (Yukihiro Matsumoto) writes:
|
|>原因はbisonではなくyaccを使っていた事です．というのはyaccは
|>生成途中の構文木をマシンスタックにおかないので，大きなスクリ
|>プトをロードして(tk.rbはかなり大きいです)コンパイル中にGCが
|>起きると構文木のノードがゴミとして回収されてしまうのでした．
|
|うーん. すごいところに原因がありましたね... これって, 他の場合でも 
|load/require/evalを使っている場合は出る可能性があるんですよねえ... ま
|だ, 原因が追求しやすくて良かったのかも(^^;;;

そうですね．まあ，あの手のバグはGC絡みというのは過去の経験か
ら分かっていましたから，比較的しぼりやすかったですね．で，結
局コンパイル中にGCが起きたらとりあえず全てのノードをマークす
るというかなり安全側に倒した方法で解決しました．

|あ, でも, 良く考えたら, 構文木を参照するポインタがスタック中か静的変数
|かにあるはずだからGCされないような(?_?

rubyのGCは大域変数やヒープ中の領域に関しては明示的に教えてや
らないとマークしませんから．

構文木はボトムアップに構築されるので，コンパイル中はパーザス
タックからしか参照されていないノードがあります．yaccの場合は
パーザスタックがヒープ上の領域にとられるので，マークされなかっ
たようです．
                                まつもと ゆきひろ /:|)