为什么gen1 / gen2集合比gen0慢？

如何解决为什么gen1 / gen2集合比gen0慢？

据我所知，短暂的对象创建在GC方面并不太麻烦-暗示gen0集合非常快。但是，第1代/第2代的集合似乎更“可怕”，也就是说，通常比gen0慢很多。

那是为什么？是什么原因使gen2集合平均比gen0慢得多？

我不知道收集方法之间的结构差异（即在标记/清除/压实阶段完成的工作），我是否缺少某些东西？还是仅仅是例如gen2倾向于大于gen0，因此要检查的对象更多？

解决方法

要扩大canton7的答案，有必要注意一些其他事项，其中之一增加了所有馆藏（尤其是gen1和gen2）的成本，但降低了它们之间的分配成本，其中之一降低了gen0和gen1集合的费用：

1. 许多垃圾收集器的行为有点类似于清理建筑物，方法是将所有有价值的东西移至另一座建筑物，炸毁原始建筑物，然后重建空壳。将gen0建筑物从gen0建筑物移动到gen1建筑物的gen0集合将相当快，因为​​gen0“建筑物”中没有太多东西。 Gen2集合必须移动更大的gen2建筑中的所有物品。垃圾收集系统可以将单独的建筑物用于较小的gen2对象和较大的gen2对象，并通过跟踪自由空间的各个区域来管理较大的建筑物，但是与试图管理所有单个存储区域相比，移动较小的对象并回收存储批发物的工作量较小。可以重新使用。但是，在这里观察代的关键点是，即使有必要扫描gen1或gen2对象，也不必移动它，因为其中的“建筑物”并不是立即拆除的目标。 / p>

2. 许多系统使用“卡表”，该卡可以记录自上次gen0或gen1收集以来是否已写入每个4K内存块，或包含用于修改对象的引用。这显着减慢了对任何此类存储区域的首次写入速度，但是在gen0和gen1收集期间，可以跳过对许多对象的检查。卡表使用方式的细节各不相同，但是基本概念是，如果代码具有大量引用，但其中大多数都位于未标记的4K块内，GC甚至无需查看这些块就可以知道通过它们可以访问的任何较新的对象 也可以通过其他方式访问，因此可以找到所有gen0对象，而不必费心看这些块。

请注意，即使没有卡表的简单垃圾收集系统也可以简单方便地从世代GC的原理中受益。例如，在Commodore 64 BASIC（其垃圾收集器非常慢）上，创建了许多寿命很长的字符串的程序可以通过使用几个peek和poke语句来调整字符串的顶部，从而避免冗长的垃圾收集周期。堆指针位于长寿命字符串的底部正下方，因此不会考虑将它们用于重定位/回收。如果程序使用了数百个在整个程序执行过程中都将持续的字符串（例如，从00到FF的两位数的十六进制字符串表），以及少数其他字符串，则这可能会使垃圾回收时间减少大约一个数量级。幅度。

,

想到的几个原因：

1. 它们更大。收集gen1也意味着收集gen0，进行gen2收集意味着收集所有三个。 gen0收集最频繁，因此低代的尺寸也较小，因此需要便宜。
2. 收集的主要成本是幸存对象数量的函数，而不是死亡对象的数量。世代垃圾收集器是建立在世代假说的基础上的，世代假说说对象倾向于生存很短时间或很长时间，但并不经常居于中间。从Gen0集合的定义来看，它们主要由该世代中死亡的对象组成，因此，集合很便宜：gen1和gen2集合具有更高的存活对象比例（理想情况下，gen2应该仅包含 可以生存的物品），因此价格更高。
3. 如果某个对象在gen0中，则只能由其他gen0对象或更新后的一代代对象引用该对象。因此，要查看是否引用了gen0中的一个对象，GC需要检查其他gen0对象，以及仅检查那些已更新为指向较低代对象（GC跟踪的更高代）的对象（请参阅“卡表” ”）。要查看是否引用了gen1对象，需要检查gen0和gen1的全部，以及gen2中更新的对象。