Yes, this is a limitation of the current escape analysis.  It doesn't 
realize that the proto.Buffer can be stack allocated.
I suspect this is because b.Marshal is recursive, and escape analysis gives 
up on recursive things.

On Tuesday, March 7, 2017 at 8:22:42 PM UTC-8, apo...@google.com wrote:
>
> 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