> Basically, it's hard to be sure that there isn't any other slice somewhere that might permit references to that trailing memory
Ian, I am kind of curious about this case. I understand that "hard" is not "impossible", but still - if I copy the needed part to a smaller array, how does the GC knows that there are no more slices pointing to a part of an old allocation? Andrey On Thursday, July 18, 2019 at 9:16:27 AM UTC-6, Ian Lance Taylor wrote: > > On Thu, Jul 18, 2019 at 7:24 AM robfig <rob...@gmail.com <javascript:>> > wrote: > > > > I was curious if reducing the capacity of slice makes that memory > available to be reclaimed? > > > > (1) Reducing capacity using a three-index: > > > > var s = make([]int64, 1e9) > > ... add data to s, keeping a count .. > > s = s[:n:n] // reduce length and capacity to number of items read > > > > (2) Reducing capacity by slicing off the front, as happens when using > slice as a queue > > > > var s []int64 > > s = append(s, 1, 2, 3, 4, 5) > > s = s[5:] > > > > Should I be careful to allocate a new slice and copy over, if I want to > avoid that memory being pinned until the original slice goes out of scope? > > In the current implementations, reducing the capacity of the slice > does not cause the trailing memory to be released. Basically, it's > hard to be sure that there isn't any other slice somewhere that might > permit references to that trailing memory. > > There has been some discussion of changing the garbage collector to > support this, but it's not simple. > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20609e66-8733-4318-98c3-6bb5d4a953ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
