Precise GCへの道
nmoshはBoehmGCをGCに使っている。BoehmGCはそれなりに高速だし移植性もあるのだけれど、エクストリームな状況ではやっぱり使いづらい。
BoehmGCから自前のGCにスイッチしたケースとしては、Chibi SchemeやMono、Racketがある。
Chibiの場合はちゃんと個々のオブジェクトについてマーク/スイープコードを書いている(= BoehmGCを使わなかった場合と同様の手間を書けている)。
Monoはsgen GCに乗り換えているが、sgenはそもそもスタックは保守的にマークする(Linux除く: http://www.mono-project.com/Working_With_SGen )のでBoehmGCを使っていたのと事実上はあまり違わない。もちろん、Precise GCとするためのAPIの追加などは行なっている。
GCの無い言語でどうGCの有る処理系を書くか
率直に言って近道は無いような気がしている。
nmoshはR6RSのライブラリの多くをC++クラスで持っていて、Schemeオブジェクトから参照されるC++オブジェクトの問題が有る。(cf. http://steps.dodgson.org/b/2012/12/19/dom-and-gc-or-what-happend-at-eden/ )
BoehmGCはこのようなシチュエーションで何も考えずにGCを実装できるが、そのかわりかなりhackな手法なので、ダイナミックリンカや他のOSレベル機構に精通していないと移植が難しい( http://d.hatena.ne.jp/mjt/20130106/p1 )。
いわゆるスマートポインタはGC風の仕組みをC++上に実現するが、循環参照を処理できないといった良く知られた弱点がある。また、オブジェクトをまとめてfreeできない等の微妙な点も。picogc( http://d.hatena.ne.jp/kazuhooku/20120327/1332813130 )のように自分が生成したオブジェクト参照をどこかで管理する必要がある。
picogcのようなpluggableなGCはあまり流行っていないように見える(除BoehmGC)。たとえば、C++のオブジェクト管理フレームワークとしてJikesJVMのMMTkがあり、LLVMのVMKitでも使われているが、VMKitは自前の移植を管理している。
いづれにしても、既存のnmoshのクラス群を生かしたままPrecise GCに移行するためには、既存のグラフ群のオブジェクトグラフをトラバース可能にする必要がある。つまり、picogcが要求しているようなgc_markメソッドの公開や参照のpicogc::localによるRetainなどをコードベース全般に導入する必要がある。
アプローチ
- "Sub VM"を持ち、必要な所で使う
検討中のアプローチは、R6RSのセマンティクスをフル実装はしないSub VMを持ち、こちらをPrecise GCにするもの。従来はI/O VMと呼んでいたがI/O以外にも用途があるので微妙なところ。
現状のnmoshアプリケーションはちょっとしたスクリプトとネットワーク/デバイスアプリケーションに大きく2分でき、後者はR6RS機能を殆ど必要としていない。
この場合、Main VMとSub VMでクロージャを呼び合う時にオブジェクトの変換が必要になるため、その辺のコストを多少心配している。特に、"Main VMとSub VMで共有されるオブジェクトのeq?性の保証"という頭の痛い問題が有る。。
細かいポイントでは、実装のサイズが大きくなるのも心配する必要がある。インタプリタを動的ライブラリとして提供するときにMain VMとSub VMの分割を想定しておくことでそれなりに対処できるような気がしている。
- 何らかの方法でGC実装を抽象化して移行する
nmoshに適用できるかどうかは微妙なところだが、例えばpicogcをgcとして使うオプションを提供するために現状のクラスを修飾していくことは考えられる。
この場合、各Schemeオブジェクトのクラスに含まれるポインタやオブジェクトを全てチェックしてオブジェクトの参照としてマークする必要がある。
- Precise GCにしない(!)
なんだかんだいってBoehmGCも高速なので、まず、BoehmGCよりも高速にならないならやる意味が無い。アセンブラで書きなおす時にコンパイラが最初の敵になるのと同様に。。
例えば、Racketのケース( http://www.cs.utah.edu/~regehr/papers/ismm15-rafkind.pdf )ではBoehmGCに比べて4倍高速になったものもあれば、逆に遅くなったものも有る。
