Re: JRuby performance questions answered

Roger P. wrote:

Rick Denatale wrote:

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


I spent a good bit of time the other day downloading some of this
“literature”. From a theoretical computer science perspective, it can
be shown that all garbage collection schemes are equivalent in a broad
sense. And when you benchmark them, all of them have strengths and
weaknesses that are workload-dependent.

And IIRC the first Lisp garbage collector was pure mark-and-sweep. I
forget where reference counting was first used – maybe Snobol. And
stop-and-copy was also developed very early, maybe for Scheme. All
three of them are quite simple to understand, once you’ve bitten the
bullet and learned recursion. :slight_smile:

This is somewhat confusing for me, because it seems that using a
mark and sweep generational style GC slows down Ruby, as per

Matz’s observations:

At a higher level, if you are doing a lot of garbage collection, you
need to look at your algorithms. And you need to supply a large enough
working set of real memory before you go finger-pointing at the
garbage collector, regardless of its type. There are some pretty good
web sites out there that have, via profiling, made some tremendous
improvements in Rails performance this way.

I suppose I’m just naive, but it doesn’t seem clear to me which is
the ‘best’ GC style, from the above observations. There appears to
be no clear answer.

That’s because it’s workload-dependent. What’s worse, overall
performance on “modern” architectures is highly dependent on spatial
and temporal locality in your interpreter, whether it’s method
dispatch, garbage collection, regular expression processing, bignum
operations, etc. It’s not just garbage collection by any stretch of
the imagination. That’s why I profile Ruby interpreters. :slight_smile:

M. Edward (Ed) Borasky

“A mathematician is a machine for turning coffee into theorems.” –
Alfréd Rényi via Paul Erd?s

M. Edward (Ed) Borasky [email protected]