并行压缩收集器算法

Question

我有两个问题。其中一个会把话题弄得乱七八糟：）

1）我遇到了一个问题，即无法找到关于不同垃圾收集器在Hotspot中如何工作的完整信息。但我不是在谈论垃圾收集器工作的一般描述（我们在互联网上有很多这样的信息），我是在谈论具体的算法。我找到了这本白皮书（Java HotSpot虚拟机中的内存管理）http://www.oracle.com/technetwork/Java/javase/tech/memorymanagement-whitepaper-1-150020.pdf。但它只有大致的想法。它对并行压缩算法（我指的是并行标记-扫描-压缩）有很好的描述（可能不是很好--见我的第二个问题），但它没有解释其他垃圾收集器的算法。然而，这份白皮书是我能在互联网上找到的最好的信息。我想知道的是，从哪里获得关于不同垃圾收集器如何工作的完整描述/信息（对于年轻一代，我的意思是:ParNew、DefNew、psyounggen；对于老一代:PSOLdGen、ParOldGen、Concurrent-Mark-Sweep）。不敢相信这些信息对用户来说是不可用的。

下面列出了我不能理解的事情：

那么，这是否意味着，当我们有一个区域包含98-99%的活物体和2-1%的死物体（换句话说，死物体的很小百分比）时，压缩这个区域不值得从这样一个区域中恢复的空间。然而，这些微小的空闲空间（空穴）最终会被填满，在垃圾收集完成后就不会有空穴了。

>

所以总结阶段做的第一件事是检查区域的密度，从最左边的区域开始，直到它达到一个点，即可以从一个区域和它右边的区域恢复的空间值得压缩这些区域的成本。

嗯，如果我们有很大比例的死物体，比这个区域更值得压缩，对吗？

>

该点右侧的区域将被压缩，消除所有死区。

请澄清它们将如何压实。每个区域都将单独压实？我想没有。所以也许这里会有某种转变？

>

摘要阶段为每个压缩区域计算并存储活动数据的第一个字节的新位置。

Answer 1

这只是对一个算法的一般描述。这种描述可以有不同的细节。在本例中，它给出了大部分细节，但仍为实现者留下一些选择。

关于你的问题：

1. 所以“摘要阶段”没有发生压缩？上一阶段的目的仅仅是查找所有可用空间吗？-是的，这是正确的。摘要阶段收集索引数据，并基本上确定所有必要的内容，以便压缩阶段可以执行复制。它们没有说明如何实现压缩，但默认的方法是简单地将每个活动对象放在前一个对象旁边。基本上，所有空的空间都被移除，在压缩步骤完成后，您就有了一个连续的内存块，其中包含所有活动对象。我明白你对第四部分的困惑，但请注意，它是用将来时写的：“will be compact”--所以不是在摘要时，而是在以后。
2. 是[...]的意思吗压缩此区域不值得从这样一个区域中恢复的空间？是的，没错。您基本上会损失一些空间，但用内存来换取执行速度是非常常见的。确切的密度阈值取决于实现，但我将使用内存占总内存的比率阈值估计在70-90%左右。