This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Guile GC behaviour
Mikael Djurfeldt <mdj@thalamus.nada.kth.se> writes:
> Greg Badros <gjb@cs.washington.edu> writes:
>
> > I'd really appreciate some Guile guru's help on this. I am trying to
> > investigate Scwm's memory leaks a bit more, and I'm confused about the
> > behaviour I'm seeing in Scwm when I evaluate this s-exp:
> >
> > (let ((i 0))
> > (while (< i 100000)
> > (gc-stats)
> > (set! i (+ i 1))))
> >
> >
> > This causes Scwm's process image size to grow dramatically (this is
> > against guile-1.3.4). We evaluate the string in a fairly contorted way.
>
> The explanation for the behaviour is this: During certain operations,
> like (gc-stats), GC is blocked (C-level: scm_block_gc == 1). If the
> interpreter runs out of memory when GC is blocked, this is "solved" by
> allocating a new heap segment.
>
> In your code snippet, the (gc-stats) call will be the main source of
> consing. Thus, GC will most commonly happen within `gc-stats', always
> leading to allocation of a new heap segment, even though the entire
> heaps are filled with garbage that could be used if GC was allowed.
>
> Does anybody have a suggestion how to solve this?
Does the guile gc release heap segments later on? I have seen Scwm get
smaller sometimes, too, but it never seems to shrink back to what it
should be.
Thanks,
Greg