This is the mail archive of the guile@sourceware.cygnus.com 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


> > >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).

That is correct, try the same thing with emacs, once you have loaded in
a 40M file and then closed the buffer emacs is big until you shut it down
and start again (usually that won't be long because the bigger it is the
slower it runs, depending on local hardware capabilities).

> 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.

Well my C programs using glibc and linux do very much change size under
top as they malloc and free memory. One presumes that the reason Janis
was looking at the top output in the first place was because of previous
experiences with other programs.

> Guile grabs memory with malloc, and free doesn't usually returns the
> memory to the OS.

I'm pretty sure that guile never frees cell memory. I suspect that it
does free SMOB memory but possibly that depends on the SMOB.

As far as I know, the brk() call can move the limit of data space
up or down through memory so you can use it to grow or shrink.
However, since the libraries use it for malloc() you have to be very
sure of what you are doing before playing with it or you will corrupt
the malloc() lists (or just never use malloc, not exactly feasible
when linking to foreign code). Also brk() is not as portable as malloc().
Using sbrk() may be safe if you are careful to work with whatever
method the local libraries use. I suggest malloc and free are the best.

Linux is also smart about stack memory and only gives you as much as
you need so going into a deep recursion and then coming out of it
will cause you to grow then shrink.

Using mmap is OK but you can run out of maps and you cannot reliably
make a given map grow without having it also jump to a new base pointer,
thus you have to think very carefully about using mmap. Personally,
the more I work with pointers the more I dislike them (or at least I
believe that they should be used much more frugally than they are) but
guile is built from the ground up on pointers so don't expect that to change.

	- Tel

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