There is no conservativeness to unsafe.Pointer. The type information for any object in the heap is recorded at allocation time, and is unrelated to the type of the reference currently held to it (be it unsafe.Pointer, []byte, *int64, or whatever). So for 2.2, the answer is no, you are incorrect.
You can allocate your backing store with make([]int64, (numBits+63)/64) and then store &a[0] in your BitSlice type (assuming numBits>0). You can type that as *int64 or unsafe.Pointer. I would use the latter just because it is clearer to the reader that shenanigans are in progress. On Monday, August 20, 2018 at 4:56:00 PM UTC-7, Kevin Malachowski wrote: > > That information is old now - Go has a precise GC now. There is some sort > of metadata stored for each variable related to whether the type contains > pointers (as Jan alluded to earlier in the thread). > > On Monday, August 20, 2018 at 7:28:51 AM UTC-7, Florian Uekermann wrote: >> >> From the GC POV, the only interesting thing about an unsafe.Pointer is if >>> its value falls anywhere into a GC managed memory block for liveness >>> analysis, AFAIK. >>> >> And then it will check that memory block for stuff that looks like a >> pointer (not caring what the actual type being pointed to is) afaik. That >> is what I meant with conservative GC. >> I found a thread from 2013, where Ian says the same >> https://groups.google.com/forum/#!topic/golang-nuts/yNis7bQG_rY. >> Maybe my information is outdated, I haven't followed the GC evolution in >> recent years that closely. >> > -- 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.
