混合写屏障的算法思想伪代码：

// 混合写屏障
func writePointer(slot, ptr unsafe.Pointer) {
    shade(*slot)                // 对正在被覆盖的对象进行着色，通过将唯一指针从堆移动到栈来防止赋值器隐藏对象。
    if current stack is grey {  // 如果当前 goroutine 栈还未被扫描为黑色
        shade(ptr)              // 则对引用进行着色，通过将唯一指针从栈移动到堆中的黑色对象来防止赋值器隐藏对象
    }
    *slot = ptr
}

如果当前 goroutine 栈已扫描为黑色，而 ptr 为白色对象，此时如果不对 ptr 着色，是否就误回收了对象？

实际描述

• 文件路径：https://github.com/changkun/go-under-the-hood/blob/master/book/zh-cn/part2runtime/ch06sched/init.md
• 原文段落：

P 的初始化，P 的状态转换图

问题描述

你好，在 procresize 中，对于收缩的 gomaxprocs 值，会将多出的 P 状态置为 _Pdead，同时释放其相关资源，但是不会释放掉 P 本身，这点在下文的 procresize 源码注释中也提到过。

	// 从未使用的 p 释放资源
	for i := nprocs; i < old; i++ {
		p := allp[i]
		p.destroy()
		// 不能释放 p 本身，因为他可能在 m 进入系统调用时被引用
	}

还有一点是 _Pdead 状态应该只可能在 procresize 中转换为 _Pidel，没可能转为 _Prunning 吧

说明

修改拼写错误。

变化箱单

• 修复了 book/zh-cn/part2runtime/ch06sched/schedule.md 的 typo 错误
• 修复了 book/backlog/sched/exec.md 的 typo 错误
• 修复了 gosrc/runtime/proc.go 的 typo 错误

实际描述

• 文件路径：under-the-hood/gosrc/sync/map.go
• 原文段落：L69

// 一个 entry 可以被原子替换为 nil 来删除：当 m.dirty 是下一个创建的，它会自动将 nil 替换为 expunged 且
// 让 m.dirty[key] 成为未设置的状态。

预期描述

// 一个 entry的p字段 可以被原子替换为 nil 来删除：当 m.dirty 是下一个创建的，它会自动将 nil 替换为 expunged 且
// 让 m.dirty[key] 成为未设置的状态。

resolve #66

说明

改进 gfget 中关于 g 的栈分配的注释。

变化箱单

• 修正了book/zh-cn/part2runtime/ch06sched/init.md 和 gosrc/runtime/proc.go中gfget代码注释。

参考文献

runtime/proc.go

// Put on gfree list.
// If local list is too long, transfer a batch to the global list.
func gfput(_p_ *p, gp *g) {
	if readgstatus(gp) != _Gdead {
		throw("gfput: bad status (not Gdead)")
	}

	stksize := gp.stack.hi - gp.stack.lo

	if stksize != _FixedStack {
		// non-standard stack size - free it.
		stackfree(gp.stack)
		gp.stack.lo = 0
		gp.stack.hi = 0
		gp.stackguard0 = 0
	}

	_p_.gFree.push(gp)
	_p_.gFree.n++
	if _p_.gFree.n >= 64 {
		lock(&sched.gFree.lock)
		for _p_.gFree.n >= 32 {
			_p_.gFree.n--
			gp = _p_.gFree.pop()
			if gp.stack.lo == 0 {
				sched.gFree.noStack.push(gp)
			} else {
				sched.gFree.stack.push(gp)
			}
			sched.gFree.n++
		}
		unlock(&sched.gFree.lock)
	}
}

实际描述

• 文件路径：https://github.com/changkun/go-under-the-hood/blob/master/book/zh-cn/part2runtime/ch08GC/basic.md
• 原文段落：

标记终止 | 保证一个周期内标记任务完成，停止写屏障 | STW | 关闭

预期描述

标记终止 | 保证一个周期内标记任务完成，停止写屏障 | STW | 开启

动机

关于8.11 过去、现在与未来章节有点疑问

需求说明

内容中阐述 Go 1：朴素标记清扫 在 Go 1 的时代，尽管所有的用户代码都是并发执行的，但是一旦垃圾回收器开始进行垃圾回收工作时，所有的用户代码都会停止执行，而且垃圾回收器仅在一个线程上执行，这时是最原始的垃圾回收器的实现，即单线程版的三色标记清扫。

Go 1.1, 1.3：并行清扫与精准标记 在 Go 1.3 时候，官方将三色标记清扫算法的垃圾回收代码改为并行，从而缩短了用户代码的停止时间，但是这仍然会造成大量的空隙，如果用户代码是一个 Web 应用，且正在处理一个非常重要的请求，则会对请求延迟造成巨大的影响。

其中 Go 1 朴素标记清扫的时候，应该不算是三色标记清扫，但稳重最后一句话【即单线程版的三色标记清扫。】，是否应该修改为【即单线程版的标记清扫】。

Go 1.1, 1.3：并行清扫与精准标记 其中【在 Go 1.3 时候，官方将三色标记清扫算法的垃圾回收代码改为并行】 是否应该修改为 【在 Go 1.3 时候，官方将标记清扫算法的垃圾回收代码改为并行】

问题描述

欧神你好，在《6.7.3 G 的创生》一章中，示例代码在新版本编译后有一些变化。以下是我的理解：

	0x001d 00029 (hello.go:8)	MOVL	$16, (SP) // 将 16 放到 SP 的位置，16 是第一个参数 siz，因为是 int32，所以是 MOVL。数字是 16 是因为有 string 和 string.len 两个参数加一起占 16 个字节
	0x0024 00036 (hello.go:8)	LEAQ	"".hello·f(SB), AX // 将 hello 的调用地址传给 AX
	0x002b 00043 (hello.go:8)	MOVQ	AX, 8(SP) // 将 hello 的调用地址放入 8(SP) 的位置
	0x0030 00048 (hello.go:8)	LEAQ	go.string."hello world"(SB), AX // 将“hello world”放入 AX
	0x0037 00055 (hello.go:8)	MOVQ	AX, 16(SP) // 将“hello world”放在 16(SP) 的位置
	0x003c 00060 (hello.go:8)	MOVQ	$11, 24(SP) // 将 $11 放在 24(SP) 的位置，11 是 string 的长度，string 是结构体，结构体在传参中会扁平化为多个参数

在新版本变化后，栈布局的图依然能帮助理解，但有些细节不一致了，在我看来现在的布局是这样的：

             栈布局
40(SP)+-----------------+      高地址
      |    caller BP    |       
32(SP)+-----------------+ <-- main.BP
      |  11 string.len  |
24(SP)+-----------------+ 
      |  "hello world"  |
16(SP)+-----------------+ <-- fn + sys.PtrSize
      |      hello      |
8(SP) +-----------------+ <-- fn
      |       siz       |
(SP)  +-----------------+ <-- SP
      |    newproc PC   |  
      +-----------------+ callerpc: 要运行的 Goroutine 的 PC
      |                 |
      |                 |       低地址

对比两个图，我有些疑惑： hello 函数地址现在占了 8 个字节，而不是原有图中的两个字节，是因为内存对齐的需求吗？ “hello world” 现在是字符串完整的值传递，而不是地址传递，是有什么区别吗？ “newproc PC” 是如何计算出的在 main.SP 下方的地址呢？我在生成的汇编代码中没有发现这里的处理。

环境

$ go version
go version go1.15.5 darwin/amd64

问题描述1

原文中的"在两种情况下由于普通的 map+mutex"，这句不知道是什么意思.

sync.Map 宣称内部做了特殊的优化，在两种情况下由于普通的 map+mutex。

https://github.com/golang-design/under-the-hood/blame/023270d971dc5c19e997e2277dfce4c172e92c67/book/zh-cn/part1basic/ch05sync/map.md#L8

问题描述2

这个性能对比图，不太明白纵坐标是什么意思。 在我的印象中，系统的sync.Map在读多写少的场景下是有优势的。 不知道这个图能不能体现出这个特性?

在测试中，我们测试了：n 个 key 中，每个 key 产生 1 次写行为，每个 key 产生 n 次读行为。
图1：map+sync.Mutex 、map+sync.RWMutex与 sync.Map 之间单次写多次读场景下的性能对比

https://github.com/golang-design/under-the-hood/blame/023270d971dc5c19e997e2277dfce4c172e92c67/book/zh-cn/part1basic/ch05sync/map.md#L13-L16

实际描述

• 文件路径：part2runtime/ch06sched/preemption
• 原文段落：

// 此程序在 Go 1.14 之前的版本不会输出 OK
package main
import (
	"runtime"
	"time"
)
func main() {
	for i := 0; i < runtime.GOMAXPROCS(0); i++ {
		go func() {
			for {
			}
		}()
	}
	time.Sleep(time.Millisecond)
	println("OK")
}

预期描述

// 此程序在 Go 1.14 之前的版本不会输出 OK
package main
import (
	"runtime"
	"time"
)
func main() {
	for i := 0; i < runtime.GOMAXPROCS(0); i++ {
		go func() {
			for {
			}
		}()
	}
	time.Sleep(time.Second)
	println("OK")
}

附图

问题描述

你好，我在学习这一章时了解到会在 mstart 中确定 m.g0 的栈边界，但是我在 darwin 系统中使用 gdb 进行调试时发现，第一个进入 mstart 中的线程（应该是 m0 吧），osStack = false，也就是说 g0 已经初始化完成了，请问是在哪里完成的这一步呢？

调试过程

系统：darwin

gdb b runtime.mstart

然后单步调试往下走，第一个进入断点的线程，osStack 是为false的，之后创建的都是 true。 后面创建的 M 是使用系统栈的这个我理解，在 allocm 中有根据系统判断是否使用系统栈，darwin 在判断逻辑中，但是第一个线程为啥没用系统栈呢......

问题描述

第二部分运行时 第七章节 内存分配 部分是基于哪个branch或者tag的？ 我看了golang 源码tag go 1.15没有7.4 大对象分配中的allocSpanLocked。 能否给出您描述的代码的commit id或者别的信息，有利于读者结合代码阅读。 请在此描述你的问题，提问前请参考提问的智慧

问题描述

在5.3 mutex一节中，开头有这么一句话

在正常模式中，等待者按照 FIFO 的顺序排队获取锁

我注意到这个是官方注释 在下文的unlockSlow方法中，正常唤醒逻辑的代码是runtime_Semrelease(&m.sema, false, 1)，您的注释是

唤醒一个阻塞的 goroutine，但不是唤醒第一个等待者

这两个说法是不是冲突了？

C.ref2 -> A，那么 shade(*slot)也就是shade(A)，应该是把A着色为灰色，为什么图中是把A置为白色、C置为灰色了？

func YuasaWritePointer(slot *unsafe.Pointer, ptr unsafe.Pointer) {
    shade(*slot)
    *slot = ptr
}

• 原文段落：8.2写屏障技术，图3：使用Yuasa写屏障赋值器

ps：还是同一个图，这个地方地方的文字和图不匹配，应该是YuasaWritePointer(C.ref3, B)吧

动机

init 相关内容已过时

需求说明

在 runtime.main 中关于 init 调用部分有更新，包括编译器部分。 相关 commit：https://github.com/golang/go/commit/d949d0b9252be1fffeadd65183a6bab3acf3de7a 本人水平有限，勉强能看懂一些，但还远远达不到能提 PR 修改此处。期待相关更新。

ps.这个项目能重启真是太好了 🎉