>> Can I ask how recent your Julia is. I see this with Julia 0.4 and Julia 0.5
>
> 0.5.0-dev+3106
> I could try 0.4 later.

Yes, that's it.  I can see Bill's memory behavior on 0.4.3 (starts at
130MB, goes to ~1.4GB when running doit2) but not on yesterday's 0.5
(starts at 150MB, when running doit2 it stays at 180MB).

>> with 100 day old master (I can't update to something more recent as someone
>> removed a documented feature of Julia and the issue was marked WontFix
>> https://github.com/JuliaLang/julia/issues/14919 , so I can't current try a
>> later Julia).
>>
>>>
>>> Yes, it is, and that's why we don't have a depward for it. The
>>> performance of Ref can be brought on pair with & with some compilar
>>> optimizations (search for stack allocation on the issue tracker) and I
>>> don't think we'll fully deprecate & before that.
>>>
>>
>> I see. That is a relief. We'll stick with & for now.
>>
>>> more than 2 collection*
>>
>>
>> I see, so collections can happen at any time, not when some block of memory
>> is "full".
>
> Yes, it happens whenever the GC thinks there are enough allocation
> since the last time.
>
>>
>>>
>>> > generations 1 and 2 if they are not copied?
>>>
>>> See the lifetime diagram in gc.c, they are marked differently.
>>>
>>> >
>>> > Or do you mean it has 2 generations plus a long term generation?
>>>
>>> See also
>>> https://github.com/yuyichao/explore/blob/master/julia/new_gc/bit_swap.md
>>> if you are interested.
>>
>>
>> Thanks.
>>
>>
>> Ah ok. It sounds like you have a more recent gc than me, and possibly this
>> also explains why you don't observe the behaviour I see.
>>
>> I actually reported the behaviour on the day the generational gc behaviour
>> was switched on. Nobody replied at the time, which made me wonder if anyone
>> had noticed. The behaviour has been the same for us from that time until 100
>> days ago when we stopped updating Julia.
>>
>> Bll.

Reply via email to