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.
