Go 垃圾回收(二)屏障技术

  • 什么是屏障?
  • golang 涉及到的三个写屏障
  • 原理分析
    • 示例分析代码
    • 先看逃逸分析
    • 写屏障真实的样子

什么是屏障?

承接上篇概述,下面讨论什么是写屏障?先说结论:

  1. 内存屏障只是对应一段特殊的代码
  2. 内存屏障这段代码在编译期间生成
  3. 内存屏障本质上在运行期间拦截内存写操作,相当于一个 hook 调用

golang 涉及到的三个写屏障

  1. 插入写屏障
  2. 删除写屏障
  3. 混合写屏障(旁白:其实本质上是两个,混合写屏障就是插入写屏障和删除写屏障的混合)

这三个名词什么意思?区别在哪里?

最本质的区别就是:我们说了,内存屏障其实就是编译器帮你生成的一段 hook 代码,这三个屏障的本质区别就是 hook 的时机不同而已。

原理分析

声明下,下面的例子使用的是 go1.13.3。

示例分析代码

一直说,写屏障是编译器生成的,先形象看下代码样子:

  1 package main
  2 
  3 type BaseStruct struct {
  4     name string
  5     age  int
  6 }
  7 
  8 type Tstruct struct {
  9     base   *BaseStruct
 10     field0 int
 11 }
 12 
 13 func funcAlloc0 (a *Tstruct) {
 14     a.base = new(BaseStruct)    // new 一个BaseStruct结构体,赋值给 a.base 字段
 15 }
 16 
 17 func funcAlloc1 (b *Tstruct) {
 18     var b0 Tstruct
 19     b0.base = new(BaseStruct)  // new 一个BaseStruct结构体,赋值给 b0.base 字段
 20 }
 21 
 22 func main() {
 23     a := new(Tstruct)    // new 一个Tstruct 结构体
 24     b := new(Tstruct)   // new 一个Tstruct 结构体
 25     
 26     go funcAlloc0(a)
 27     go funcAlloc1(b)
 28 }

这里例子,可以用来观察两个东西:

  1. 概述篇提到的逃逸分析
  2. 编译器插入内存屏障的时机

先看逃逸分析

为什么先看逃逸分析?

因为只有堆上对象的写才会可能有写屏障,这又是个什么原因呢?因为如果对栈上的写做拦截,那么流程代码会非常复杂,并且性能下降会非常大,得不偿失。根据局部性的原理来说,其实我们程序跑起来,大部分的其实都是操作在栈上,函数参数啊、函数调用导致的压栈出栈啊、局部变量啊,协程栈,这些如果也弄起写屏障,那么可想而知了,根本就不现实,复杂度和性能就是越不过去的坎。

继续看逃逸什么意思?就是内存分配到堆上。golang 可以在编译的时候使用 -m 参数支持把这个可视化出来:

$ go build -gcflags "-N -l -m" ./test_writebarrier0.go 
# command-line-arguments
./test_writebarrier0.go:13:18: funcAlloc0 a does not escape
./test_writebarrier0.go:14:17: new(BaseStruct) escapes to heap
./test_writebarrier0.go:17:18: funcAlloc1 b does not escape
./test_writebarrier0.go:19:18: funcAlloc1 new(BaseStruct) does not escape
./test_writebarrier0.go:23:13: new(Tstruct) escapes to heap
./test_writebarrier0.go:24:13: new(Tstruct) escapes to heap

先说逃逸分析两点原则

  1. 在保证程序正确性的前提下,尽可能的把对象分配到栈上,这样性能最好;
    1. 栈上的对象生命周期就跟随 goroutine ,协程终结了,它就没了
  2. 明确一定要分配到堆上对象,或者不确定是否要分配在堆上的对象,那么就全都分配到堆上;
    1. 这种对象的生命周期始于业务程序的创建,终于垃圾回收器的回收

我们看到源代码,有四次 new 对象的操作,经过编译器的“逃逸分析”之后,实际分配到堆上的是三次:

  1. 14 行 —— 触发逃逸(分配到堆上)
    1. 这个必须得分配到堆上,因为除了这个 goroutine 还要存活呢
  2. 19 行 —— 无 (分配到栈上)
    1. 这个虽然也是 new,单就分配到栈上就行,因为 b0 这个对象就是一个纯粹的栈对象
  3. 23 行 —— 触发逃逸 (分配到堆上)
    1. 这个需要分配到堆上,因为分配出来的对象需要传递到其他协程使用
  4. 24 行 —— 触发逃逸 (分配到堆上)
    • 这次必须注意下,其实站在我们上帝视角,这次的分配其实也可以分配到栈上。这种情况编译器就简单处理了,直接给分配到堆上。这种就属于编译器它摸不准的,那么分配到堆上就对了,反正也就性能有点影响,功能不会有问题,不然的话你真分配到栈上了,一旦栈被回收就出问题了

写屏障真实的样子

再看下编译器汇编的代码:

关注我公众号, 获取更多干货

