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

False pointers, current GC is not precise.

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.

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?

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

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

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();
    }

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