On Friday, March 3, 2017 at 9:05:50 AM UTC+2, Yota Toyama wrote:
>
> Nathan,
>
> As I posted above right after you posted, you are right.
> "Memory leak" was gone when I inserted sleep at the loop end.
> Thank you for your advice!
>
> Yota
>
> On Friday, March 3, 2017 at 10:39:02 AM UTC+9, Nathan Fisher wrote:
>>
>> Hi Yota,
>>
>> I don't disagree there's value in understanding how Go handles the
>> scenario. What I'm not certain of is the potential tradeoffs when
>> optimising for an uncommon edge case.
>>
>> The loop you've created is very tight and would be unusual to find in a
>> typical application. The allocator is moving faster than GC could ever hope
>> to keep up. Given it's an endless loop without any work I think there would
>> be a tradeoff of performance to guard against something that will only
>> exist in micro-benchmarks and/or invalid code.
>>
>> I would expect that if you introduce some "work" the memory leak would go
>> away.
>>
>> Kind regards,
>> Nathan
>>
>> On Fri, 3 Mar 2017 at 01:10 Yota Toyama <rav...@gmail.com> wrote:
>>
>>> Volker,
>>>
>>> I don't know if the term "memory leak" is misuse.
>>> But, the 1st version's memory usage is constant but the 2nd version's
>>> one grows over time as if nothing is garbage-collected.
>>>
>>>
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> - from my thumbs to your eyes
>>
>
instead of time.Sleep(), use runtime. Gosched().
Djadala
--
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.
