Will a unsafe pointer confuse the garbage collector?

[Peter RK]

If I use a pointer with wrong type to locate a real object in memory, can the garbage collector recognize that object correctly via such pointer? Or it will just ignore unsafe pointer?

[Axel Wagner]

I think an unsafe.Pointer is not a problem, but storing that pointer in
a uintptr is unsafe.

[Tamás Gulácsi]

It will treat it as a pointer, and keep its referencee alice. An uintptr does not, so use unsafe.Pointer, if needed.

[Peter RK]

If target object contains some pointers, will them be found for constructing a complete reference chain? How do the garbage collector figure out the real type of such object referred by an unsafe pointer?

[Roberto Zanotto]

Yes, everything will work ok, the garbage collector does not need to inspect the type of the object. There is a bitmask updated at object allocation time that indicates which words in memory are pointers and which are not, so pointers inside structs will be recognized.

[thwd]

I'm interested.

 * Where is this bit pattern located in relation to the pointer itself and the referenced memory area?

 * If uintptr is invisible to the GC, am I correct in assuming that it is used for manual memory management where needed?

 * Does the write barrier also apply to unsafe.Pointers?

Thank you for your time.

- Tom

[thwd]

On Monday, September 14, 2015 at 11:33:06 PM UTC+2, thwd wrote:

 * If uintptr is invisible to the GC, am I correct in assuming that it is used for manual memory management where needed?

On second thought, considering the tri-color approach I assume an object pointed to by a sole uintptr will remain white in the next GC cycle. So it would be collected.

If that's correct, what is uintptr good for? 

[Ian Lance Taylor]

On Mon, Sep 14, 2015 at 2:33 PM, thwd <sedevel...@gmail.com> wrote:
>
> I'm interested.
>
> * Where is this bit pattern located in relation to the pointer itself and
> the referenced memory area?

See runtime/mbitmap.go.

> * If uintptr is invisible to the GC, am I correct in assuming that it is
> used for manual memory management where needed?

I don't think I would put it that way. The GC also ignores pointers
that are not into GC memory, and most manual memory management is done
with that memory, so it uses pointers too. The GC and memory
allocation code does convert to uintptr in order to do pointer
arithmetic.

> * Does the write barrier also apply to unsafe.Pointers?

Yes.

Ian

[Roberto Zanotto]

Sorry but I don't have the knowledge to answer your questions, the little information I had was from casually reading a thread on golang-dev. Looks like Ian came to the rescue :)
Cheers

On Monday, September 14, 2015 at 11:33:06 PM UTC+2, thwd wrote: