From: Rick DeNatale <rick.denatale@...>
Date: 2007-11-10T22:38:38+09:00
Subject: Re: JRuby performance questions answered

On 11/9/07, Roger Pack <rogerpack2005@gmail.com> wrote:
>
> > Wow it would appear that jruby is indeed faster, and indeed uses a lot
> > more memory :)  (or maybe that's just startup overhead).  thanks for a
> > good program!
>
> I wonder if jruby uses reference counting for its ruby objects (or if it
> even matters), and if not maybe someday it would :)  I'm just in a pro
> reference counting mood these days :)

I very much doubt it.

Roger, you REALLY need to read the literature on GC which has been
accumulating for the past 50 years.

Reference counting is pretty much an obsolete approach to GC.  It was
probably the first approach taken for lisp back in the 1950s. Other
language implementations usually started with reference counting (e.g.
the first Smalltalk).

It's main advantage is that it's easy to understand. On the other hand
it incurs a large overhead since counts need to be
incremented/decremented on every assignment.  It can't detect circular
lists of dead objects. In early Smalltalk programs when reference
counting was used, you needed to explicitly nil out references to
break such chains.  There's also the issue of the overhead for storing
the reference count, and how many bits to allocate.  Most reference
counting implementations punt when the reference count overflows, they
treat a 'full' count as an infinite count and no longer decrement it,
leading to more uncollectable objects.

Mark and sweep, such as is used in the Ruby 1.8 implementation quickly
replaced reference counting as the simplest GC considered for real
use.

More modern GCs tend to use copying GCs which move live objects to new
heap blocks leaving the dead ones behind. And most use generational
scavenging which takes advantage of the observation that most objects
either die quite young, or live a long time.  This approach was
pioneered by David Ungar in the Berkeley implementation of
Smalltalk-80.  And this is the kind of GC typically used in JVMs
today.

Which particular GC approach is best for Ruby is subject to some study.

Many of the usages of ruby aren't quite like those of Java, or
Smalltalk.  I had dinner with a former colleague, who happens to be
the lead developer of the IBM J9 java virtual machine, and he made the
observation that Java, and Smalltalk before it have a long history of
having their VMs tuned for long running processes.  On the other hand
many Ruby usages are get in and get out.  These use cases mean that
it's more valuable to have rapid startup than perfect GC in the sense
that all dead objects are reclaimed quickly, not that any of the
current GCs guarantee the latter.

So the best GC for Ruby might not be the same as would be used for a
JVM or Smalltalk VM, but I'm almost certain it would be a reference
counter.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/