読者です 読者をやめる 読者になる 読者になる

Re: Pythonのガベージコレクタは「マーク&スイープ」?

http://d.hatena.ne.jp/atsuoishimoto/20110220/1298179766
の話に私の翻訳した記事がのってたので、ブログでも補足させてください。
ここで話すPythonというのは「CPython」のことです。
 

PythonGCはマーク・スイープか?

これは「参照カウント」だと思います。
参照カウンタには「循環参照しているオブジェクト群が死んでも死にきれない」という罠があって、それを解消するために部分的にマーク・スイープのようなものが組み込まれた、というのが私の理解です。
これは我々の本では「部分的マーク・スイープ法」と書いてますね。
CPythonはこのアルゴリズムを少しいじって実装されているようです。世代別になってますね。
 
これは詳細が知りたいですよね。
なんと実装については我々の本に載っています(キリッ
 

なんで「マーク・スイープ」じゃないの?

なぜなら,拡張モジュールが動作している為,Pythonはルートセットを完全に取り決める事は決して出来ないからです.
ルートセットが正確に決定できない場合は,オブジェクトを解放する際に「どこか」から参照されている危険性があります.
たとえ,拡張モジュールが現在と違う設計をされたとしても,オブジェクトはCの関数スタック上にあり,ポータブルにルートを見つける方法はないでしょう.

http://www.narihiro.info/translate/garbage_collection_for_python_jp.html

という話ですが「ちょっと言い過ぎ感があるかなぁ」と思います。
CRubyだと実際に実装されちゃってるわけなので。
すみません、誤解のあるような訳をしちゃって…。
 

しかし、Python2でガベージコレクタを修正しようという話になったころには、すでにサードパーティによるPython拡張モジュールが大量に存在していた。
Pythonコミュニティは基本的にバージョン間のコンパチビリティを非常に重視するので、このような既存拡張モジュールへの影響が大きい修正は受け入れられなかったのである。

http://d.hatena.ne.jp/atsuoishimoto/20110220/1298179766

というのが本当のところ理由のような気がします。
参照カウントから、マーク・スイープなどのtracing gcに乗り換えるのはかなり大変でしょうし(逆もそうだけど)。
 

こんなアーキテクチャ依存の処理があるとPythonの移植性が損なわれてしまうという懸念から、最終的には却下された。
おかげで、現在でもPythonのコア部分は、Cコンパイラが使える環境であれば、細かいアーキテクチャに関わらず移植することができるのである。

http://d.hatena.ne.jp/atsuoishimoto/20110220/1298179766

なるほど。
GC以外にもアーキテクチャ依存のところはありそうな気はするので、「レジスタの中身を取ってくるのは汚いハックになるからやだなー、生理的に無理」って感じのような気もします。
はて、どうなんでしょう…。