2005/11/01

昨日の続き。

1. 途中経過のdumpからGC_written_bitsが上書きされている、と思ったのは誤認であった。 テストルーチンは問題が出る前にforkしており、先にdumpが出る子プロセスの方では GC_written_bitsが正しく設定されており、後にdumpが出てた親プロセスの方で GC_written_bitsが'0'のままであった。
2. Solarisでは、dirty bitsを読むのにprocfsを使ってる。GC初期化時に自分のプロセスIDの ファイルをオープンして、ioctl(PIOCOPENPD)でpage data fileのディスクリプタを 得て保存。その後、GCがキックされる度に(GC_initiate_gc)そこからdirty bitsの 情報をread(2)する。read(2)の度にdirty bits情報はクリアされる。
3. 仮説。page data file descriptorが親子で共有されるということは、 もしかして片方でread(2)するとそれがもう片方に影響を与えたりしない?
4. もひとつ。page data file descriptorは /proc/<親のprocess-id> をopenした プロセスファイルから得たものなんだが、そのまま子がそれを参照してて 子自身のpage dirty bitsが取れるんだろうか。
5. sunのサイトにもforkが絡んだ場合のpage data fileの説明が見当たらないし、 とりあえずこのへんの疑問点をgc-listに投げてみた。

Gauche的には、今回の問題だけに関してはforkの前に強制的にgcを呼ぶようにすれば 回避できるな…

Tag: Gauche