Re: guile/guile-core/libguile init.c

[Greg Harvey <Greg dot Harvey at thezone dot net>]

Jim Blandy <jimb@red-bean.com> writes:

> In his thesis, Ben Zorn recommends that one should not GC when the
> freelist is exhausted.  If you do this, then programs whose data size
> is close to the current heap size will GC very frequently, because the
> freelists will always be short.  And since these GC's will reclaim
> very little storage, the time they take is pretty much wasted.
>
> He suggests that the program should instead expand the heap whenever
> the freelist is exhausted, and GC after every N allocations, where N
> is a parameter.  This way, the heap size naturally adjusts to match
> the program's data size, and the GC frequency is more controlled.
> 

If this were the case (for the first bit), guile would allocate a new
segment (IIRC the threshold that used to be in before the change was
1/4 heap size, which is probably too small (scwm seems to like 1/2
better), but offsets the fact that guile allocates way too much memory
for consecutive segments); removing that and replacing it with some
fixed number of cells and heap allocation when the freelist is
exhausted, with everything else remaining the same, just causes more
collections; once the heap starts filling up, this means scanning an
awful lot just to potentially reclaim N objects (unless lots of stuff
dies, but then both will still get back the same amount). You'd get
better benefit from allowing the user to specify what portion of the
current heap size should be available after a collection, allocating
when it becomes overful.

If guile was using an aged based collector where it could compact live
objects, then this would have much more going for it, since there's no
need for any kind of special area for young objects, just below the
place where we started from; but that currently isn't the case.

-- 
Gregh