Re: Considering Guile as part of a Master's Thesis

["Paul R. Wilson" <wilson@cs.utexas.edu>]

>From owner-guile@cygnus.com Fri Dec 19 07:35:06 1997
>To: Mikael Djurfeldt <mdj@nada.kth.se>
>Cc: peyler@nortom.com, bkuhn@ebb.org, guile@cygnus.com, gss@nortom.com
>Subject: Re: Considering Guile as part of a Master's Thesis
>
>Mikael Djurfeldt <mdj@nada.kth.se> writes:
>
>This reminds me - I /think/ I read somewhere about pretty good gengc
>that was also conservative.

There's a generational version of Boehm's conservative collector.
For fully conservative GC (with conservative heap tracing) it's
a little tricky.  You need to use VM protections to figure out
which pages get modified.  The overheads of the trap handling
tend to be fairly high, and it's usually not worth doing with
a small young generation.  You want a young generation of some
size---like 2MB---so that the young generation isn't GC'd so
frequently that re-protecting pages and handling faults on
them doesn't eat away the performance benefit of having
generations.

I don't think that should be a problem for Guile, though,
if you're only conservatively scanning the stack.

> I'm not sure how it was accomplished,
>though. One thing with Guile is that we can't do copying GC, but
>experience with RScheme shows that it wasn't too much of a problem.
>
>Does anyone have any references on this? If we don't see gengc done
>for masters thesis, it'd still be sufficiently interesting idea that
>somebody will want to tackle it. I do remember that Paul Wilson's
>article on various GC methods didn't have more than a passing mention
>of generational + conservative GC techniques.

Generational GC and conservative stack scanning should go together
fine---you should pretty much just take your conservative stack
scanning code and plug it in to any non-copying generational GC,
like ours.

This seems like a very doable little project.

The trickier part is making the generational GC thread safe.  You
need to make sure that the allocator and write barrier work right in
the presence of whatever kind of threads you use.  This is a non-problem
for RScheme because we use a "safe points" scheme for thread switching;
threads never switch except at places that are non-confusing for
the GC.  If you may have thread switches at any instruction, you
have to deal with synchronization issues.  I don't think these
issues are actually hard, either, but we haven't done them.

The main thing you want to do is replicate the data structures
that are frequently operated on, so that threads can usually
allocate and record write barrier events without synchronizing.