“泄漏/泄漏”在Golang逃逸分析中的意义是什么？

Question

func main() {
        i1 := 1
    A1(&i1)
}

func A1(i1 *int) *int {
    return i1
}

逃逸分析的结果是

./main.go:18:9: parameter i1 leaks to \~r1 with derefs=0:
./main.go:18:9:   flow: \~r1 = i1:
./main.go:18:9:     from return i1 (return) at ./main.go:19:2
./main.go:18:9: leaking param: i1 to result \~r1 level=0

parameter i1 leaks to \~r1 with derefs=0和leaking param: i1 to result \~r1 level=0的含义是什么？

首先我尝试谷歌golang escape leaking，最相关的结果是escape-analysis-shows-channel-as-leaking-param的评论。

“你为什么这么想？”可以合理地假定泄漏是严重的，并与其阀杆泄漏有关。我很难想出这样一个例子:漏油是件好事，比如漏桶，漏油罐，漏水，电容器漏，漏船，漏水抽提物。对于高性能的go专家来说，这可能是显而易见的，但是对于我们其他人来说，链接到docs并提供对泄漏param所指的内容的简短澄清将是有帮助的。

这是我想问的同样的问题，但在此之后就不再有答复了。

然后，我尝试读取打印这些结果的源代码。

在编译/内部/转义/泄漏。中，我找到了一些评论

// a泄漏表示来自参数的一组赋值流。 //堆或其任何函数(第一个numEscResults) //结果参数。

但我不明白，有没有官方文件来代表它。

此外，在源代码中我还发现了一个问题。如果numEscResults(7)后的结果参数将在运行时转义到堆中？

func main() {
    i1, i2, i3, i4, i5, i6, i7, i8, i9 := 1, 1, 1, 1, 1, 1, 1, 1, 1
    A1(&i1, &i2, &i3, &i4, &i5, &i6, &i7, &i8, &i9)
    return
}

func A1(i1, i2, i3, i4, i5, i6, i7, i8, i9 *int) (*int, *int, *int, *int, *int, *int, *int, *int, *int) {
    return i1, i2, i3, i4, i5, i6, i7, i8, i9
}

...some duplicate output
./main.go:16:13: leaking param: i2 to result ~r10 level=0
./main.go:16:17: leaking param: i3 to result ~r11 level=0
./main.go:16:21: leaking param: i4 to result ~r12 level=0
./main.go:16:25: leaking param: i5 to result ~r13 level=0
./main.go:16:29: leaking param: i6 to result ~r14 level=0
./main.go:16:33: leaking param: i7 to result ~r15 level=0
./main.go:16:37: leaking param: i8
./main.go:16:41: leaking param: i9
./main.go:8:30: i8 escapes to heap:
./main.go:8:30:   flow: {heap} = &i8:
./main.go:8:30:     from &i8 (address-of) at ./main.go:9:40
./main.go:8:30:     from A1(&i1, &i2, &i3, &i4, &i5, &i6, &i7, &i8, &i9) (call parameter) at ./main.go:9:4
./main.go:8:34: i9 escapes to heap:
./main.go:8:34:   flow: {heap} = &i9:
./main.go:8:34:     from &i9 (address-of) at ./main.go:9:45
./main.go:8:34:     from A1(&i1, &i2, &i3, &i4, &i5, &i6, &i7, &i8, &i9) (call parameter) at ./main.go:9:4
./main.go:8:30: moved to heap: i8
./main.go:8:34: moved to heap: i9

Answer 1

参数i1泄漏到~r1与derefs=0和泄漏param的含义是什么: i1导致~r1 level=0

TLDL:如果您正在寻找分配，忽略泄漏的param，寻找“移动到堆”块。

“泄漏param”意味着该函数在返回后以某种方式使其参数保持活动，这并不意味着它将被移到堆中，事实上，大部分“泄漏params”都在堆栈上分配。

"r1“指函数的返回值，从0开始，所以"r1”指的是第二个返回值。(与OP提供的示例代码不匹配，应该是r0)，如果第一个片段泄漏" i1“，因为"r0 =i1”，所以第0‘函数返回值为"i1“，因此"i1”必须在返回后保持活动，“泄漏”给调用者。

编译器输出中“泄漏参数”之前的部分是因为OP使用' -m '，它打印数据流图。

对于deref，请参阅cmd/compile/internal/escape/escape中的注释。

..。取消引用操作的数量减去寻址操作的数量被记录为边缘的权重(称为“deref”)。

" level“没有在当前的注释中进行描述，而且自从我熟悉gc源代码以来已经有一段时间了，据我所知，它是内存间接级、间接(*)操作增量、address-of (&)递减，因此这个函数

func A1(a **int) *int {
    p := &a
    return **p
}

应该给出一个泄漏的a和level=1。

此外，在源代码中我还发现了一个问题。如果numEscResults(7)之后的结果参数将在运行时转义到堆中？

是的，所有的结果(阅读，返回)，在第7‘，依赖于泄漏的参数将被移到堆，我不知道确切的原因，7，但我可以猜测，从经验的gc源代码，这是一个不太慢编译的值，但保留大多数函数的优化