April 08, 2016
On Thursday, 7 April 2016 at 16:13:59 UTC, Steven Schveighoffer wrote:
> On 4/6/16 3:54 PM, Jonathan Villa wrote:
>
> You are likely running into the GC being conservative. You are also possibly running into an issue where you are expecting the compiler to do something with the stack where it may do something else. A classic question that is asked on D forums all the time is why when you null some variable and then call GC collect, the memory isn't collected. The answer is because quite possibly the value is still in a register, and the registers must be scanned too.
>
> As for conservatism, if you generate a 1-million element array of pointers (each element has a pointer in it), then you have some random stack variable that "happens" to point into that giant array (more likely in 32-bit systems), then both the array, and all it's pointing at gets saved.
> 
> -Steve

Good, I compiled the program in 64 bit mode (-m64) and now it release memory normally like in Debian.

I would like to know where can I learn more about the 'register' or the GC for the D so I can avoid future issues.

JV.


April 08, 2016
On 4/8/16 11:08 AM, Jonathan Villa wrote:
> On Thursday, 7 April 2016 at 16:13:59 UTC, Steven Schveighoffer wrote:
>> On 4/6/16 3:54 PM, Jonathan Villa wrote:
>>
>> You are likely running into the GC being conservative. You are also
>> possibly running into an issue where you are expecting the compiler to
>> do something with the stack where it may do something else. A classic
>> question that is asked on D forums all the time is why when you null
>> some variable and then call GC collect, the memory isn't collected.
>> The answer is because quite possibly the value is still in a register,
>> and the registers must be scanned too.
>>
>> As for conservatism, if you generate a 1-million element array of
>> pointers (each element has a pointer in it), then you have some random
>> stack variable that "happens" to point into that giant array (more
>> likely in 32-bit systems), then both the array, and all it's pointing
>> at gets saved.
>>
>
> Good, I compiled the program in 64 bit mode (-m64) and now it release
> memory normally like in Debian.

Definitely, 64-bit is less likely to randomly point at memory. This isn't 100% sure-fire way to fix the problem though.

>
> I would like to know where can I learn more about the 'register' or the
> GC for the D so I can avoid future issues.

Your best bet is to free the memory itself if it's possible.

import core.memory: GC;
GC.free(combs.ptr);

For more info on how GC works: dlang.org/spec/garbage.html

-Steve
April 08, 2016
On Friday, 8 April 2016 at 15:21:50 UTC, Steven Schveighoffer wrote:
> On 4/8/16 11:08 AM, Jonathan Villa wrote:
>> On Thursday, 7 April 2016 at 16:13:59 UTC, Steven Schveighoffer wrote:
> Your best bet is to free the memory itself if it's possible.
>
> import core.memory: GC;
> GC.free(combs.ptr);
>
> For more info on how GC works: dlang.org/spec/garbage.html
>
> -Steve

Thank you very much! I think this is the answer I was looking for C:

JV
1 2
Next ›   Last »