hybrid write barrier 為什麼能消除 stack rescanning？

這兩天看了一下 eliminate stack rescanning 那個 proposal，感覺很困惑。

stack rescanning 的初衷是因為 write barrier 太重，所以棧上變數的讀寫是不會加 write barrier 的，所以自然需要在 mark termination STW 時重掃一遍棧。但是現在，棧上變數讀寫仍然不加 hybrid write barrier，那麼與 mark 併發的棧上變數的修改還是無法被 GC 觀測到。考慮一下例子：

a 和 b 均為棧上變數，型別為指標，c 為堆上記憶體。

a = c mark start, a 和 b 作為根物件入隊 a = nil a 出隊，被染黑 b 出隊，被染黑 b = c mark termination

至此，c 還是白的，會被回收。

我想了一下，hybrid write barrier 有效的前提是，逃逸分析百分百可靠，堆上記憶體一定會有一個堆上的引用，這樣在堆上引用被移動到棧上時 deletion barrier 就會發揮作用。問題在於現在 Go 的逃逸分析並不是百分百準確的。所以我很困惑。

ref:

https://golang.org/src/cmd/compile/internal/ssa/writebarrier.go#L16 的 needwb 函式中展示了在何時新增 barrier，顯然棧上讀寫是不加 barrier 的。

那個 proposal: https://github.com/golang/proposal/blob/master/design/17503-eliminate-rescan.md