脱BoehmGCへの道 準備編(4)

実装編書いたのに準備編に逆戻りｗ

コードリーディングに関するのは準備編にまとめようと思っているだけなので実装をしていないわけではないんだけど、妙な感じではある。

SBCLのコードを読んでてどうも納得がいかないというか、理解ができていない部分がある。オブジェクトのコピーである。他のGCと同様SBCLも世代別GCも最初にスタックエリア、静的エリア(SBCLが内部で持ってるもので、.dataとかではない)におかれているポインタの保存をした後にごみ集め(scavenge)するようになっている。

まぁ、これだけ見れば特に問題ないように見えるんだけど、世代別GCではコピーが発生する。コードを読んでいるとscavenge_newspace_generationがコピーを行うとコメントに書いてあるのだが、 最終的にそいつはscavengeにたどり着き普通に回収しているように見える。また、ポインタを保存する際にそのオブジェクトが保持している中身には一切の興味を示していない。つまり、ルートからたどれる最初のオブジェクトしか保存していないようにみえるのだ。(実際は、ページ丸ごと保存しているので4096バイト(32ビット？)ごそっと保存してるんだけど。)

これはLisp側のコードも解析しないといけないかなぁと思い、ちょっと眺めてみた。知っている人は知っていると思うけど、SBCLはVOPと呼ばれる仮想アセンブリ言語があってこいつが非常に読みづらい。頑張ってたどっていくと、X86環境ではメモリの割付はallocation手続きからalloc_overflow_*(ecxとかとか)が呼ばれ最終的にCで定義されたallocそして、世代別GCならgeneral_allocが呼ばれることが分かった。ということは、Lisp側で割り付けられようが、CのAPI使おうが(SBCLは外部にAPIを公開してないので不可能だけど)、最終的には同じメモリが同じように割り付けられているはずである。

となってくると、たとえばベクタなんかが中にLispオブジェクトを保持していた場合どうにかしてコピーしないとまずいことになると思うんだけど、どうなってるんだ？確かに、scav_other_pointerではオブジェクトの最初のアドレスからヘッダをとってコピーしてるんだけど、こうあるべきなのか？

そもそも、general_allocを勘違いしている可能性があるといえばあるんだけど・・・

とりあえず、ハッシュテーブルの保存を考えてみる。以下が僕が理解しているSBCLのGCフローになる。

1. スタック上にハッシュテーブルが見つかった
2. そのオブジェクトが存在しているページをスクラッチ世代に昇格させる
3. 掃除
1. 掃除する領域を探す
2. 領域からページを取る
3. ページが旧世代に属していた場合は掃除する
4. ページテーブルの更新をする

上でも書いたけど、理解している範囲ではハッシュテーブル内に格納された値は一切救われない。それどころか、ハッシュテーブルが所属しているページはスクラッチ世代に一時的に昇格されているので、触られることさえない。(問答無用でweak-hashtableにされているとかｗ)
そうなってくると、実際にテーブル内に格納されているキーと値はどこか別のポインタとして生き残っている必要があることになるのだが、SBCL的にはこれらのポインタはどこかにあるものなんだろうか？