Paul Brannan wrote:
> On Fri, Dec 11, 2009 at 09:07:16AM +0900, Yukihiro Matsumoto wrote:
> Adding reference counting to ruby would not work with extensions (they
> don't know to increment the reference count) and would probably not be
> what we (the ruby community) want anyway.  The simplicity of writing
> extensions (due to ruby's conservative GC) is part of what makes ruby
> attractive to many people.
> 

Adding reference counting to MRI would make existing Ruby code that is 
not written to avoid cycles unusable, unless a periodic GC was done.

Writing code that does not create cycles is "unnatural" to me -- not 
worrying about cycles is one of the reasons I left Perl for Ruby after 
12 years.  This is not to say that having a reference counting option 
might not be suitable for some applications (real-time Ruby on a small 
device).

> Also, where are the bottlenecks in the GC today?  Is it the number of
> objects that have to be marked?  Could gc_mark itself be optimized so
> the cost of marking any given object is reduced?
> 

I'm not convinced that the GC is the issue, but I haven't really been 
measuring it in production environments.   I think common code or Ruby 
semantics that create avoidable garbage is the issue and would be an 
issue regardless of GC technology, including reference counting.

KAS