why GC not work?

FG via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun Feb 8 08:23:22 PST 2015


On 2015-02-08 at 15:56, mzfhhhh wrote:
> On Saturday, 7 February 2015 at 06:08:39 UTC, ketmar wrote:
>> On Sat, 07 Feb 2015 04:30:07 +0000, Safety0ff wrote:
>>
>>> False pointers, current GC is not precise.
>>
>> not only that. constantly allocating big chunks of memory will inevitably
>> lead to OOM due to current GC design. you can check it with manual
>> freeing. there were some topics about it, and the solution is either use
>> 64 bit OS ('cause the memory is here, but there is no address space to
>> allocate it), or use `malloc()` and `free()` from libc.
>
> hi,i still have two questions:
>
> 1. how large is the "big chunks"  ? 10MB? 50MB? ...
>        where are topics about this?
>        if I don't know the exact size, it is very likely a memory leak

You wrote yourself, that you used "win7 x86,dmd v2.066.0", that is x86 and not x86-64.
In 32-bits even with blocks as small as 1 MB there is a chance that the garbage collector will think some data on stack is a pointer to that block because when cast to void* it could point right into that allocated block of memory.
  
> 2. "auto buf = new byte[](1024*1024*100);"
>        now the gc can't free this buf.
>        can i free it by manual?

Yes. import core.memory; GC.free(buf.ptr); // and don't use buf afterwards


More information about the Digitalmars-d-learn mailing list