Re: generational GC

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Maciej Stachowiak <mjs@eazel.com> writes:

> I guess the logical conclusion is either provide generational GC only,
> or non-generational GC only. This decisions would preferrably be based
> on looking at some real-life performance numbers.

Yes.

I guess that what we really are trying to address here is the fact
that already a "plain" newly booted Guile consumes about half of its
execution time in GC.  With more cells allocated for code and data,
this fraction grows.

We want to take away the "unnecessary" work done by the GC on code and
on semi-permanent data.

I see two ways of addressing this problem:

1. Introduce a new "slow" heap-type (freelist) which holds source
   conses.

   It is possible to arrange it so that source code only points to
   other source code pairs.  Either the reader could be put in a mode
   where it allocates source-pairs, and/or the memoization process
   could rewrite code into source-pairs.

   Normally GC only involves "fast" heaps.  The "slow" heap would only
   GC (together with the "fast" ones) when it runs out of cells.

   I'm pretty confident that the new GC scheme can handle yet another
   heap type without overhead.  Actually, the entire idea is pretty
   simple to implement.

   This solution removes unnecessary GC of code.

2. Introduce generational GC.

   This introduces overhead at the write barrier, but has the
   advantage over 1 in that it remoces unnecessary GC of
   semi-permanent code.

I expect that the overhead in solution 2 will be shadowed by the
wins.  It is a more general solution which solves a more fundamental
problem than 1.  If we use 1, we still might want to introduce even
more complexity later in order to solve more of the problem.  In
contrast, th complexity introduced in 2 solves several problems at
once.

Still, we could look upon 1 as a backup.

BTW, I hope that Michael introduces the changes in a way that we
easily can compare before/after, e.g. by using "cvs tag" with pre- and
post-tags.