I'm guessing this is related to the same related questions about "bytes.Buffer" and escape analysis.
The golang protobuf package (https://github.com/golang/protobuf) has a "proto.Buffer" type (https://github.com/golang/protobuf/blob/master/proto/lib.go#L309). The following program always heap allocates it: " package trial import ( "log" "github.com/gogo/protobuf/proto" "google.golang.org/trial/codec_perf" // irrelevant protobuf code generated by protoc compiler ) func main() { // protobuf struct here is irrelevant, any valid argument will cause the behavior p := &codec_perf.Buffer{} // b gets heap allocated b := &proto.Buffer{} b.SetBuf(make([]byte, proto.Size(p))) if err := b.Marshal(p); err != nil { log.Fatal(err) } } " compiling with: 'go build -gcflags "-m=1"' shows at the bottom of the log: " # google.golang.org/trial ./main.go:17: inlining call to (*proto.Buffer).SetBuf ./main.go:17: make([]byte, proto.Size(p)) escapes to heap ./main.go:17: p escapes to heap ./main.go:12: &codec_perf.Buffer literal escapes to heap ./main.go:15: &proto.Buffer literal escapes to heap ./main.go:19: p escapes to heap ./main.go:20: err escapes to heap ./main.go:20: main ... argument does not escape " FYI output of "go version": 'go version devel +4cce27a3fa Sat Jan 21 03:20:55 2017 +0000 linux/amd64' This might just be a golang/protobuf issue, but it also seems very similar to https://github.com/golang/go/issues/7661. Wondering is this just due to escape analysis missing the opportunity? Possibly heap allocs like this will go away in a future version? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.