如何解决雪兰多亚自我修复的障碍
标题几乎说明了一切-这些自我修复障碍是什么，为什么它们在Shenandoah 2.0中很重要？
解决方法
这种解释将piggy绕在the first part和the second part上，而我试图将其放在Shenandoah 2.0周围。
要真正回答这个问题，我们通常需要研究load reference barrier的实现方式以及GC cycle的行为。
当触发某个GC cycle时，它首先选择垃圾最多的区域；即：集合集中中的对象很少（将来会很重要）。
理解该主题的最简单方法是通过示例。假设这是现在在特定区域中存在的方案：
refA refB
|
---------
| mark |
---------
| i = 0 |
| j = 0 |
---------
该区域中存在一个对象，并且有两个指向它的引用：refA和refB。 GC进入，并选择该区域进行垃圾收集。 同时应用程序中有活动线程试图通过refA和refB访问此对象。由于此对象在某个时刻是alive，因此需要撤离到新区域（mark-compact阶段的一部分）。
因此：GC是 active ，同时，我们通过refA/refB read 。进行此阅读时，我们将踏入load-reference-barrier，已实施here。请注意，它在内部有一些“过滤器”（通过一堆if/else语句）。具体来说：
-
它检查“疏散当前是否在进行中”。这是通过在首次开始疏散时设置的线程局部标志来完成的。我们假设答案是：是的。
-
它检查我们当前正在操作的对象是否在“集合集中”。这意味着它当前被标记为活动。让我们假设这也是“是”。
-
最后一个检查是查明此对象是否已“复制”到其他区域（已撤离）。我们假设对此的答案是“否”，即：
obj == fwd。
此时，发生了一些事情。首先创建一个副本，然后mark becomes forwardee
refA refB
|
-------------- ---------
| forwardee | ---- | mark |
-------------- ---------
| i = 0 | | i = 0 |
| j = 0 | | j = 0 |
--------- ---------
仅在代码的稍后部分，refA和refB将被更新以指向 new （已复制）对象。但这意味着一件有趣的事情。这意味着直到实际使refA和refB指向新对象之前，它们当前指向的对象都在“集合集中”。因此，如果GC处于活动状态，即使已经建立forwardee，load-reference-barrier仍然需要做一些工作。
因此Shenandoah后面的非常聪明的人这样说：为什么在forwardee建立之后（或{{1} }已为其他参考资料所知）？ And this is exactly what they did。
让我们回到最初的图纸：
forwardee同样，我们“启用”所有过滤器：
-
有一个通过
读取的线程refA refB | --------- | mark | --------- | i = 0 | | j = 0 | --------- -
GC已激活
-
refA和refA之后的对象还活着。
这就是“自我修复障碍”所发生的情况：
refB区别很明显： refB refA
| |
-------------- ---------
| forwardee | ---- | mark |
-------------- ---------
| i = 0 | | i = 0 |
| j = 0 | | j = 0 |
--------- ---------
已通过refA移至当场指向新对象。如果将再次通过CAS进行 的读取（GC仍处于活动状态），这将导致更快地执行负载引用屏障。为什么？因为refA指向“集合集中” 不是的对象。
但这也意味着，如果我们通过refA进行读取并看到refB-在第一次读取时，代码可以做同样的技巧并更新fwd != obj通过refB发生了。
据知情人士说，这可以提高性能，我相信他们。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。