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
