-3

I have the following code

package main

import "fmt"

func main() {
    a := []int{1}
    b := &a[0]
    fmt.Println(a, &a[0], b, *b) // prints [1] 0xc00001c030 0xc00001c030 1

    a = append(a, 1, 2, 3)
    fmt.Println(a, &a[0], b, *b) // prints [1 1 2 3] 0xc000100020 0xc00001c030 1
}

First it creates a slice of 1 int. Its len is 1 and cap is also 1. Then I take a pointer to its first element and get the underlying pointer value in print. It works fine, as expected.

Than I add 3 more elements to the slice making go expand the capacity of the slice, thus copying it to another place in memory. After that I print the address (by taking a pointer) of the slice's first element which is now different from address stored in b.

However, when I then print the underlying value of b it also works fine. I don't understand why does it work. As far as I know the slice to which first element b points to was copied to another place in memory, so its previous memory must have been released. However, it seems to still be there.

If we look on maps, golang doesn't even allow us to create pointers on element by key because of the exact same problem - underlying data can be moved to another place in memory. However, it works perfectly fine with slices. Why is it so? How does it really works? Is the memory not being freed because there still is a variable which points to this memory? How is it different from maps?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Daniel Richter
  • 77
  • 6
  • 2
    "so its previous memory must have been released." No, that0s not how slices work. Slices are views into a backing array and the first backing array stays alive as you retained a copy to (an element of) it. Read the blog posts about slices and append. – Volker Dec 12 '22 at 11:01
  • 2
    «so its previous memory must have been released» this is the key misunderstanding. Go is a garbage-collected language, so there's no explicit means to "release" (free) memory in it: a memory block becomes eligible for GC when it has no references to it. In your example, the slice itself was a sole reference to its backing array, and you've added another one. Then the 1st one disappeared (the slice resulting due to the `append` call references a new chunk of memory) but the 2nd one (yours) was still alive, and so was the whole backing array referenced by it. – kostix Dec 12 '22 at 12:25
  • 2
    Go doesn't "move" things in memory, but it does "copy". You use both words in the same context, which is indicative of the source of confusion. "Move" and "copy" are not the same. – Hymns For Disco Dec 12 '22 at 12:36
  • 3
    The last bit of your question is answered [here](https://stackoverflow.com/a/32496031/720999) by @Volker. – kostix Dec 12 '22 at 12:53

2 Answers2

6

What happens to pointer to element when Go moves slice to another place in memory?

Nothing.

[W]hen I then print the underlying value of b it also works fine. I don't understand why does it work.

Why wouldn't it work?

The memory location originally pointed to is still there, unaltered. And as long as anything (such as b) still references it, it will remain usable. Once all references to that memory are removed (i.e. go out of scope), then the garbage collector may allow it to be used by something else.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
1

What happens to pointer to element when Go moves slice to another place in memory?

I believe the current GC implementation do not move such objects at all, although the specifications allow for this to happen. Unless you use the "unsafe" package, you are unlikely to encounter any problems even if it did move the underlying data structure.

Robert Ford
  • 11
  • 2