On Tue, Oct 18, 2016 at 4:19 PM, Ian Lance Taylor <i...@golang.org> wrote:

> On Tue, Oct 18, 2016 at 3:13 PM, Joshua Liebow-Feeser <he...@joshlf.com>
> wrote:
> >
> > On Tue, Oct 18, 2016 at 2:53 PM, Ian Lance Taylor <i...@golang.org>
> wrote:
> >>
> >> On Tue, Oct 18, 2016 at 2:45 PM, Joshua Liebow-Feeser <he...@joshlf.com
> >
> >> wrote:
> >> >
> >> > On Tue, Oct 18, 2016 at 2:40 PM, Joshua Liebow-Feeser <
> he...@joshlf.com>
> >> > wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Oct 18, 2016 at 2:16 PM, Ian Lance Taylor <i...@golang.org>
> >> >> wrote:
> >> >>>
> >> >>> On Tue, Oct 18, 2016 at 12:30 PM, Joshua Liebow-Feeser
> >> >>> <he...@joshlf.com>
> >> >>> wrote:
> >> >>> >
> >> >>> > 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.
> >> >>>
> >> >>> See runtime/lfstack*.go.
> >> >>
> >> >> Awesome, thanks!
> >> >
> >> >
> >> > 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?
> >>
> >> 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.
> >
> >
> > OK great. And they won't ever be moved? (Come to think of it, is pointer
> > rewriting only ever a thing on the stack?)
>
> Yes, with the current toolchain, objects in the heap are never moved.
>
> (Obviously no guarantees that this will always be true.)
>

Awesome, thanks.

>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to