It seems the issue has to do with the compiler inlining `foo`. If I add the
compiler directive `//go:noinline` above `foo` and run `go test` the test
fails, just like when I run `go test -covermode=atomic`. This makes sense
because if the function is inlined and the slice is allocated on the sta
Interesting, I actually ran into some odd behavior with this function that
I'm not sure how to explain. Consider the following test:
import (
"reflect"
"testing"
"unsafe"
)
func sliceToStringUnsafe(v []byte) string {
var s string
sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
sh.D
That is a worry, but escape analysis can handle this case. It understands
flow of pointers through unsafe.Pointer and uintptr. As a consequence, in
this example it forces the array to be allocated on the heap.
The runtime has on occasion a need to hide values from escape analysis. It
has to
It just occurred to me that there may actually be a problem with the
conversion functions in the example. Specifically, since the Go
compiler can allocate byte slices on the heap if they do not escape, the
following function may be invalid:
func foo() string {
v := []uint64{1,2,3}
Filed: https://github.com/golang/go/issues/19687
On Thu, Mar 23, 2017 at 4:41 PM, 'Keith Randall' via golang-nuts
wrote:
>
>
> On Thursday, March 23, 2017 at 4:24:40 PM UTC-7, Caleb Spare wrote:
>>
>> That's very good to know. Thanks, Ian.
>>
>> Unfortunately if I use this KeepAlive-based fix, p
On Thursday, March 23, 2017 at 4:24:40 PM UTC-7, Caleb Spare wrote:
>
> That's very good to know. Thanks, Ian.
>
> Unfortunately if I use this KeepAlive-based fix, p escapes and so the
> function now allocates. I guess I'll stick with the original version
> from my first email.
>
> Does this
That's very good to know. Thanks, Ian.
Unfortunately if I use this KeepAlive-based fix, p escapes and so the
function now allocates. I guess I'll stick with the original version
from my first email.
Does this indicate a shortcoming of either compiler support for
KeepAlive or escape analysis in ge
On Thu, Mar 23, 2017 at 9:16 AM, Caleb Spare wrote:
>
> Brief follow-up: does the seeming validity of the code rely at all on
> the fact that the indicated line is written as a single line? What if,
> instead, a *StringHeader var were extracted?
>
> func stringToSliceUnsafe(s string) []uint64 {
>
Thanks Ian, that's very helpful.
Brief follow-up: does the seeming validity of the code rely at all on
the fact that the indicated line is written as a single line? What if,
instead, a *StringHeader var were extracted?
func stringToSliceUnsafe(s string) []uint64 {
var v []uint64
h
That only applies to []byte. I have a []uint64.
On Feb 23, 2017 4:13 AM, "T L" wrote:
>
>
> On Wednesday, February 22, 2017 at 6:53:53 AM UTC+8, Caleb Spare wrote:
>>
>> I have a program that uses unsafe in order to coerce some slices to
>> strings for use as map keys. (Avoiding these allocation
On Wednesday, February 22, 2017 at 6:53:53 AM UTC+8, Caleb Spare wrote:
>
> I have a program that uses unsafe in order to coerce some slices to
> strings for use as map keys. (Avoiding these allocations ends up being
> an important performance optimization to this program.)
>
> Here's some exa
On Tue, Feb 21, 2017 at 2:53 PM, Caleb Spare wrote:
> I have a program that uses unsafe in order to coerce some slices to
> strings for use as map keys. (Avoiding these allocations ends up being
> an important performance optimization to this program.)
>
> Here's some example code that shows what
12 matches
Mail list logo
