On Wed, 12 Nov 2014 12:42:10 +0000 Matthias Bentrup via Digitalmars-d <[email protected]> wrote:
> 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. i know it. what i can't get is why D allocates more and more address space with each 'new'. what i expecting is address space consumption on par with 'size', but it grows alot faster. seems that i should either read GC code to see what's going on (oh, boring!) or write memory region dumper (it's funnier). i bet that something is wrong with GC memory manager though, but can't prove it for now.
signature.asc
Description: PGP signature
