This is the mail archive of the mailing list for the Guile project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GC and continuations

Michael Livshin <> writes:

> Janis Dzerins <> writes:
> > On 17 Feb 2000, Ole Myren Rohne wrote:
> > 
> > >Janis Dzerins <> writes:
> > >
> > >> When I stopped the process (ctrl-c) and run GC like this: (gc) then
> > >> no memory was reclaimed (at least it was not abvious in the `top').
> > >
> > >Try (gc-stats). Garbage collection and malloc/free are not necessarily
> > >correlated.
> > 
> > But the fact stays the same --- when guile accumulates for example 40M, it
> > stays that big forever (I supose; that was my question).
> try it with any C program: malloc n big blocks; see what top tells
> you; then free them and see what top tells you again.  most probably
> (there may be exceptions, though I'm not aware of any) you'll see the
> same figure.
> Guile grabs memory with malloc, and free doesn't usually returns the
> memory to the OS.
> [ note that changing the Guile allocator to use mmap or brk could be a 
>   worthwhile project.  apart from the possibility to return the memory 
>   to the OS (which I personally think is not very important), you'd
>   also get much better control over alignment, etc. ]

Actually, there is an option in the last gc snapshot I made to allow
an mmapped heap (though in this case, it was an attempt to speed
pointer identification time, so it mmaps a pretty big hunk to insure
that it's just a single range check to identify a pointer into the
heap). Generally (at least if you're using glibc, I'm pretty sure that
the other common malloc's also have this behaviour), malloc's of the
size that guile uses for heap segments will be mmapped, anyway, so
changing the allocation won't help a bit (unless it's an allocator
that can insure a constant range of addresses for the allocation,
while not requiring a very large chunk of memory to start with, since
that can really kill performance).

Anyhow, the problem here is not that the malloc can't free the memory,
but that guile allocates far too much heap, and any living object in a
heap segment will cause it to be retained. I've explained why this
sucks (and provided patches) quite a few times, to no avail; the
latest one is at (it probably
doesn't work against the current cvs).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]