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

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