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 indicate a shortcoming of either compiler support for > KeepAlive or escape analysis in general? > > KeepAlive shouldn't be making things escape. If that is happening you should file a bug for it. The definition is:
//go:noinline func KeepAlive(interface{}) {} which should be pretty easy to analyze :) Caleb > > On Thu, Mar 23, 2017 at 10:26 AM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > > On Thu, Mar 23, 2017 at 9:16 AM, Caleb Spare <ces...@gmail.com > <javascript:>> 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 { > >> var v []uint64 > >> h := (*reflect.StringHeader)(unsafe.Pointer(&s)) // <-- > >> sh := (*reflect.SliceHeader)(unsafe.Pointer(&v)) > >> sh.Data = h.Data > >> sh.Len = h.Len >> 3 > >> sh.Cap = h.Len >> 3 > >> return v > >> } > >> > >> (Play link: https://play.golang.org/p/BmGtYTsGNY) > >> > >> Does h keep s alive? A strict reading of rule 6 doesn't seem to say > >> that keeping a *StringHeader or *SliceHeader around keeps the > >> underlying string/slice alive (but it's sort of implied by the rule 6 > >> example code, which doesn't refer to s after converting it to a > >> *StringHeader). > > > > That is an interesting point. I don't think there is anything keeping > > s alive here. I think this isn't quite the same as the example in the > > docs, because that example is assuming that you are doing to use s > > after setting the fields--why else would you be doing that? In this > > case it does seem theoretically possible that s could be freed between > > the assignment to h and the use of h.Data. With the current and > > foreseeable toolchains it's a purely theoretical problem, since there > > is no point there where the goroutine could be preempted and the fact > > that s is no longer referenced be detected. But as a theoretical > > problem it does seem real. One fix would be something like > > p := &s > > h := (*reflect.StringHeader)(unsafe.Pointer(p)) > > sh := (*reflect.SliceHeader)(unsafe.Pointer(&v)) > > sh.Data = h.Data > > sh.Len = ... > > sh.Cap = ... > > runtime.KeepAlive(p) > > > > Ian > -- 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.