Re: [go-nuts] Map of structs vs Array of structs

[keith . randall]

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 GCd? That would seem to be very expensive. 

Yes, the Go GC does that.  It's not super expensive, but it does have more 
overhead than other GCs, mostly because object headers don't work.
The additional task is just to round the pointer down to the beginning of 
the object. We keep some data structures per page (8KB) that make that 
computation quick.

> WellI ran some tests and that is indeed the case - but it looks like 
retains a reference to the entire slice (which is expected).

Right.

> Can you point to some documentation on how the GC tracks these interior 
pointers?

See src/runtime/mbitmap.go:findObject

On Saturday, November 9, 2019 at 9:50:41 AM UTC-8, robert engels wrote:
>
> 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 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, sir...@gmail.com  wrote:
>
> 
> 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 necessary, moving the map around in 
>> >> memory.  That means that the language can not permit taking the 
>> >> address of an entry in a map--if it could, it would not be possible to 
>> >> move a map in memory. 
>> > 
>> > How come append to a slice doesn't ever need to move the contents in 
>> > order to grow the slice? 
>>
>> When append needs to move the contents, it gives you a slice that 
>> refers to a new backing store.  The old backing store still exists and 
>> pointers to it are still valid.  And a program could even reasonable 
>> use it. 
>>
>> This does mean that whether a function like this prints 2 or 100 
>> depends on the details of the implementation of append. 
>>
>> func main() { 
>> a := append([]int{}, 1, 2, 3) 
>> a = append(a, 4) 
>> p := [1] 
>> a = append(a, 5, 6, 7) 
>> a[1] = 100 
>> fmt.Println(*p) 
>> } 
>>
>> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a6acb447-ac6d-47e5-a2e8-eaa49e1b732a%40googlegroups.com
>  
> 
> .
>
>
> -- 
> 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 golan...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/C5210B7D-0139-42BC-A7AE-9D33E54EC539%40ix.netcom.com
>  
> 
> .
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/df4a40e3-6d99-4611-a65d-fd1efcba472c%40googlegroups.com.

Re: [go-nuts] Map of structs vs Array of structs

[robert engels]

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 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 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 mailto:i...@golang.org>>: 
>> >> It is designed that way because we want to permit setting a new key in 
>> >> a map to grow the hash table if necessary, moving the map around in 
>> >> memory.  That means that the language can not permit taking the 
>> >> address of an entry in a map--if it could, it would not be possible to 
>> >> move a map in memory. 
>> > 
>> > How come append to a slice doesn't ever need to move the contents in 
>> > order to grow the slice? 
>> 
>> When append needs to move the contents, it gives you a slice that 
>> refers to a new backing store.  The old backing store still exists and 
>> pointers to it are still valid.  And a program could even reasonable 
>> use it. 
>> 
>> This does mean that whether a function like this prints 2 or 100 
>> depends on the details of the implementation of append. 
>> 
>> func main() { 
>> a := append([]int{}, 1, 2, 3) 
>> a = append(a, 4) 
>> p := [1] 
>> a = append(a, 5, 6, 7) 
>> a[1] = 100 
>> fmt.Println(*p) 
>> } 
>> 
>> 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 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/a6acb447-ac6d-47e5-a2e8-eaa49e1b732a%40googlegroups.com
>>  
>> .
> 
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/C5210B7D-0139-42BC-A7AE-9D33E54EC539%40ix.netcom.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/C17799E2-73A0-4E64-AA1B-94A46B87A00E%40ix.netcom.com.

Re: [go-nuts] Map of structs vs Array of structs

[Robert Engels]

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 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 necessary, moving the map around in 
>> >> memory.  That means that the language can not permit taking the 
>> >> address of an entry in a map--if it could, it would not be possible to 
>> >> move a map in memory. 
>> > 
>> > How come append to a slice doesn't ever need to move the contents in 
>> > order to grow the slice? 
>> 
>> When append needs to move the contents, it gives you a slice that 
>> refers to a new backing store.  The old backing store still exists and 
>> pointers to it are still valid.  And a program could even reasonable 
>> use it. 
>> 
>> This does mean that whether a function like this prints 2 or 100 
>> depends on the details of the implementation of append. 
>> 
>> func main() { 
>> a := append([]int{}, 1, 2, 3) 
>> a = append(a, 4) 
>> p := [1] 
>> a = append(a, 5, 6, 7) 
>> a[1] = 100 
>> fmt.Println(*p) 
>> } 
>> 
>> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a6acb447-ac6d-47e5-a2e8-eaa49e1b732a%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/C5210B7D-0139-42BC-A7AE-9D33E54EC539%40ix.netcom.com.

Re: [go-nuts] Map of structs vs Array of structs

[sirpros]

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 necessary, moving the map around in 
> >> memory.  That means that the language can not permit taking the 
> >> address of an entry in a map--if it could, it would not be possible to 
> >> move a map in memory. 
> > 
> > How come append to a slice doesn't ever need to move the contents in 
> > order to grow the slice? 
>
> When append needs to move the contents, it gives you a slice that 
> refers to a new backing store.  The old backing store still exists and 
> pointers to it are still valid.  And a program could even reasonable 
> use it. 
>
> This does mean that whether a function like this prints 2 or 100 
> depends on the details of the implementation of append. 
>
> func main() { 
> a := append([]int{}, 1, 2, 3) 
> a = append(a, 4) 
> p := [1] 
> a = append(a, 5, 6, 7) 
> a[1] = 100 
> fmt.Println(*p) 
> } 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a6acb447-ac6d-47e5-a2e8-eaa49e1b732a%40googlegroups.com.