[ruby-core:27496] Re: better GC?

Paul,

If compatibility with 'C' extensions is not a major concern for you, I'm
curious to learn why you haven't  tried using JRUBY?  Or, have you?

For real-time applications, what's needed is any sort of incremental GC to
replace the current "stop-the-world while I mark and sweep" MRI does now. 
Generational GC is just one means to that end.  MRI needs something that
incrementally collects garbage without copying objects.  In my opinion MRI
cannot simply "give up" compatibility with 'C' extensions without becoming a
new implementation entirely.

The run time of the current collector is roughly proportional to Ruby's
process size.  An optimization that saves memory, even if it adds CPU
cycles, tends to make MRI faster on the whole when dealing with large
numbers of objects.  For this reason alone, you might want to give the MBARI
patches a whirl.

- brent




Paul Brannan wrote:
> 
> On Fri, Dec 11, 2009 at 09:07:16AM +0900, Yukihiro Matsumoto wrote:
>> Yes, but unfortunately it's not small at all.  GC has a lot of
>> trade-offs and difficult technical dependency.  It's not that easy to
>> solve your frustration.  I am happy to be proven wrong (that means
>> patches are welcome).
> 
> As I mentioned to you at the conference, GC is the primary reason I can
> no longer use ruby for production code where I work.  We use perl5 and
> python instead, both of which use reference counting.  (We disable the
> cycle-finding GC in python and don't write code that produces cycles).
> 
> 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.
> 
> OTOH the dynamic language space is becoming more competitive every year,
> and it would be a shame to see ruby fall behind because it has to remain
> backward compatible.
> 
> Hypothetically, if ruby could give up backward compatibility with
> existing extensions, would the problem become any easier?
> 
> 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?
> 
> Just brainstorming a bit...
> 
> Paul
> 
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/-ruby-core%3A27135--better-GC--tp26735247p27080151.html
Sent from the ruby-core mailing list archive at Nabble.com.