看看Java / OpenJDK，似乎每个“新”垃圾收集实现大约比前一个大一个。
CLR等其他运行时的垃圾收集器实现的大小是多少？ 垃圾收集的非平凡改进是否等同于实施的规模/复杂性的急剧增加？
更进一步，是否可以对垃圾收集器实施进行一般性的观察，或者是否存在某些设计决策（在Java或其他地方），这些决策特别促进或强制要求这些规模的增加？
答案 0 :(得分：1)
非常有趣的问题......真的很宽泛，但我会尽力给予体面的投入。
更进一步，是否可以对垃圾收集器实施进行一般性的观察，或者是否存在某些设计决策（在Java或其他地方），这些决策特别促进或强制要求这些规模的增加？
java的垃圾收集器最初不支持代，因此添加此功能使其大小增加。另一个增加jvm垃圾收集器大小/复杂性的是它的配置。用户可以通过多种方式调整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/
它的功能非常少，甚至要求用户在共享引用时标记块。它的大小很小，只有一个C文件和一个header文件。
将此与.net框架中使用的功能齐全的gc进行比较。下面我介绍了与.net垃圾收集器的两位架构师的一系列会谈。 http://channel9.msdn.com/Tags/garbage+collector
具体来说这个链接：http://channel9.msdn.com/Shows/Going+Deep/Patrick-Dussud-Garbage-Collection-Past-Present-and-Future他们讨论了.net gc的演变，包括特征和复杂性（与代码行有关）。