Does go garbage collect parts of slices?

If I implement a queue like this...

package main

import(
	"fmt"
)

func PopFront(q *[]string) string {
	r := (*q)[0]
	*q = (*q)[1:len(*q)]
	return r
}

func PushBack(q *[]string, a string) {
	*q = append(*q, a)
}

func main() {
	q := make([]string, 0)
	
	PushBack(&q, "A")
	fmt.Println(q)
	PushBack(&q, "B")
	fmt.Println(q)
	PushBack(&q, "C")
	fmt.Println(q)
	
	PopFront(&q)
	fmt.Println(q)
	PopFront(&q)
	fmt.Println(q)    	
}

... I end up with an array ["A", "B", "C"] that has no slices pointing to the first two elements. Since the "start" pointer of a slice can never be decremented (AFAIK), those elements can never be accessed.

Is Go's garbage collector smart enough to free them?

Slices are just descriptors (small struct-like data structures) which if not referenced will be garbage collected properly.

The underlying array for a slice (to which the descriptor points to) on the other hand is shared between all slices that are created by reslicing it: quoting from the Go Language Specification: Slice Types:

> A slice, once initialized, is always associated with an underlying array that holds its elements. A slice therefore shares storage with its array and with other slices of the same array; by contrast, distinct arrays always represent distinct storage.

Therefore if at least one slice exists, or a variable holding the array (if a slice was created by slicing the array), it will not be garbage collected.

Official Statement about this:

The blog post Go Slices: usage and internals By Andrew Gerrand clearly states this behaviour:

> As mentioned earlier, re-slicing a slice doesn't make a copy of the underlying array. The full array will be kept in memory until it is no longer referenced. Occasionally this can cause the program to hold all the data in memory when only a small piece of it is needed.
>
> ...
>
> Since the slice references the original array, as long as the slice is kept around the garbage collector can't release the array.

Back to your example

While the underlying array will not be freed, note that if you add new elements to the queue, the built-in append function occasionally might allocate a new array and copy the current elements to the new – but copying will only copy the elements of the slice and not the whole underlying array! When such a reallocation and copying occurs, the "old" array may be garbage collected if no other reference exists to it.

Also another very important thing is that if an element is popped from the front, the slice will be resliced and not contain a reference to the popped element, but since the underlying array still contains that value, the value will also remain in memory (not just the array). It is recommended that whenever an element is popped or removed from your queue (slice/array), always zero it (its respective element in the slice) so the value will not remain in memory needlessly. This becomes even more critical if your slice contains pointers to big data structures.

func PopFront(q *[]string) string {
    r := (*q)[0]
    (*q)[0] = ""  // Always zero the removed element!
    *q = (*q)[1:len(*q)]
    return r
}

This is mentioned Slice Tricks wiki page:

> ### Delete without preserving order
>
> a[i] = a[len(a)-1]
> a = a[:len(a)-1]
>
> NOTE If the type of the element is a pointer or a struct with pointer fields, which need to be garbage collected, the above implementations of Cut and Delete have a potential memory leak problem: some elements with values are still referenced by slice a and thus can not be collected.

No. At the time of this writing, the Go garbage collector (GC) is not smart enough to collect the beginning of an underlying array in a slice, even if it is inaccessible.

As mentioned by others here, a slice (under the hood) is a struct of exactly three things: a pointer to its underlying array, the length of the slice (values accessible without reslicing), and the capacity of the slice (values accessible by reslicing). On the Go blog, slice internals are discussed at length. Here is another article I like about Go memory layouts.

When you reslice and cut off the tail end of a slice, it is obvious (upon understanding the internals) that the underlying array, the pointer to the underlying array, and the slice's capacity are all left unchanged; only the slice length field is updated. When you re-slice and cut off the beginning of a slice, you are really changing the pointer to the underlying array along with the length and capacity. In this case, it is generally unclear (based on my readings) why the GC does not clean up this inaccessible part of the underlying array because you cannot re-slice the array to access it again. My assumption is that the underlying array is treated as one block of memory from the GC's point of view. If you can point to any part of the underlying array, the entire thing is ineligible for deallocation.

I know what you're thinking... like the true computer scientist you are, you may want some proof. I'll indulge you:

https://goplay.space/#tDBQs1DfE2B

As mentioned by others and as shown in the sample code, using append can cause a reallocation and copy of the underlying array, which allows the old underlying array to be garbage collected.

Simple question, simple answer: No. (But if you keep pushing the slice will at some point overflow its underlying array then the unused elements become available to be freed.)

Contrary to what I'm reading, Golang certainly seems to garbage collect at least unused slices starting sections. The following test case provides evidence.

In the first case the slice is set to slice[:1] in each iteration. In the comparison case, it skips that step.

The second case dwarfs the memory consumed in the first case. But why?

func TestArrayShiftMem(t *testing.T) {
	slice := [][1024]byte{}

	mem := runtime.MemStats{}
	mem2 := runtime.MemStats{}
	runtime.GC()
	runtime.ReadMemStats(&mem)

	for i := 0; i < 1024*1024*1024*1024; i++ {
		slice = append(slice, [1024]byte{})
		slice = slice[1:]
		runtime.GC()

		if i%(1024) == 0 {
			runtime.ReadMemStats(&mem2)
			fmt.Println(mem2.HeapInuse - mem.HeapInuse)
			fmt.Println(mem2.StackInuse - mem.StackInuse)
			fmt.Println(mem2.HeapAlloc - mem.HeapAlloc)

		}
	}
}


func TestArrayShiftMem3(t *testing.T) {
	slice := [][1024]byte{}

	mem := runtime.MemStats{}
	mem2 := runtime.MemStats{}
	runtime.GC()
	runtime.ReadMemStats(&mem)

	for i := 0; i < 1024*1024*1024*1024; i++ {
		slice = append(slice, [1024]byte{})
		// slice = slice[1:]
		runtime.GC()

		if i%(1024) == 0 {
			runtime.ReadMemStats(&mem2)
			fmt.Println(mem2.HeapInuse - mem.HeapInuse)
			fmt.Println(mem2.StackInuse - mem.StackInuse)
			fmt.Println(mem2.HeapAlloc - mem.HeapAlloc)

		}
	}
}

Output Test1:

go test -run=.Mem -v .
...
0
393216
21472
^CFAIL	github.com/ds0nt/cs-mind-grind/arrays	1.931s

Output Test3:

go test -run=.Mem3 -v .
...
19193856
393216
19213888
^CFAIL	github.com/ds0nt/cs-mind-grind/arrays	2.175s

If you disable garbage collection on the first test, indeed memory skyrockets. The resulting code looks like this:

func TestArrayShiftMem2(t *testing.T) {
	debug.SetGCPercent(-1)

	slice := [][1024]byte{}

	mem := runtime.MemStats{}
	mem2 := runtime.MemStats{}
	runtime.GC()
	runtime.ReadMemStats(&mem)
	// 1kb per

	for i := 0; i < 1024*1024*1024*1024; i++ {
		slice = append(slice, [1024]byte{})
		slice = slice[1:]
		// runtime.GC()

		if i%(1024) == 0 {
			fmt.Println("len, cap:", len(slice), cap(slice))
			runtime.ReadMemStats(&mem2)
			fmt.Println(mem2.HeapInuse - mem.HeapInuse)
			fmt.Println(mem2.StackInuse - mem.StackInuse)
			fmt.Println(mem2.HeapAlloc - mem.HeapAlloc)

		}
	}
}