Note: this issue - assigning to a field of a compound map value - is a
proposal at https://github.com/golang/go/issues/3117
> Ian, can you clarify that for me, so the GC tracks interior pointers (to
a slice of structs) so that even if there are no references to the outer
slice it will not be GC
WellI ran some tests and that is indeed the case - but it looks like retains a
reference to the entire slice (which is expected).
Can you point to some documentation on how the GC tracks these interior
pointers?
> On Nov 9, 2019, at 11:03 AM, Robert Engels wrote:
>
> Ian, can you clarify that
Ian, can you clarify that for me, so the GC tracks interior pointers (to a
slice of structs) so that even if there are no references to the outer slice it
will not be GCd? That would seem to be very expensive.
> On Nov 9, 2019, at 9:36 AM, sirp...@gmail.com wrote:
>
>
> Thanks for these resp
No. Because in the absence on a memory barrier the writes may not be flushed
meaning you cannot reason about any value ever being changed. atomics provide
the memory barrier, but the mm still does not specify a “happens before”
relationship (but without this they are fairly useless).
> On Nov
On Fri, Nov 08, 2019 at 06:06:22AM -0600, Robert Engels wrote:
I think that is a bit unclear - even if they access different elements, if they
ever access the same element even at different times , you need
synchronization- it’s not only if the access the same element “concurrently”.
No, that
Thanks for these responses.
On Tuesday, 6 August 2013 22:06:38 UTC+1, Ian Lance Taylor wrote:
>
> On Tue, Aug 6, 2013 at 1:57 PM, Jakob Borg wrote:
> > 2013/8/6 Ian Lance Taylor :
> >> It is designed that way because we want to permit setting a new key in
> >> a map to grow the hash table if n
