Actually, the above version makes it even worse, as uncommenting the y[0] = nil line no longer causes memory to be freed. It really does look like compiler optimizations are making this hard to reason about.
On Thursday, December 22, 2016 at 1:08:13 PM UTC-5, dr...@pendo.io wrote: > > You may be on to something about compiler optimizations, but unfortunately > it doesn't seem that simple: https://play.golang.org/p/Qa-i5eiRZ_. It > looks like using _ was confusing matters, so I switched to using a Println > to force actual use of those variables. The issue still occurs with global > variables. > > On Thursday, December 22, 2016 at 12:38:49 PM UTC-5, Ian Lance Taylor > wrote: >> >> On Thu, Dec 22, 2016 at 9:16 AM, <dr...@pendo.io> wrote: >> > It should be clear from the source code, but I'm using two calls to >> > runtime.GC() followed by runtime.ReadMemStats(). >> >> Oh, I see, sorry. My guess is that you are effectively testing the >> compiler's statement ordering. The compiler knows that calling Alloc >> does not use or affect x or y, so there is no necessary relationship >> between setting x and y and calling Alloc. If I change x and y to be >> global variables then I do see Alloc drop. >> https://play.golang.org/p/NQu_bQxxLY . >> >> Ian >> >> > On Thursday, December 22, 2016 at 12:06:13 PM UTC-5, Ian Lance Taylor >> wrote: >> >> >> >> On Thu, Dec 22, 2016 at 8:16 AM, <dr...@pendo.io> wrote: >> >> > >> >> > 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. >> >> >> >> How are you determining that "memory isn't freed"? There are several >> >> possible meanings for that. >> >> >> >> 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...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> > -- 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.
