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 <[email protected]
> <javascript:>> wrote:
> > On Thu, Mar 23, 2017 at 9:16 AM, Caleb Spare <[email protected]
> <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 [email protected].
For more options, visit https://groups.google.com/d/optout.
