conservativeなGC - やねうらおブログ(移転しました)

BoehmのGCは保守的(conservative)なGCである。これは、root集合から辿れるならば、配列の中身すべての要素を辿ることを意味する。画像imageのように大きな配列を扱う場合、こんなことをされてはたまらない。配列の要素がでたらめな数字だと、そんなところを辿ってアクセス違反にならないの？と思うかも知れないが、GCは自分のヒープから割り当てたメモリしか辿らないので、アクセス違反は起きない。

そこで、D言語の場合、大きな配列はGCのヒープからではなく他のallocator(たとえばmallocで)からメモリを割り当てるのが常套手段となっている。他のallocatorから割り当てたメモリはGCのヒープから割り当てたものではないので、GCはその先をスキャンすることをあきらめるからである。

まあ、どのみちアプリケーションが肥大化してきたときに保守的なGCではどうしようもいかなくなる。保守的なGCが使われる限り、リアルタイム性が問題になる大規模なアプリは書けないんじゃないかとも思う。

そうは言ってもBoehmのGCは、一番メジャーである。D言語は言うに及ばないが、monoプロジェクト(C#のネイティブコンパイラなどを作っているプロジェクト)でもBoehmのGCが採用されている。いっちょ大規模なアプリを開発したろかい！とか考えているやねうらおにとって、これは非常に迷惑な話だ。CLI自体は型情報を持っているわけで、保守的なGCなんか使う必要はないというのに。*1

ちなみに、Microsoftの.NET frameworkはそのへんどうなっているかというと次のようになっている。

ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part I
http://www.microsoft.com/japan/msdn/net/mag00/GCI.asp

ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part II
http://www.microsoft.com/japan/msdn/net/mag00/GCI2.asp

しかし、上の記事を読んでGCの仕組みについてひと通り理解するだけでも大変だろう。まあ、GCというのは、高速化したり、並列的に効率よく実行できるようにしたりするのは、非常に難しいのだ。Microsoftの.NET frameworkはそれなりにうまくやっている。とりあえずそのくらい理解しておけば十分だと思う。少なくとも、趣味や研究目的でもない限りはGCの自作はお勧めしない。まして、まともなGCともなるとゲームを作るついでにひょいっと自作出来る規模のものでは決してないのだ。

*1:monoのGCは、将来的にはIntelのORPに変更されるかも知れない。ORPについては、この解説が参考になるだろう。http://yamaguch.sytes.net/~tora/java/orp.html