Volker,
Sorry for double posts.
Following your idea, I could fix my code of the 2nd version.
When I insert time.Sleep(SomeTime) at for loop end, everything seems to be
fine.
The threshold of SomeTime is between 100 and 1000.
When it is set to 100, the memory usage grows over time but, when 1000, it
looks constant.
l := NewList(42, nil)
for {
l = l.Rest() // Cause memory leak?
time.Sleep(SomeTime)
}
I expected Go's GC collects all garbages at every sweep phase.
Or, doesn't it?
Yota
On Friday, March 3, 2017 at 2:38:08 AM UTC+9, Volker Dobler wrote:
>
> Am Donnerstag, 2. März 2017 17:15:05 UTC+1 schrieb Yota Toyama:
>>
>> Hi, all.
>>
>> I'm trying to understand argument liveness in Go 1.8.
>> As preparation for it, I wrote 2 programs which iterate over infinite
>> lists.
>> At first, I thought both can be run forever without any memory leak.
>> However, the result was that one could and the other couldn't.
>>
>> Their main difference is the way to iterate lists.
>>
>> l := *NewList(42, nil)
>>
>> for {
>> l = *l.Rest() // Cause no memory leak :)
>> }
>>
>> vs
>>
>> l := NewList(42, nil)
>>
>> for {
>> l = l.Rest() // Cause memory leak!!!
>> }
>>
>> The repository is here <https://github.com/raviqqe/argument-liveness.go>.
>> I wanna understand why the latter causes memory leak and what is going on
>> in my programs at low level.
>> Any ideas?
>>
>
>
> What makes you say that one version causes a memory leak?
>
> The first version produces much less garbage (well, basically none):
> l is a ListValue and the freshly created "list rest" is assigned to it,
> basically just overwriting the memory location of l with the same
> value.
>
> The second version produces an endless linked list where only the
> last list element is reachable from your code as this is the only value
> you have a pointer to.
>
> So the second produces tremendous amounts of garbage but this
> garbage is collectable. Running it shows no problem when tracing GC
> at least not with Go 1.8.
>
> So the main difference is: The first code does not produce an "endless
> list" it just operates on one List value while the second code really
> constructs an ever increasing linked list if List values where only the
> tail is reachable/uncollectable.
>
> How did you determine the second version "leaks"?
>
> V
>
--
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.
