On Wednesday, 12 November 2014 at 12:30:15 UTC, ketmar via
Digitalmars-d wrote:
On Wed, 12 Nov 2014 12:05:25 +0000
thedeemon via Digitalmars-d <[email protected]> wrote:
On Wednesday, 12 November 2014 at 11:05:11 UTC, ketmar via
Digitalmars-d wrote:
> 734003200
> address space" (yes, i'm on 32-bit system, GNU/Linux).
>
> the question is: am i doing something wrong here? how can i
> force GC to stop eating my address space and reuse what it
> already has?
Sure: just make the GC precise, not conservative. ;)
With current GC implementation and array this big chances of
having a word on the stack that looks like a pointer to it and
prevents it from being collected are almost 100%. Just don't
store big arrays in GC heap or switch to 64 bits where the
problem is not that bad since address space is much larger and
chances of false pointers are much smaller.
but 'mkay, let's change the sample a little:
import core.memory;
import std.stdio;
void main () {
uint size = 1024*1024*300;
for (;;) {
auto buf = new ubyte[](size);
writefln("%s", size);
size += 1024*1024*100;
GC.free(GC.addrOf(buf.ptr));
buf = null;
GC.collect();
GC.minimize();
}
}
this shouldn't fail so soon, right? i'm freeing the memory,
so... it
still dying on 1,887,436,800. 1.7GB and that's all? this can't
be true,
i have 3GB of free RAM (with 1.2GB used) and 8GB of unused
swap. and
yes, it consumed all of the process address space again.
On Linux/x86 you have only 3 GB virtual address space, and this
has to include the program code + all loaded libraries too. Check
out /proc/<pid>/maps, to see where the dlls are loaded, and look
at the largest chunk of free space available. That is the
theoretical limit that could be allocated.
