From: matz@... (Yukihiro Matsumoto)
Date: 1996-02-14T11:46:32+09:00
Subject: [ruby-list:145] Re: The black face.

まつもと ゆきひろ＠トヨタケーラムです．

In message "[ruby-list:143] The black face."
    on 96/02/14, P nakawtse <nakawtse@syrinx.dq.isl.ntt.jp> writes:

|中渡＠ＮＴＴです．

|  parse.y ->  parse.c ->  parse.o なんですね．
|  parse.y って終端／非終端記号とソースの対応が書いてありますが
|  parse.cでは何をするプログラムになっているのですか？ 

パーザです，つまりテーブルを参照しながら構文解析をする関数で
すね．この関数にはparse.yに書いてあったCコードの断片が埋め込
まれています．

暗黒面といったのは，「こんなのコンパイラやインタプリタを自分
で作ることに関心がある人以外には難しすぎる」と思ったからです．
これ以上は興味があれば，yaccの解説書を読んでください．

|　Altairをみてきました．ＧＣまわりに工夫がありますね．この
|　参照ポインタ方式はrubyにもはいってるのでしょうか？

pythonも参照カウント方式ですね．rubyは採用していません．

理由は以下の通りです．

 (1) 参照カウント方式ではサイクルになったオブジェクトが回収さ
     れない

     参照がループしているオブジェクトは全体として参照数がゼ
     ロになりませんから，いつまでも回収されません．参照カウ
     ント方式だけではこれを解消することはできません．

 (2) C言語のレベルでプログラマが参照数の管理を行う必要がある．

     これを忘れると発見しにくいバグの原因になります．rubyはC
     言語による拡張の容易さを目標のひとつにしましたので，こ
     れはちょっと受け入れられませんでした．わざわざマシンの
     スタックをスキャンするようなGCを選んだのも，拡張モジュー
     ルのユーザがメモリ管理を心配しなくて済むためです．

 (3) 通常のGCは遅くない

     参照カウントを推す人の主張は「参照カウントは(負荷が分散
     するため)中断が無い」というものです．確かにそれは嘘では
     ないのですが，インタプリタ言語ではGCによる中断はほとん
     ど問題になりません(他が遅いので)．このことは私の経験か
     らもいえますし，最近のcomp.lang.lispでのGCのスレッドで
     も同じような主張をしている人がいました．