Re: integrating with GUILE's GC

[Lynn Winebarger <owinebar@indiana.edu>]

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.

> > 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.  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. 
     If this isn't available, I'll work on adding it when the time comes
to worry about it.  It might be a while before that time comes, but it
will - either that, or if we get grant money, have the person working on
our GC system do it.

> is having a container object registered with the rtgc, with each
> object that's accessible from guile, and when the guile object is
> collected, you could remove it from the container (you could do this
> with an smob free function, for example). Then, all you really need is
> to make sure that any munging on the rtgc objects that guile does goes
> through the proper channels (the impression I got from the paper is
> that that's pretty much automatically handled by an overloaded
> assignment operator anyway, so it's probably not even something you'd
> have to worry about).

    Actually, all our code will be written in C, which means we'll have to
translate the system to handle C instead of C++.  But the objects will all
be laid out in particular ways, and their layouts recorded dynamically (to
allow for dynamic loading).
   Thanks for the detailed response.

Lynn