On Tue, May 8, 2018 at 12:51 PM, <klo...@gmail.com> wrote: > > On Tuesday, May 1, 2018 at 10:15:08 PM UTC+2, Ian Lance Taylor wrote: >> >> On Tue, May 1, 2018 at 1:00 PM, <time...@gmail.com> wrote: >> > >> > I looked at the source but can't understand it well enough. >> > >> > If I allocate a [1000]byte, or a []byte, I understand the GC will need >> > to >> > mark the slice/array itself for collection. However, does the GC mark >> > all >> > the bytes within, and does the marking phase attempt to follow all the >> > items? >> >> A [1000]byte value holds no pointers, so the GC marks that value once >> and does not look inside it. >> >> A []byte holds a single pointer, to the backing array, and the backing >> array holds no pointers, so the GC marks the []byte and the backing >> array, and then stops. >> >> > > Interesting. And what happens in this case: > > type Foo struct { > s string > } > > func makeFoo() *Foo { > buf := make([]byte,16) > foo := (*Foo)(unsafe.Pointer(&buf)) > foo.s = "Hello World!" > return foo > } > > If I understand you correctly, the GC would consider the string "Hello > World!" to be collectable, because its only pointer is in memory that should > not hold pointers. Or does the assignment of foo.s add some mark to the > memory block that it now may contain pointers?
That program is not one of the valid unsafe.Pointer patterns documented at https://golang.org/pkg/unsafe, so it is invalid. As you say, the string "Hello World!" could be collected by the GC. With the current implementations the string is likely to be in read-only memory so it would not be collected, but of course future implementations may act differently. In the current implementations the assignment to foo.s does not add any marking to the memory block. It would remain marked as not containing any pointers. > If I changed buf to > > buf := make([]unsafe.Pointer,16) > > would that make things work? Now the GC knows that buf may contain pointers > and if I understand correctly it doesn't need to know the type of pointer. That would still be invalid according to the unsafe.Pointer docs. The results would be different. The representation of a string is both a pointer and a length. With this change, you would be storing the length into a field marked as containing a pointer. In other words, you would have an invalid pointer value. The most likely result would be a crash when the garbage collector tried to mark the memory to which that pointer points. 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.