Re: JRuby performance questions answered

Rick DeNatale wrote:
> 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.

I don't think reference counting is any easier to understand than pure 
mark-and-sweep or pure stop-and-copy. The main advantage of reference 
counting in my opinion is that its restrictions force you to kick some 
features out of your language design if you want to use it. :)


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

My recollection is that mark-and-sweep was the original, and that 
reference counting came later.

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

Bah ... I actually found a reference a couple of days ago on this 
(http://portal.acm.org/citation.cfm?id=91597). If you're not signed up 
for the ACM library it will cost you money to read it. But essentially 
"pure" mark-and-sweep was replaced by stop-and-copy, which compacts the 
heap. Then generational mark-and-sweep came along and "rehabilitated" 
mark-and-sweep. Note the publication date -- 1990. The abstract is free 
-- it reads:

"Stop-and-copy garbage collection has been preferred to mark-and-sweep 
collection in the last decade because its collection time is 
proportional to the size of reachable data and not to the memory size. 
This paper compares the CPU overhead and the memory requirements of the 
two collection algorithms extended with generations, and finds that 
mark-and-sweep collection requires at most a small amount of additional 
CPU overhead (3-6%) but, requires an average of 20% (and up to 40%) less 
memory to achieve the same page fault rate. The comparison is based on 
results obtained using trace-driven simulation with large Common Lisp 
programs."

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

I think at least for Rails on Linux, someone (assuming funding) could 
collect and analyze plenty of data. I'd actually be surprised if someone 
*isn't* doing it, although I know *I'm* not. ;)

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

Well ... OK. If you want to distinguish between long running (server) 
and rapid startup (client), that's fine. But look at the marketplace. We 
have servers, we have laptop clients, we have desktop clients, we have 
mobile clients, and we have bazillions of non-user-programmable 
computers like DVD players, iPods, in-vehicle navigation systems, etc.

Now while the hard-core hackers like me wouldn't buy an iPod or a DVD 
player, preferring instead to add hard drive space to a real computer, 
Apple isn't exactly going broke making iPods and iPhones that are (for 
the moment, anyhow) closed to "outsiders". And I'm guessing that, while 
you *can* run Ruby on, say, an embedded ARM/Linux platform, most of the 
software in those gizmos is written in C and heavily optimized.

I've got a couple of embedded toolkits, and I've actually built Ruby for 
them, but when you only have 32 MB of RAM, you don't want to collect 
garbage -- you don't even want to *generate* garbage! So I wouldn't 
personally spend much time thinking about garbage collection for rapid 
startup. If you want rapid startup, you're going to have as much binding 
as possible done at compile time -- you aren't even going to compile a 
Ruby script to an AST when you start a process up.

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

Did you mean to say, "not be a reference counter"?