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