2 ms·

I don't know much about the Go compiler internals, but it sounds like in most cases (possibly all) the object being referenced in that way will be heap allocate

I don't know much about the Go compiler internals, but it sounds like in most cases (possibly all) the object being referenced in that way will be heap allocated; the entire point of this article is that no matter what (across function boundaries, the reference itself put into the heap, whatever) the member `y` of `X` will be inline with its stack representation. https://golang.org/doc/faq#stack_or_heap https://golang.org/doc/faq#stack_or_heap

topspin 10y ago
Go does escape analysis like most (all?) good GC implementations to detect optimization opportunities. You can allocate an array of objects, for instance, and Go will try to make a contiguous, dense allocation for all the members, enabling extremely efficient pointer arithmetic to resolve member offsets thus avoiding an indirection, and precluding the GC bookkeeping for individual elements, and perhaps improving processor cache utilization. But the key point stands wrt Go; Go is among the languages that "can't do this." First, there is no way to get a reference to a field inside a struct in Go (the workaround is reflection which has runtime overhead, and therefore doesn't count) and if you could get such a reference the compiler would be forced to reference count the member via the GC to satisfy the Go memory model.
- EdiX 10y ago
  > First, there is no way to get a reference to a field inside a struct in Go what? https://play.golang.org/p/1OJ5U5ZwFJ https://play.golang.org/p/1OJ5U5ZwFJ > if you could get such a reference the compiler would be forced to reference count the member via the GC to satisfy the Go memory model no reference counting in go.
  - saghm 10y ago
    I'm not that familiar with Go, but my guess is that "reference count" here refers to the action that the garbage collector does when it pauses the world (i.e. "count as a reference") rather than the actual paradigm "reference counting".

topspin 10y ago

Go does escape analysis like most (all?) good GC implementations to detect optimization opportunities. You can allocate an array of objects, for instance, and Go will try to make a contiguous, dense allocation for all the members, enabling extremely efficient pointer arithmetic to resolve member offsets thus avoiding an indirection, and precluding the GC bookkeeping for individual elements, and perhaps improving processor cache utilization. But the key point stands wrt Go; Go is among the languages that "can't do this." First, there is no way to get a reference to a field inside a struct in Go (the workaround is reflection which has runtime overhead, and therefore doesn't count) and if you could get such a reference the compiler would be forced to reference count the member via the GC to satisfy the Go memory model.

EdiX 10y ago
> First, there is no way to get a reference to a field inside a struct in Go what? https://play.golang.org/p/1OJ5U5ZwFJ https://play.golang.org/p/1OJ5U5ZwFJ > if you could get such a reference the compiler would be forced to reference count the member via the GC to satisfy the Go memory model no reference counting in go.
- saghm 10y ago
  I'm not that familiar with Go, but my guess is that "reference count" here refers to the action that the garbage collector does when it pauses the world (i.e. "count as a reference") rather than the actual paradigm "reference counting".