Go Runtime: WriteBarrier

[GopherDaily]

在阅读 Go runtime 相关的代码时, 我们可以看到大量 write barrier 相关的代码或者注释, 大概可以猜到是和 GC 相关的, 具体用途和原理之前确并不知晓.

Go 的垃圾回收可以被简化为两个步骤: 标记(mark)和清除(sweep).

• 标记阶段, GC 将所有存活的对象标记为黑色.
• 清除阶段, GC 遍历内存将所有未被标记的对象回收.

GC 在标记阶段并不暂停所有协程的执行. 这就需要我们考虑, 如果对象的引用关系在标记阶段被修改了应该怎么办?

假设:

• t1 时, 对象 A 被标记为黑色, 即 A 引用的对象已都被 GC 发现并处理.
• t2 时, 用户新建了对象 C, 并将其赋值给 A 的字段 ref, 即 A.ref = C

由于 C 仅被 A 引用, 但 A 已被标记为黑色, 所以 GC 不会再去标记 C. 在随后的清除阶段, 虽然 C 依然被引用, 但是会因为未被标记而被 GC 的回收, 这显然时不可接受的.

为了处理这种情况, Go 引入 write barrier, 即由编译器在需要的地方插入相关代码处理.

我们构造一个相关的例子:

var sink *int

func main() {
        foo := []int{1, 2, 3}
        sink = &foo[1]
}

在生成的汇编代码中我们可以找到相关内容:

cat -n objdump | grep -A 100 "main.main>:"
...
138038          sink = &foo[1]
138039    4576b1:       48 8d 48 08             lea    0x8(%rax),%rcx
138040    4576b5:       83 3d d4 10 0a 00 00    cmpl   $0x0,0xa10d4(%rip)        # 4f8790 <runtime.writeBarrier>
138041    4576bc:       74 15                   je     4576d3 <main.main+0x53>
138042    4576be:       66 90                   xchg   %ax,%ax
138043    4576c0:       e8 1b d2 ff ff          call   4548e0 <runtime.gcWriteBarrier2>
138044    4576c5:       49 89 0b                mov    %rcx,(%r11)
138045    4576c8:       48 8b 05 51 32 07 00    mov    0x73251(%rip),%rax        # 4ca920 <main.sink>
138046    4576cf:       49 89 43 08             mov    %rax,0x8(%r11)
138047    4576d3:       48 89 0d 46 32 07 00    mov    %rcx,0x73246(%rip)        # 4ca920 <main.sink>
...

其逻辑是:

• 通过全局变量 runtime.writeBarrier 判断是否开启了 write barrier

  runtime.writeBarrier 是一个全局变量, 在进入标记段前开启, 进入清除阶段前关闭.

• 如果开启了, 则调用 runtime.gcWriteBarrier2 将对象保存到当前的 p, GMP 中的 p

  runtime.gcWriteBarrier2 是直接以会编实现的函数, 会将寄存器 AX 内的指针保存到 p.wbbuf.

• 标记阶段结束时, GC 会额外处理这些对象

  在结束标记前, GC 会为调用 wbBufFlush 处理这缓存的对象.

Link: https://github.com/j2gg0s/j2gg0s/blob/main/_posts/2023-11-01-Go%20Runtime%3A%20WriteBarrier.md