Re: integrating with GUILE's GC

[Lynn Winebarger <owinebar@indiana.edu>]

On 11 Jun 1999, Greg Harvey wrote:
> Actually, this is one of the bits I want to implement when guile does
> have os-level threads (in reality, the new gc should've been finished
> long ago, but I've been suffering a bit from
> `too-many-irons-in-the-fire-itis' ;). Since the write barrier for the
> gengc can easily be used to base an incremental gc around, it should
> come fairly cheap; being able to separately collect most threads
> should also be possible even without an incremental gc, provided the
> threads play fairly nice.

    I'm planning to attempt to structure the threads' memory use so that
this will be possible (separately collecting each thread) to some extent.  
It should be fairly hierarchical in nature (it's a streaming media server,
so there will be threads in charge of other threads, etc).  I'm thinking
if we declare some of the data members of the "employee" thread to be
private, then the "boss" thread shouldn't worry about collecting those
members, even though there would be an indirect path from the boss' root
set.

> It's not currently easy, but it could be done; most of guile only
> cares that it can do a SCM_NEWCELL(&foo), and be able to access the
> car and cdr of foo, though it does have the additional expectation
> being able to set the type of an object by munging around with the
> car, which almost definately won't fit in nicely with other methods of
> keeping the type information. I looked at some of the plugin type gc's
> and decided not to go that route, partly because I get a kick out of
> messing around with the gc :), but mostly because it's probably easier
> to implement an efficient gc around the specific needs of guile, than
> to take a generic gc and meld it into guile (though it would be an
> interesting project if someone felt up to it).

    Normally I'd agree, if GUILE was only to be used as a Scheme
interpreter.  But when it's hooked into another system that uses GC,
having "plug-in-ability" of the GC becomes more desirable.  Of course,
there probably aren't that many folks writing systems that use GC in C.

> Possibly. The current system basically just handles cons cells, which
> simplifies things a great deal (none of the fragmentation problems
> that come up in dealing with putting a whole object on the `heap';
> OTOH, it is just moving fragmentation issues to malloc & pals, but
> it's probably a safer assumption that these'll have fairly system
> specific optimizations for handling memory without too much
> fragmentation... admittedly, that's 90% cop out ;).

   With a mark and sweep algorithm it's definitely a concern.  I was
thinking of using stop-and-copy, though.  Since most of the server's
threads' will do a little work, then set a timer, the allocater should be
able to anticipate (to some degree) when a GC cycle is needed, and do it
in between the threads' waking up.  Then the allocation routine would be
super fast, and clean up would be done on time the thread doesn't care
about.

Lynn