[#144] Another implementation of Bignum — "Dmitry Antipov" <dmitry.antipov@...>

Hello Ruby hackers,

15 messages 2002/06/06

Re: Improving Ruby's garbage collector for interactive apps

From: matz@... (Yukihiro Matsumoto)
Date: 2002-06-20 17:54:36 UTC
List: ruby-core #177
Hi,

In message "Improving Ruby's garbage collector for interactive apps"
    on 02/06/19, Matthew Bloch <mattbee@soup-kitchen.net> writes:

|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?

Yes and yes.  Generational mark and sweep algorithm was done before,
but it was not good enough, probably due to write barrior cost.

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

It should be conservative, to make extension development easy and
reliable.  At least, I want extension writers not worrying about
reference management.  I really hate GC_Protect and INCREF.

							matz.

In This Thread