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.

Sign up for GitHub

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

Jump to bottom

cmd/compile: "escapes to heap" for arrays with capacity from variable regression #13093

Closed
mkevac opened this issue Oct 29, 2015 · 4 comments
Closed

cmd/compile: "escapes to heap" for arrays with capacity from variable regression #13093

mkevac opened this issue Oct 29, 2015 · 4 comments
Labels
FrozenDueToAge
Milestone
Go1.6

Comments

@mkevac
Copy link
Contributor

mkevac commented Oct 29, 2015

Consider this simple example:

$ cat 1.go 
package main

func main() {
    l := 123

    buf := make([]byte, 0, l)
    _ = buf

    buf2 := make([]byte, 0, 123)
    _ = buf2
}

http://play.golang.org/p/mGfIERaXRL

$ go version
go version go1.4.3 linux/amd64
$ go build -gcflags=-m 1.go 
# command-line-arguments
./1.go:3: can inline main
./1.go:6: main make([]byte, 0, l) does not escape
./1.go:9: main make([]byte, 0, 123) does not escape

$ go version
go version go1.5 linux/amd64
$ go build -gcflags=-m 1.go
# command-line-arguments
./1.go:3: can inline main
./1.go:6: make([]byte, 0, l) escapes to heap
./1.go:9: main make([]byte, 0, 123) does not escape

array escapes to heap in 1.5, but does not escape in 1.4
@mdempsky mdempsky changed the title "escapes to heap" for arrays with capacity from variable regression cmd/compile: "escapes to heap" for arrays with capacity from variable regression Oct 29, 2015
@ianlancetaylor ianlancetaylor added this to the Go1.6 milestone Oct 29, 2015
@dr2chase
Copy link
Contributor

Evidence (assembly language, and s/123/32000000) suggests that go 1.4 was in fact performing a heap allocation and not being entirely honest about it. So, not a bug.

    0x0022 00034 (.../eth.go:4) MOVQ    $123,AX
    0x0029 00041 (.../eth.go:6) MOVQ    $type.[]uint8+0(SB),BX
    0x0030 00048 (.../eth.go:6) MOVQ    BX,(SP)
    0x0034 00052 (.../eth.go:6) MOVQ    $0,8(SP)
    0x003d 00061 (.../eth.go:6) MOVQ    AX,16(SP)
    0x0042 00066 (.../eth.go:6) PCDATA  $0,$0
    0x0042 00066 (.../eth.go:6) CALL    ,runtime.makeslice(SB)
    0x0047 00071 (.../eth.go:6) NOP ,

makeslice calls newarray calls mallocgc.

@randall77
Copy link
Contributor

I think there is some conflation of concerns here. We must heap allocate if the value either escapes or is variable sized. go1.4 is correct in saying buf does not escape.

Does escape analysis in 1.5 mark variable-sized allocations as escaping? That's not technically correct, but it's academic at this point because it will get heap allocated either way. But it may matter at some point in the future (per-goroutine private heaps? Function-local alias analysis?)

@dr2chase
Copy link
Contributor

For purposes of not losing our minds in the escape analysis code, "escapes" and "heap allocated" are one and the same. There are some latent bugs in the 1.4 escape-analysis code, some related to constant-but-very-large allocations being late-escaped to the heap -- and potentially dragging pointers to the stack with them because the allocation was moved after escape analysis ran.

I think most people who care about this flag care about the "heap allocated" part, so perhaps we should change the message to be clearer?

@randall77
Copy link
Contributor

I see now, heap->stack pointers bad. Changing the message sounds good, although it might not be worth the big CL that would entail.

@golang golang locked and limited conversation to collaborators Nov 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.6
Development

No branches or pull requests
5 participants
@mkevac @dr2chase @ianlancetaylor @randall77 @gopherbot