On Fri, Mar 27, 2020 at 8:19 AM Leszek Kubik <leszek.ku...@gmail.com> wrote:
> A fix for the situation of the topic could be implemented by the slice type. > Imagine, if a slice value not only shared the pointer to the underlying > buffer but also a list with references to all other slices holding on to the > underlying buffer then such operation as s = s[x:y] could walk the list, find > and free all unreferenced values in the underlying buffer (perhaps even > assigning zero value to have consistent behavior regardless of []T or []*T). > Such operation would be deterministic. Of course there could be an > optimization in place, whenever the slice was derived from a named array, > just keep some flag instead of the list of references to all other slices. I > don't see how GC could achieve that in a consistent way since the GC may not > even do the swipe between calls like s = s[:x]; s = s[:cap(x)]. Unfortunately > I'm afraid that this would break some existing code (even if we also trim the > cap property) thus keeping in mind the original notion of a slice as a window > to some array makes sense to me. For many, if not most programs the current approach is quite ok. The suggested solution is non trivial, especially in terms of runtime and memory consumption costs. Not only _all_ programs will get slower, but the added memory overhead can sometimes dwarf the memory savings. If a specific program has the problem of "zombie" slice elements, which is BTW the same problem as keeping a short string sliced from of a huge string, then in both the cases the solution is to make a copy of the part that is needed to keep, thus allowing the GC to take care of the original backing array. -- 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/CAA40n-WVFpUQDmf0oohmCG4tfSstUcszVJcgNnbAHs%2BJxHM%3DXg%40mail.gmail.com.
