目的

インライン展開により、-gcflags でmoved to heap が出力されても、ヒープにエスケープしない場合もあるということを理解する。

環境

$ go version
go version go1.23.2 linux/amd64

検証

(1) ヒープにエスケープしないパターン

moved to heap: res が出力されているが、f()はインライン展開されるので、resはヒープにエスケープしない。
moved to heap: resの部分の出力は、あくまでも、その関数のスコープしか見ていないことに注意しよう。つまり、f()関数だけを見ており、呼び出し元でインライン展開されるかどうかは全く気にしていない。
ベンチマークテストにおける0 allocs/opという結果や、<runtime.newobject> が出力されない結果を見れば、resがヒープにエスケープしてないことがわかるだろう。
後の(2)の例では、0000000000466c00 <main.f>の出力があるが、今回はf()が完全にmain()にインライン展開されているので、f()についての出力はない。

main.go

package main

func main() {
	_ = f()
}

func f() *int {
	y := 2
	res := y * 2
	return &res
}

main_test.go

package main

import "testing"

func Benchmark(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = f()
	}
}

ubuntu@ip-172-31-33-158:~/gopractice$ go build -gcflags "-m=2" .
# gopractice
./main.go:7:6: can inline f with cost 15 as: func() *int { y := 2; res := y * 2; return &res }
./main.go:3:6: can inline main with cost 19 as: func() { _ = f() }
./main.go:4:7: inlining call to f
./main.go:9:2: res escapes to heap:
./main.go:9:2:   flow: ~r0 = &res:
./main.go:9:2:     from &res (address-of) at ./main.go:10:9
./main.go:9:2:     from return &res (return) at ./main.go:10:2
./main.go:9:2: moved to heap: res

$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: gopractice
cpu: Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
Benchmark-2     1000000000               0.3741 ns/op          0 B/op          0 allocs/op
PASS
ok      gopractice      0.422s

$ go build -o main_binary main.go
$ objdump -d main_binary
...
0000000000466be0 <main.main>:
  466be0:       c3                      ret
  466be1:       cc                      int3
  466be2:       cc                      int3
  466be3:       cc                      int3
  466be4:       cc                      int3
  466be5:       cc                      int3
  466be6:       cc                      int3
  466be7:       cc                      int3
  466be8:       cc                      int3
  466be9:       cc                      int3
  466bea:       cc                      int3
  466beb:       cc                      int3
  466bec:       cc                      int3
  466bed:       cc                      int3
  466bee:       cc                      int3
  466bef:       cc                      int3
  466bf0:       cc                      int3
  466bf1:       cc                      int3
  466bf2:       cc                      int3
  466bf3:       cc                      int3
  466bf4:       cc                      int3
  466bf5:       cc                      int3
  466bf6:       cc                      int3
  466bf7:       cc                      int3
  466bf8:       cc                      int3
  466bf9:       cc                      int3
  466bfa:       cc                      int3
  466bfb:       cc                      int3
  466bfc:       cc                      int3
  466bfd:       cc                      int3
  466bfe:       cc                      int3
  466bff:       cc                      int3
...

(2) ヒープにエスケープするパターン

//go:noinline があるので、f()はインライン展開されず、resはヒープにエスケープする。
ベンチマークテストの1 allocs/opという結果や、call 40b2e0 <runtime.newobject>という出力結果を見れば、resがヒープにエスケープされていることがわかるだろう。

main.go

package main

func main() {
	_ = f()
}

//go:noinline
func f() *int {
	y := 2
	res := y * 2
	return &res
}

main_test.go

同上

ubuntu@ip-172-31-33-158:~/gopractice$ go build -gcflags "-m=2" .
# gopractice
./main.go:8:6: cannot inline f: marked go:noinline
./main.go:3:6: can inline main with cost 61 as: func() { _ = f() }
./main.go:10:2: res escapes to heap:
./main.go:10:2:   flow: ~r0 = &res:
./main.go:10:2:     from &res (address-of) at ./main.go:11:9
./main.go:10:2:     from return &res (return) at ./main.go:11:2
./main.go:10:2: moved to heap: res

$ go test -bench=. -benchmem
goos: linux
goarch: amd64
pkg: gopractice
cpu: Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
Benchmark-2     61113674                16.46 ns/op            8 B/op          1 allocs/op
PASS
ok      gopractice      1.031s

$ go build -o main_binary main.go
$ objdump -d main_binary
...
0000000000466be0 <main.main>:
  466be0:       49 3b 66 10             cmp    0x10(%r14),%rsp
  466be4:       76 0b                   jbe    466bf1 <main.main+0x11>
  466be6:       55                      push   %rbp
  466be7:       48 89 e5                mov    %rsp,%rbp
  466bea:       e8 11 00 00 00          call   466c00 <main.f>
  466bef:       5d                      pop    %rbp
  466bf0:       c3                      ret
  466bf1:       e8 2a b1 ff ff          call   461d20 <runtime.morestack_noctxt.abi0>
  466bf6:       eb e8                   jmp    466be0 <main.main>
  466bf8:       cc                      int3
  466bf9:       cc                      int3
  466bfa:       cc                      int3
  466bfb:       cc                      int3
  466bfc:       cc                      int3
  466bfd:       cc                      int3
  466bfe:       cc                      int3
  466bff:       cc                      int3

0000000000466c00 <main.f>:
  466c00:       49 3b 66 10             cmp    0x10(%r14),%rsp
  466c04:       76 21                   jbe    466c27 <main.f+0x27>
  466c06:       55                      push   %rbp
  466c07:       48 89 e5                mov    %rsp,%rbp
  466c0a:       48 83 ec 10             sub    $0x10,%rsp
  466c0e:       48 8d 05 eb 67 00 00    lea    0x67eb(%rip),%rax        # 46d400 <type:*+0x5400>
  466c15:       e8 c6 46 fa ff          call   40b2e0 <runtime.newobject>
  466c1a:       48 c7 00 04 00 00 00    movq   $0x4,(%rax)
  466c21:       48 83 c4 10             add    $0x10,%rsp
  466c25:       5d                      pop    %rbp
  466c26:       c3                      ret
  466c27:       e8 f4 b0 ff ff          call   461d20 <runtime.morestack_noctxt.abi0>
  466c2c:       eb d2                   jmp    466c00 <main.f>
  466c2e:       cc                      int3
  466c2f:       cc                      int3
  466c30:       cc                      int3
  466c31:       cc                      int3
  466c32:       cc                      int3
  466c33:       cc                      int3
  466c34:       cc                      int3
  466c35:       cc                      int3
  466c36:       cc                      int3
  466c37:       cc                      int3
  466c38:       cc                      int3
  466c39:       cc                      int3
  466c3a:       cc                      int3
  466c3b:       cc                      int3
  466c3c:       cc                      int3
  466c3d:       cc                      int3
  466c3e:       cc                      int3
  466c3f:       cc                      int3
...

おまけ

速度

ヒープにエスケープしない場合よりも、ヒープにエスケープした場合の方が明らかに時間がかかっている。具体的には、前者が0.3741 ns/opであり、後者が16.46 ns/opである。
ヒープにエスケープしない場合は、resのコピーを呼び出し元に返す。
ヒープにエスケープする場合は、resのアドレスのコピーを呼び出し元に返し、さらに、resそのものをスタック領域からヒープ領域にコピーする必要がある。
ヒープへの読み書き速度は、スタックへの読み書き速度よりもはるかに遅いため、このような時間差が生まれる。
ポインタを返せば、速度が速くなると安易に考えるのは非常に危険である。

参考