从这个地方我们需要知道一个事情,go 的关键字语法呀,其实在编译的时候,都会对应到一个特定的函数,比如 new 这个关键字就对应了 newobject 函数,go 这个关键字对应的是 newproc 函数。贴一张比较完整的图:

关注我公众号, 获取更多干货

从这个汇编代码我们也确认了,23,24行的对象分配确实是在堆上。我们再看下函数 funcAlloc0funcAlloc1 这两个。

main.funcAlloc0

 13 func funcAlloc0 (a *Tstruct) {
 14     a.base = new(BaseStruct)    // new 一个BaseStruct结构体,赋值给 a.base 字段
 15 }

关注我公众号, 获取更多干货

简单的注释解析:

(gdb) disassemble 
Dump of assembler code for function main.funcAlloc0:
   0x0000000000456b10 <+0>:     mov    %fs:0xfffffffffffffff8,%rcx
   0x0000000000456b19 <+9>:     cmp    0x10(%rcx),%rsp
   0x0000000000456b1d <+13>:    jbe    0x456b6f <main.funcAlloc0+95>
   0x0000000000456b1f <+15>:    sub    $0x20,%rsp
   0x0000000000456b23 <+19>:    mov    %rbp,0x18(%rsp)
   0x0000000000456b28 <+24>:    lea    0x18(%rsp),%rbp
   0x0000000000456b2d <+29>:    lea    0x1430c(%rip),%rax        # 0x46ae40
   0x0000000000456b34 <+36>:    mov    %rax,(%rsp)
   0x0000000000456b38 <+40>:    callq  0x40b060 <runtime.newobject>
   # newobject的返回值在 0x8(%rsp) 里,golang 的参数和返回值都是通过栈传递的。这个跟 c 程序不同,c 程序是溢出才会用到栈,这里先把返回值放到寄存器 rax
   0x0000000000456b3d <+45>:    mov    0x8(%rsp),%rax           
   0x0000000000456b42 <+50>:    mov    %rax,0x10(%rsp)
   # 0x28(%rsp) 就是 a 的地址:0xc0000840b0
=> 0x0000000000456b47 <+55>:    mov    0x28(%rsp),%rdi         
   0x0000000000456b4c <+60>:    test   %al,(%rdi)
   # 这里判断是否开启了屏障(垃圾回收的扫描并发过程,才会把这个标记打开,没有打开的情况,对于堆上的赋值只是多走一次判断开销)
   0x0000000000456b4e <+62>:    cmpl   $0x0,0x960fb(%rip)        # 0x4ecc50 <runtime.writeBarrier>
   0x0000000000456b55 <+69>:    je     0x456b59 <main.funcAlloc0+73>
   0x0000000000456b57 <+71>:    jmp    0x456b68 <main.funcAlloc0+88>
   # 赋值 a.base = xxxx
   0x0000000000456b59 <+73>:    mov    %rax,(%rdi)
   0x0000000000456b5c <+76>:    jmp    0x456b5e <main.funcAlloc0+78>
   0x0000000000456b5e <+78>:    mov    0x18(%rsp),%rbp
   0x0000000000456b63 <+83>:    add    $0x20,%rsp
   0x0000000000456b67 <+87>:    retq   
   # 如果是开启了屏障,那么完成 a.base = xxx 的赋值就是在 gcWriteBarrier 函数里面了
   0x0000000000456b68 <+88>:    callq  0x44d170 <runtime.gcWriteBarrier>
   0x0000000000456b6d <+93>:    jmp    0x456b5e <main.funcAlloc0+78>
   0x0000000000456b6f <+95>:    callq  0x44b370 <runtime.morestack_noctxt>
   0x0000000000456b74 <+100>:   jmp    0x456b10 <main.funcAlloc0>
End of assembler dump.

所以,从上面简单的汇编代码,我们印证得出几个小知识点

  1. golang 传参和返回参数都是通过栈来传递的(可以思考下优略点,有点是逻辑简单了,也能很好的支持多返回值的实现,缺点是比寄存器的方式略慢,但是这种损耗在程序的运行下可以忽略);
  2. 写屏障是一段编译器插入的特殊代码,在编译期间插入,代码函数名字叫做 gcWriteBarrier
  3. 屏障代码并不是直接运行,也是要条件判断的,并不是只要是堆上内存赋值就会运行 gcWriteBarrier 代码,而是要有一个条件判断。这里提前透露下,这个条件判断是垃圾回收器扫描开始前,stw 程序给设置上去的;
    1. 所以平时对于堆上内存的赋值,多了一次写操作;

伪代码如下:

if runtime.writeBarrier.enabled {
    runtime.gcWriteBarrier(ptr, val)
} else {
    *ptr = val
}

说到 golang 传参数只用栈这点,这里就再深入挖掘一点,golang ABI(Application Binary Interface)标准就是这样的,传参数用栈,返回值也用栈。但是巧了,刚好,就有一些特例,我们今天遇到的 runtime.gcWriteBarrier 就是个特例,gcWriteBarrier 就故意违反了这个惯例,这里引用一段这汇编文件的注释:

