0

Is there a difference how pointers work in Go and C++, will pointers change after gc?

I want to know the specific relationship between pointers and memory in Go. If you have relevant information or source code explanations, thank you very much.

icza
  • 389,944
  • 63
  • 907
  • 827
jimmy
  • 21
  • 1
  • 1
    I can explain this one. "[T]he specific relationship between pointers and memory in [Go]" is. A pointer is a memory address. – Volker May 20 '19 at 11:16
  • 1
    Ah, sorry, I forgot to answer the question in the headline: No. – Volker May 20 '19 at 11:17
  • Maybe @jimmy was looking smth like [this](https://stackoverflow.com/questions/57483/what-are-the-differences-between-a-pointer-variable-and-a-reference-variable-in)? :) – Sergey Narozhny May 20 '19 at 20:06
  • Of interest? [pointers](https://go101.org/article/pointer.html) and [unsafe](https://go101.org/article/unsafe.html). – Mark May 20 '19 at 21:54
  • In c++ pointers always point to a memory address, but in golang, GC may reorganize memory. Will the pointer change after this happens? – jimmy May 21 '19 at 02:33
  • @jimmy: Which part of "No" was not clear enough. No. – Volker May 21 '19 at 05:38

1 Answers1

0

The language specification does not say anything whether pointers should stay invariant. Which means you should not rely / build on this.

What you have guarantee of is that if pointers change after a garbage collection cycle, or if the runtime changes them due to memory allocation / release, the pointers you have in your variables will be updated to reflect the changes.

There is a hint in the documentation of unsafe.Pointer that pointers may change:

A uintptr is an integer, not a reference. Converting a Pointer to a uintptr creates an integer value with no pointer semantics. Even if a uintptr holds the address of some object, the garbage collector will not update that uintptr's value if the object moves, nor will that uintptr keep the object from being reclaimed.

In practice the garbage collector won't go around and change pointers all the time, that would be an unnecessary overhead. But it may reorder objects in memory if a lot of them is freed and compacts the memory, or there's a "pressure" to free unused memory (e.g. due to a call to debug.FreeOSMemory()).

icza
  • 389,944
  • 63
  • 907
  • 827