Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: incorrect escape reason for heap-allocated array with var len/cap #24578

Closed
ALTree opened this issue Mar 28, 2018 · 1 comment
Closed
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@ALTree
Copy link
Member

ALTree commented Mar 28, 2018

$ go version
go version devel +377a2cb2d2 Tue Mar 27 18:03:39 2018 +0000 linux/amd64

When compiling

package p

func f() {
	n := 32
	workBuf := make([]int, 0, n)
	// ... do some local work on workBuf
	_ = workBuf
}

-m -m says:

./test.go:5:17: make([]int, 0, n) escapes to heap
	from make([]int, 0, n) (too large for stack) at ./test.go:5:17

The given reason for the escape ("too large for stack") is wrong. The same-sized allocation is put on the stack when the bound is a const 32:

./test.go:5:17: f make([]int, 0, 32) does not escape

The real reason for the escape is that we don't stack-allocate arrays when the len/cap is a variable.

Someone using -m -m when investigating an allocation profile may be thrown off by the incorrect explanation.

@ALTree ALTree added the NeedsFix The path to resolution is known, but the work has not been done. label Mar 28, 2018
@ALTree ALTree added this to the Unplanned milestone Mar 28, 2018
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/102895 mentions this issue: cmd/compile: more accurate escape reason for nonconst array

@golang golang locked and limited conversation to collaborators Mar 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

2 participants