I think what is going on is this.
y := []*int{&x[0]}
compiles to:
var z [1]*int // allocate backing array
p = &z // take its address
p[0] = &x[0] // initialize it
y := z[:] // slice it
Because z has its address taken, we conservatively assume that z lives
throughout f. That keeps the object pointed to by z[0] alive.
Maybe we could do something about this? It would require reasoning about
the lifetime of a backing array given the lifetime of a slice.
On Thursday, December 22, 2016 at 10:23:40 AM UTC-8, dr...@pendo.io wrote:
>
> I finally took a look at the assembly, and unsurprisingly, a lot of
> pointers are being kept in registers. I'm not sure how registers interact
> with the GC, but I figured the memory might be free-able once function
> returns. Sure enough: https://play.golang.org/p/zpmVYSyKvX.
>
> Thanks for the help in digging into this, Ian! This was really bugging me.
>
> - Drew
>
> On Thursday, December 22, 2016 at 11:17:11 AM UTC-5, dr...@pendo.io wrote:
>>
>> Hi all,
>>
>> I was just toying around with pointers to slice elements, and I ended up
>> with this Go program: https://play.golang.org/p/D6e2SHEW1f. By the end
>> of the program, all references to memory in the main function are dropped,
>> but memory isn't freed after a call to runtime.GC(). This happens both in
>> the Go Playground and on my local machine (though the latter is running Go
>> 1.6).
>>
>> Is it just that runtime.GC() is not triggering a full GC and a later run
>> would clear the memory? Any insight here would be appreciated, as I'm
>> really curious now. Also, this isn't just a toy problem; it reflects some
>> actual code I'm working on.
>>
>> Thanks,
>> - Drew
>>
>
--
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.
