cmd/compile: []byte(string) incurs allocation even when it does not escape

[rogpeppe]

The following Go program reports that the function makes an allocation to do the string to []byte conversion, even though the compiler reports the conversion as non-escaping.

https://play.golang.org/p/y2d2RiYqK5

It prints:

  48 B/op	       1 allocs/op

Given that the compiler has marked it as non-escaping, I'd expect no allocations.

go version devel +eab99a8 Mon Jun 26 21:12:22 2017 +0000 linux/amd64

[randall77]

It's non-escaping, but its size is unknown. We need to allocate []byte of unknown size on the heap.

[bcmills]

We shouldn't even need to do that if the slice isn't mutated, right? (How hard would it be to make the escape analysis also do mutability?)

[rogpeppe]

For the record I encountered this issue when passing a string to hex.Decode. Mutability analysis would be amazing, but just avoiding the allocation would be nice.

[bradfitz]

Dup of #2205 ?

[rogpeppe]

Although the particular example would be fixed if #2205 was fixed, I don't think it's quite the same issue. I hadn't realised that all variable-length allocations escaped (strictly speaking that's not true, because []byte(string) where len(string)<=32 is stack-allocated), and I'm not sure that others do either.

I'm probably not the only one who was using -gcflags -m output as a proxy for whether there's an allocation or not. Given that we're (I presume) not about to make some kind of instant-free arena for variable-length items, perhaps another way of addressing this issue might be to change the output printed by the -m flag to make it clearer that this the result of this kind of operation may actually escape to the heap.

[robpike]

Sure, it's escaped to the heap but that's as far as it will get. The guard towers that surround the heap are well-manned and your memory will never get outside the heap's walls. You can relax.

[andybons]

@rogpeppe is your proposal to change the output of the -m flag to make this clearer? Is this worthy of a proposal or NeedsDecision? Trying to figure out next steps.

[bradfitz]

Unplanned, needs fix, performance.

No decision needed. This is just work, and somewhat tricky work.

[andybons]

Thanks, Brad. Updated.

[josharian]

Given that we're (I presume) not about to make some kind of instant-free arena for variable-length items

Cross-reference: #20533