// gcWriteBarrier performs a heap pointer write and informs the GC. // // gcWriteBarrier does NOT follow the Go ABI. It takes two arguments: // - DI is the destination of the write // - AX is the value being written at DI // It clobbers FLAGS. It does not clobber any general-purpose registers, // but may clobber others (e.g., SSE registers).

这里为了减少 GC 导致性能的损耗,使用了 rdi ,rax ,这两个寄存器来传参数:

  1. rdi :堆内存写入的地址
  2. rax :赋的值

我们继续看下 runtime·gcWriteBarrier 函数干啥的,这个函数是用纯汇编写的,举一个特定cpu集合的例子,在 asm_amd64.s 里的实现。这个函数只干两件事:

  1. 执行写请求
  2. 处理 GC 相关的逻辑

下面简单理解下 runtime·gcWriteBarrier 这个函数:

TEXT runtime·gcWriteBarrier(SB),NOSPLIT,$120

        get_tls(R13)
        MOVQ    g(R13), R13
        MOVQ    g_m(R13), R13
        MOVQ    m_p(R13), R13
        MOVQ    (p_wbBuf+wbBuf_next)(R13), R14

        LEAQ    16(R14), R14
        MOVQ    R14, (p_wbBuf+wbBuf_next)(R13)
    // 检查 buffer 队列是否满?
        CMPQ    R14, (p_wbBuf+wbBuf_end)(R13)

    // 赋值的前后两个值都会被入队

        // 把 value 存到指定 buffer 位置
        MOVQ    AX, -16(R14)   // Record value

    // 把 *slot 存到指定 buffer 位置
        MOVQ    (DI), R13
        MOVQ    R13, -8(R14)

    // 如果 wbBuffer 队列满了,那么就下刷处理,比如置灰,置黑等操作
        JEQ     flush
ret:
    // 赋值:*slot = val 
        MOVQ    104(SP), R14
        MOVQ    112(SP), R13
        MOVQ    AX, (DI)
        RET

flush:
    。。。

        //  队列满了,统一处理,这个其实是一个批量优化手段
        CALL    runtime·wbBufFlush(SB)

    。。。

        JMP     ret

思考下:不是说把 *slot = value 直接置灰色,置黑色,就完了嘛,这里搞得这么复杂?

最开始还真不是这样的,这个也是一个优化的过程,这里是利用批量的一个思想做的一个优化。我们再理解下最本质的东西,触发了写屏障之后,我们的核心目的是为了能够把赋值的前后两个值记录下来,以便 GC 垃圾回收器能得到通知,从而避免错误的回收。记录下来是最本质的,但是并不是要立马处理,所以这里做的优化就是,攒满一个 buffer ,然后批量处理,这样效率会非常高的。

wbBuf 结构如下:
8

每个 P 都有这么个 wbBuf 队列。

我们看到 CALL runtime·wbBufFlush(SB) ,这个函数 wbBufFlush 是 golang 实现的,本质上是调用 wbBufFlush1 。这个函数才是 hook 写操作想要做的事情,精简了下代码如下:

func wbBufFlush1(_p_ *p) {
        start := uintptr(unsafe.Pointer(&_p_.wbBuf.buf[0]))
        n := (_p_.wbBuf.next - start) / unsafe.Sizeof(_p_.wbBuf.buf[0])
        ptrs := _p_.wbBuf.buf[:n]

        _p_.wbBuf.next = 0

        gcw := &_p_.gcw
        pos := 0
    // 循环批量处理队列里的值,这个就是之前在 gcWriteBarrier 赋值的
        for _, ptr := range ptrs {
                if ptr < minLegalPointer {
                        continue
                }
                obj, span, objIndex := findObject(ptr, 0, 0)
                if obj == 0 {
                        continue
                }

                mbits := span.markBitsForIndex(objIndex)
                if mbits.isMarked() {
                        continue
                }
                mbits.setMarked()
                if span.spanclass.noscan() {
                        gcw.bytesMarked += uint64(span.elemsize)
                        continue
                }
                ptrs[pos] = obj
                pos++
        }

        // 置灰色(投入灰色的队列),这就是我们的目的,对象在这里面我们就不怕了,我们要扫描的就是这个队列;
        gcw.putBatch(ptrs[:pos])

        _p_.wbBuf.reset()
}

所以我们总结下,写屏障到底做了什么:

  1. hook 写操作
  2. hook 住了写操作之后,把赋值语句的前后两个值都记录下来,投入 buffer 队列
  3. buffer 攒满之后,批量刷到扫描队列(置灰)(这是 GO 1.10 左右引入的优化)

main.funcAlloc1

 17 func funcAlloc1 (b *Tstruct) {
 18     var b0 Tstruct
 19     b0.base = new(BaseStruct)  // new 一个BaseStruct结构体,赋值给 b0.base 字段
 20 }

关注我公众号, 获取更多干货

最后,再回顾看下 main.funcAlloc1 函数,这个函数是只有栈操作,非常简单。

下一篇,继续讲述插入写屏障究竟是什么东西?


坚持思考,方向比努力更重要。关注公众号:奇伢云存储,获取更多干货。 关注我公众号, 获取更多干货