This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Guile GC behaviour
- To: Greg Badros <gjb at cs dot washington dot edu>
- Subject: Re: Guile GC behaviour
- From: Mikael Djurfeldt <mdj at thalamus dot nada dot kth dot se>
- Date: 28 Sep 1999 01:35:31 +0200
- Cc: guile at sourceware dot cygnus dot com, scwm-discuss at scwm dot mit dot edu
- Cc: djurfeldt at nada dot kth dot se
- References: <qrrogeouffb.fsf@elwha.cs.washington.edu>
- Reply-to: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>
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?