这是一个创建于 221 天前的主题，其中的信息可能已经有所发展或是发生改变。
我正在实现一个并发的三色标记垃圾收集器，我看了一些帖子，里面描述的 1.14 之前，golang 无法强制停止 goroutine 从而无法启动开始 gc 。
我的疑问是，全局变量 runtime.writeBarrier 更新了之后，运行中的 goroutine 不就读到了 writeBarrier 并启动了写屏障么，为什么必须等待 goroutine 停止呢？
92 CMPL runtime.writeBarrier(SB), $0
99 JEQ 103
101 JMP 108
108 CALL runtime.gcWriteBarrier(SB)
---
更近一步，假设刚刚更新完读不到，那更新完等个几十 ms 还读不到么 🤔.
我的疑问是，全局变量 runtime.writeBarrier 更新了之后，运行中的 goroutine 不就读到了 writeBarrier 并启动了写屏障么，为什么必须等待 goroutine 停止呢？
92 CMPL runtime.writeBarrier(SB), $0
99 JEQ 103
101 JMP 108
108 CALL runtime.gcWriteBarrier(SB)
---
更近一步，假设刚刚更新完读不到，那更新完等个几十 ms 还读不到么 🤔.
 |
1
zmcity 221 天前
提高 gc 吞吐量。
|
 |
2
hankai17 221 天前
有种 atomic 的感觉
|
 |
4
waiY 221 天前
[粗线条话 GC （一）] https://www.bilibili.com/video/BV1hv411x7we?p=19
我看这里有简单解释了一下，GC 开始前需要 STW 通知全部的 g 开启写屏障，没有 STW 的话可能会导致部分的 g 开启写屏障有延时导致错误。至于”1.14 之前，golang 无法强制停止 goroutine 从而无法启动开始 gc “是因为 1.13 之前是依赖编译期间插入的代码来检测是否有 gc 在等待执行，如果代码中有个 for{}循环就会导致插入的代码无法执行，从而导致一直阻塞 |
 |
5
gav1nvv 221 天前
貌似和多线程引用计数需要记录指针调用，如果线程运行中启动，可能会影响指针记录，造成内存泄漏，所以等 goroutine 结束再启动
|
Select Language