either me or GC sux badly (GC don't reuse free memory)

[ketmar via Digitalmars-d]

On Wed, 12 Nov 2014 12:42:10 +0000
Matthias Bentrup via Digitalmars-d <digitalmars-d at puremagic.com> 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 <digitalmars-d at puremagic.com> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20141112/db8998ce/attachment.sig>