java - 为什么并发 GC 需要 remark 阶段

Question

并发 GC 需要 remark 阶段。 remark phase的作用是在concurrent mark phase中标记被修改的对象。但我认为如果我们只在concurrent mark phase 标记新创建的对象，就没有必要执行remark phase。

remark phase 是因为对象被修改了。修改可以是两种类型。一个是创建新对象，另一个是修改指向另一个对象的指针。如果我们标记新创建的对象，就可以轻松解决新对象问题。而修改指向另一个对象的指针实际上不是问题。因为

Dead object can not revive

死对象意味着没有人可以指向该对象。他们如何复活？所以修改后的指针应该指向已经标记好的对象。这意味着不需要执行remark。

有人可能会说，“在创建新对象时对其进行标记太昂贵了。因此它们不能在并发标记阶段期间进行标记，这就是为什么remark phase需要”。这似乎是合理的。但这会引起另一个问题。 remark 怎么可能不从根开始遍历每一个对象呢？如果remark phase要从根开始遍历每一个对象，concurrent mark phase所做的工作是无用的。或者，如果remark phase只遍历修改过的对象，则修改对象的信息应该保存在某个地方。我认为这可能比仅仅标记要昂贵得多。

我错了吗？应该是错的。但是我不知道哪一点是错误的。

Answer 1

And modified pointer to another object is not a problem in fact. Because

Dead object can not revive

他们真的不能，但是你知道哪些对象是死的吗？不!为什么？

在初始标记阶段之后您并不知道它，因为您只查看线程堆栈而没有遵循引用。

你不知道在并发标记阶段之后是否会发生如下情况:

• 线程读取字段 a.x 并将其值存储在其寄存器中(或其堆栈或其他地方)。
• 然后这个线程设置a.x = null(或其他东西)。
• GC 出现并在那里看到 null。
• 然后线程将a.x 恢复到它之前的值。

现在，GC 错过了 a.x 指向的对象。虽然上述场景不是很常见，但它可能会发生，并且存在更现实(和更复杂)的场景。

所以需要再次查看修改后的内存，也就是remark阶段。幸运的是，不必再次扫描整个内存，因为 card table习惯了。

---

我害怕this (otherwise nice) explanation在这一点上有点误导:

The remark phase is a stop-the-world. CMS cannot correctly determine which objects are alive (mark them live), if the application is running concurrently and keeps changing what is live.

线程确实改变了什么是活的，但它们也改变了你可以看到的活的。这就是问题所在。

This article说得很清楚:

Part of the work in the remark phase involves rescanning objects that have been changed by an application thread (i.e., looking at the object A to see if A has been changed by the application thread so that A now references another object B and B was not previously marked as live).

我会说:当你搜查一个房间又一个房间时，你可能会因为 child 四处移动眼镜而遗漏了眼镜。

关于场景的注释

我很确定，上述情况是可能的，只是程序通常不会这样做。对于一个非常现实的例子，考虑

void swap(Object[] a, int i, int j) {
    Object tmp = a[i];
    a[i] = a[j];
    // Now the original reference a[i] is in a register only.
    a[j] = tmp;
}