Improving Ruby's garbage collector for interactive apps

re: this problem I had a few weeks back:

  http://groups.google.com/groups?hl=en&lr=&th=690604f9e21251a&rnum=1

I'd like to try to take this problem in hand and alter Ruby's garbage 
collection to more easily accommodate programs requiring smooth animation.  
The conclusion that I reached was that Ruby's GC takes unpredictable amounts 
of time to run at any point, and that calling GC.start every animation frame 
did nothing to alleviate the problem.  

I'm new to the practice of how GCs work in so my starting point (apart from a 
few college notes) has been Paul Wilson's widely-referenced "Uniprocessor 
Garbage Collection Techniques" paper:

  http://citeseer.nj.nec.com/wilson92uniprocessor.html

and the exposition given in the introductory sections of :

  http://www.daimi.aau.dk/~beta/Papers/Train/train.html#GS93cite

is pretty useful too.

So from my survey of gc.c, Ruby's collector is the simplest possible mark & 
sweep algorithm which necessarily halts the whole system to do its work, and 
is conservative in that it doesn't necessarily find out about all garbage 
(because it must guess at what's a pointer and what's not).  Is this correct?

Initially I suppose I'm looking for the simplest possible hack to try to 
smooth out the bumps but currently I'm still looking into the way that other 
parts of the Ruby interpreter are required to support the garbage collection, 
since this obviously will influence my choice of technique.  I'm still 
looking into this, but in the meantime if anybody has any thoughts as to what 
direction they'd like to see this work take, I'd be interested to hear it, 
especially from Matz or other veterans of the Ruby memory management.

cheers,

-- 
Matthew Bloch                 Bytemark Computer Consulting
                                http://www.bytemark.co.uk/
                                  tel. [phone]