Re: integrating with GUILE's GC

[Greg Harvey <Greg.Harvey@thezone.net>]

Lynn Winebarger <owinebar@indiana.edu> writes:

> On 10 Jun 1999, Greg Harvey wrote:
> > It should be possible to have a gc to manage the c side of things, and
> > let guile's gc continue to handle the scheme side of things. The
> > interaction between the two could become complicated, though; you have
> > to handle bits like informing each gc when a particular object is
> > being held by the other gc.
> 
>     Yeah, actually I'd prefer not to do that if possible.  Since the
> system will have real time requirements, getting stuck in a GC cycle would
> be a real problem.  The server will be multithreaded, and each thread
> should be able to collect garbage relatively independently of the others -
> if Guile's GC mucks around every thread's memory space it would be bad
> news for meeting real-time requirements.

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.

> > > Is there any way to design the system to use a "plug-in" GC?  Like,
> > > for example, Paul Wilson et al.'s real-time GC?
> > 
> > I haven't actually looked at it yet (it's a pretty big download :),
> > but from the paper, it looks like it could be the easiest of the
> > `plugin' gc's to coerce into cooperating with guile. What might work
> 
>      Ok, my bad - I meant plugging a GC into the GUILE system.  So,
> say, I could register the GC with GUILE when it starts up, and then that's
> what it uses.  

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).

> I haven't looked at GUILE's source yet, but I'm guessing
> this is not the case, and probably making this workable would require
> weeding out object allocation assumptions. 

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 ;).

-- 
Greg