Java/OpenJDK を見ると、すべての「新しい」ガベージ コレクションの実装は、前のものよりもおよそ 1 桁大きいようです。
CLR などの他のランタイムでのガベージ コレクターの実装のサイズはどれくらいですか? ガベージ コレクションの重要な改善は、実装のサイズ/複雑性の急激な増加と同一視できますか?
さらに進んで、この観察は一般的なガベージコレクターの実装について行うことができますか、またはこれらのサイズの増加を特に助長または義務付ける特定の設計上の決定 (Java または他の場所で) はありますか?
非常に興味深い質問です...非常に幅広いですが、適切な情報を提供できるよう最善を尽くします。
さらに進んで、この観察は一般的なガベージコレクターの実装について行うことができますか、またはこれらのサイズの増加を特に助長または義務付ける特定の設計上の決定 (Java または他の場所で) はありますか?
Java のガベージ コレクターは当初、世代をサポートしていなかったので、この機能を追加するとサイズが大きくなりました。jvm ガベージ コレクタのサイズと複雑さを増すもう 1 つの要素は、その構成です。ユーザーはさまざまな方法で GC を微調整できるため、複雑さが増します。jvm ガベージ コレクタの調整可能な機能をすべて知りたい場合は、このドキュメントを参照してください http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
このstackoverflowの回答は、これについてもう少し詳しく説明しています https://stackoverflow.com/a/492821/25981
サイズと機能の比較について...
これは C の非常に単純なガベージ コレクターです: https://code.google.com/p/dpgc/
機能はほとんどなく、参照が共有されているため、ユーザーがブロックをマークする必要さえあります。そのサイズは非常に小さく、1Cファイルと 1headerファイルの重さです。
これを、.net フレームワークで使用されるフル機能の gc と比較してください。以下に、.net ガベージ コレクターの 2 人のアーキテクトとの対談をまとめました。 http://channel9.msdn.com/Tags/garbage+collector
具体的には、このリンク: http://channel9.msdn.com/Shows/Going+Deep/Patrick-Dussud-Garbage-Collection-Past-Present-and-Future は、機能と複雑さの両方のインターンである .net gc の進化について説明しています。 (これはコード行に関連しています。)