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.

Reply via email to