We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
$ 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:
-m -m
./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:
const
./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.
The text was updated successfully, but these errors were encountered:
Change https://golang.org/cl/102895 mentions this issue: cmd/compile: more accurate escape reason for nonconst array
cmd/compile: more accurate escape reason for nonconst array
Sorry, something went wrong.
360c191
No branches or pull requests
When compiling
-m -m
says: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: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.The text was updated successfully, but these errors were encountered: