You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
// skipping
What did you do?
package main
funcmain() {
thing:=make([]byte, 65536) // also ran with 65535, which is < 64KiB
}
Ran with go run -gcflags '-m -m' alloc.go
What did you expect to see?
message should say it escapes to heap because of a max value (not sure if this is an escape analysis impl determined value, or more related to my architecture or setup of the stack, or a mix of those)
What did you see instead?
./alloc.go:7:13: make([]byte, 65537) escapes to heap:
./alloc.go:7:13: flow: {heap} = &{storage for make([]byte, 65537)}:
./alloc.go:7:13: from make([]byte, 65537) (non-constant size) at ./alloc.go:7:13
it will not escape when I use 65535 instead of 65536.
The text was updated successfully, but these errors were encountered:
ALTree
changed the title
allocation escapes to heap with "non-constant size" with constant size >= 64K
cmd/compile: allocation escapes to heap with "non-constant size" with constant size >= 64K
Sep 26, 2020
Thanks for reporting this. The problem is at the following check in escape.go:
why := "too large for stack"
if n.Op == OMAKESLICE && (!Isconst(n.Left, CTINT) || !Isconst(n.Right, CTINT)) {
why = "non-constant size"
}
In OMAKESLICE nodes, n.Left is the length and n.Right is the capacity. In a call with implied capacity like make([]byte, 65536), n.Right will be nil, so Isconst(n.Right, CTINT) will return false, and we print non-constant size instead of the correct message.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?// skipping
What did you do?
Ran with
go run -gcflags '-m -m' alloc.go
What did you expect to see?
message should say it escapes to heap because of a max value (not sure if this is an escape analysis impl determined value, or more related to my architecture or setup of the stack, or a mix of those)
What did you see instead?
it will not escape when I use
65535
instead of65536
.The text was updated successfully, but these errors were encountered: