In article <87psn64tq5.fsf@laas.fr>,
Ludovic Courtès <ludovic.courtes@laas.fr> wrote:
>> This interleaving of initialization and sweeping makes it pretty hard to
>> track exactly where fresh cells come from.  I guess one solution might
>> be to maintain a list of the uninitialized segments and pick cells
>> directly from there before actually sweeping.

>* This poor man's generational GC has the advantage of being quite easy
>  to implement.  Basically, instead of having a single segment table as
>  we have now, we'd have to maintain a set of three segment tables,
>  which would not be too complicated it seems.
>
>  In particular, it's much easier to implement than the per-cell
>  generational GC, as proposed by Greg Harvey in
>  http://home.thezone.net/~gharvey/guile/ggc-notes.txt .  It's also less
>  intrusive: basically `scm_i_sweep_some_segments ()' is the only place
>  where generations would be taken into account.  Of course, the outcome
>  would certainly be better with a per-cell approach, but I'd expect the
>  per-segment approach to yield a non-null benefit for a pretty low
>  cost.

I don't get it. I thought the generational would save on the marking
phase. What's sweeping got to do with it?

>What do you think?  Are there flaws in this reasoning?  :-)

Yes; it's reasoning. In my experience, nice sounding theories and
approaches are usually meaningless. Programmers (including myself) are
notoriously bad at predicting performance characteristics. Why don't
you do some measurements before trying to design code?

I've tried "poor man's" optimizations before, and I always had to
conclude that optimizations introduced extra overhead, with a net loss
in performance.  that

If you want to have generational GC, I recommend to plug in Boehms GC
collector. MzScheme also does this with good results.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel