Is it safe to modify any part of a pointer?

[Joshua Liebow-Feeser]

Hi All,

I'm playing around with implementing a wait-free channel in the runtime package, and as part of this, it'd be really nice to have double-word compare-and-swap (CAS). Barring that, however, for my purposes, it would actually be fine to have a one-word value that encodes both a pointer and some extra information using bit packing. The problem, though, is that if I store this value as, for example, a uintptr, the GC may not realize that it's a pointer. So my question is: are there any bits in a pointer which, when modified, won't mess with the GC? Note that since this is implemented in the runtime, I'm totally OK with relying on behavior specific to the current GC implementation.

Thanks!

Cheers,

Josh

[adon...@google.com]

On Tuesday, 18 October 2016 15:30:36 UTC-4, Joshua Liebow-Feeser wrote:

are there any bits in a pointer which, when modified, won't mess with the GC?

Even if there are, using them would constrain the future choices of the GC team, for which they will not thank you.

This seems like a bad idea for many reasons.

[Joshua Liebow-Feeser]

This is very experimental, so I'm fine doing things that would never actually be accepted into the runtime. I just want an algorithm that works with the current gc.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/3cLrmBoF5B8/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Ian Lance Taylor]

See runtime/lfstack*.go.

Ian

[Joshua Liebow-Feeser]

Awesome, thanks! 

Ian

[Joshua Liebow-Feeser]

Actually, quick follow-up. I noticed that the lfstack implementation side-steps the GC issue by just not keeping pointers. That might work for me if I just store runtime.g pointers, but that raises another question: can the GC ever free g's, or are they just explicitly freed when a goroutine quits? That is, is it safe for me to store a pointer/counter hybrid like in lfstack - where that pointer is a *g - and assume that the GC won't collect the g from out from under me? 

Ian

[Ian Lance Taylor]

For the specific case of a g, this is safe at the moment. The current
Go runtime caches all g's and never releases them. See gfget and
gfput in runtime/proc.go.

Ian

[Joshua Liebow-Feeser]

OK great. And they won't ever be moved? (Come to think of it, is pointer rewriting only ever a thing on the stack?) 

Ian

[Ian Lance Taylor]

Yes, with the current toolchain, objects in the heap are never moved.

(Obviously no guarantees that this will always be true.)

Ian

[Joshua Liebow-Feeser]

Awesome, thanks. 

Ian