• mzfhhhh (16/16) Feb 06 2015 import std.stdio;
• Safety0ff (1/1) Feb 06 2015 False pointers, current GC is not precise.
• ketmar (6/7) Feb 06 2015 not only that. constantly allocating big chunks of memory will inevitabl...
• mzfhhhh (9/20) Feb 08 2015 hi,i still have two questions:
• FG (5/22) Feb 08 2015 You wrote yourself, that you used "win7 x86,dmd v2.066.0", that is x86 a...
• safety0ff (3/8) Feb 08 2015 That won't work, see:
• FG (13/22) Feb 08 2015 Perhaps it was fixed in DMD 2.066.1, because this works for me just fine...
• safety0ff (3/8) Feb 08 2015 Here's the link I couldn't find earlier:

"mzfhhhh" <mzfhhhh foxmail.com> writes:

import std.stdio;

void testGC()
{
     auto b = new byte[](1024*1024*100);
     writeln("malloc 100M!");
}

void main()
{
     foreach(i;1..100)
     {
         testGC();
     }
}
--------------------------------------
core.exception.OutOfMemoryError (0)

win7 x86,dmd v2.066.0

"Safety0ff" <safety0ff.dev gmail.com> writes:

False pointers, current GC is not precise.

ketmar <ketmar ketmar.no-ip.org> writes:

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=20
lead to OOM due to current GC design. you can check it with manual=20
freeing. there were some topics about it, and the solution is either use=20
64 bit OS ('cause the memory is here, but there is no address space to=20
allocate it), or use `malloc()` and `free()` from libc.=

"mzfhhhh" <mzfhhhh foxmail.com> writes:

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

2. "auto buf = new byte[](1024*1024*100);"
       now the gc can't free this buf.
       can i free it by manual?

FG <home fgda.pl> writes:

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

"safety0ff" <safety0ff.dev gmail.com> writes:

On Sunday, 8 February 2015 at 16:23:44 UTC, FG wrote:
 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

That won't work, see:
http://forum.dlang.org/thread/uankmwjejsitmlmrbufe forum.dlang.org

FG <home fgda.pl> writes:

On 2015-02-08 at 19:15, safety0ff wrote:
 On Sunday, 8 February 2015 at 16:23:44 UTC, FG wrote:
 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

 That won't work, see:
 http://forum.dlang.org/thread/uankmwjejsitmlmrbufe forum.dlang.org


Perhaps it was fixed in DMD 2.066.1, because this works for me just fine:

     import core.memory;

     void testGC()
     {
         auto b = new byte[](1024 * 1024 * 100);
         GC.free(b.ptr);
     }

     void main()
     {
         foreach (i; 1..100)
             testGC();
     }

"safety0ff" <safety0ff.dev gmail.com> writes:

On Sunday, 8 February 2015 at 18:43:18 UTC, FG wrote:
 On 2015-02-08 at 19:15, safety0ff wrote:
 That won't work, see:
 http://forum.dlang.org/thread/uankmwjejsitmlmrbufe forum.dlang.org

 Perhaps it was fixed in DMD 2.066.1, because this works for me 
 just fine:

Here's the link I couldn't find earlier:
https://issues.dlang.org/show_bug.cgi?id=14134