零长度和零上限的切片仍然可以指向基础数组并阻止垃圾回收吗？

Question

Let's take the following scenario:

a := make([]int, 10000)
a = a[len(a):]

As we know from "Go Slices: Usage and Internals" there's a "possible gotcha" in downslicing. For any slice a if you do a[start:end] it still points to the original memory, so if you don't copy, a small downslice could potentially keep a very large array in memory for a long time.

However, this case is chosen to result in a slice that should not only have zero length, but zero capacity. A similar question could be asked for the construct a = a[0:0:0].

Does the current implementation still maintain a pointer to the underlying memory, preventing it from being garbage collected, or does it recognize that a slice with no len or cap could not possibly reference anything, and thus garbage collect the original backing array during the next GC pause (assuming no other references exist)?

Edit: Playing with reflect and unsafe on the Playground reveals that the pointer is non-zero:

func main() {
    a := make([]int, 10000)
    a = a[len(a):]

    aHeader := *(*reflect.SliceHeader)((unsafe.Pointer(&a)))
    fmt.Println(aHeader.Data)

    a = make([]int, 0, 0)
    aHeader = *(*reflect.SliceHeader)((unsafe.Pointer(&a)))
    fmt.Println(aHeader.Data)
}

http://play.golang.org/p/L0tuzN4ULn

However, this doesn't necessarily answer the question because the second slice that NEVER had anything in it also has a non-zero pointer as the data field. Even so, the pointer could simply be uintptr(&a[len(a)-1]) + sizeof(int) which would be outside the block of backing memory and thus not trigger actual garbage collection, though this seems unlikely since that would prevent garbage collection of other things. The non-zero value could also conceivably just be Playground weirdness.

Answer 1

As seen in your example, re-slicing copies the slice header, including the data pointer to the new slice, so I put together a small test to try and force the runtime to reuse the memory if possible.

I'd like this to be more deterministic, but at least with go1.3 on x86_64, it shows that the memory used by the original array is eventually reused (it does not work in the playground in this form).

package main

import (
    "fmt"
    "unsafe"
)

func check(i uintptr) {
    fmt.Printf("Value at %d: %d
", i, *(*int64)(unsafe.Pointer(i)))
}

func garbage() string {
    s := ""
    for i := 0; i < 100000; i++ {
        s += "x"
    }
    return s
}

func main() {
    s := make([]int64, 100000)
    s[0] = 42

    p := uintptr(unsafe.Pointer(&s[0]))
    check(p)

    z := s[0:0:0]
    s = nil
    fmt.Println(z)
    garbage()
    check(p)
}