Golang Writeb

总述

本文会分析gc中 writeBarrier、bitmap 、writeBuffer技术.

背景

写屏障这个技术是从 go1.5引入的, 是三色标记的gc需要的一个策略, 后来在go1.8中, 消除rescan的设计中进行了升级, 使用了混合屏障, 避免了rescan的STW的消耗. gc过程中, 除了写屏障技术, 在mark阶段也进行了优化, 使用 bitmap 替换了sweep流程, 避免sweep带来的性能问题: 遍历堆、缓存亲和力差.

分析

源码路径: mwbuf.go mbarrier.go

mbarrier

mbarrier.go的注释很全了. (和proposal一致) 通过注释知道, golang使用了 Yuasa-style deletetion barrier 和 Dijkstra insertion barrier. shade(染色)和condition work 一起工作避免了修改器对gc隐藏了对象. 方法如下

当从堆上unlink object 的时候, 进行染色, 将唯一的指针从堆上移动到栈上
当将指针安装到黑色对象, 进行染色. 将唯一指针从栈移动到黑色对象.
一旦goroutine栈是黑色的, 就没必要染色了

主要用来:

内存顺序的解决
stack write
global writes
publication ordering
singal handler pointer writes

在实现上, 是在类似memmove的操作前面

使用场景

mgcmark.go

mbitmap.go

writebuffer

每个p都有一个wirte buffer queue 作为 pool. 填满之后就会刷新到 gc workbuf.

数据结构

type wbBuf struct {
    // next points to the next slot in buf. It must not be a
    // pointer type because it can point past the end of buf and
    // must be updated without write barriers.
    //
    // This is a pointer rather than an index to optimize the
    // write barrier assembly.
    next uintptr

    // end points to just past the end of buf. It must not be a
    // pointer type because it points past the end of buf and must
    // be updated without write barriers.
    end uintptr

    // buf stores a series of pointers to execute write barriers
    // on. This must be a multiple of wbBufEntryPointers because
    // the write barrier only checks for overflow once per entry.
    buf [wbBufEntryPointers * wbBufEntries]uintptr
}

其实, next、end 都是指向 buf的下一个和最后一个. 其中, 每次的pointer都是放两个指针: old、new. 在 wbBufFlush的实现中, 就是进行染成灰色、标记.

使用场景

在atomic.Value的实现和分析中, StorePointer会先调用 atomicwb: 在原子指针写之前执行写屏障操作.

其他

消除STW stack rescan的讨论

golang1.7 使用 Dijkstra write barrier 处理并发指针修改. 因为读取远大于写入, 所以性能好. 但是呢, golang 在stack write 的时候, 不是使用 stack write barrier, 而是 STW期间进行re scan. 这样的话, 如果有大量的活跃的goroutine, re scan stack 会消耗大概 10-100 毫秒的时间.
golang后面的版本采用混合屏障策略, 所有新分配的对象都是黑色的 (以前都是白色的), 这样, 就不需要进行 stack rescan, 从而节省了大量时间. hybrid barrier 通过初始scan 的时候stack标黑, 实现在标记阶段的时候, 允许并发scan, 相比而言, Dijkstra barrier 允许并发mark, 但是在标记的最终时候->rescan stack 需要一次STW. Yuasa 在标记mark的一开始的时候, 需要一次 STW(获取stack快照), 但是在 mark最终的时候, 并不需要rescan. 参考文献: elimate rescan

参考

一个比较清晰的版本梳理