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