From: "M. Edward (Ed) Borasky" <znmeb@...>
Date: 2007-11-09T00:39:17+09:00
Subject: Re: Unrecovered memory leak thoughts.

Paul Brannan wrote:
> On Thu, Nov 08, 2007 at 09:13:34PM +0900, Rick DeNatale wrote:
>>> Anyway good luck to all.  Seems almost like it would be easier to just
>>> write a reference counting GC than find this bug, should it be a bug
>>> :)  I'd be willing to offer someone $100 US to build a reference
>>> counting GC for 1.9 :)
>> Reference counting has a couple of unfortunate 'features'.
>>
>> First, it's pretty inefficient in that it imposes an overhead on every
>> variable assignment to adjust reference counts.  Second, it can easily
>> leave permanently noncollectable constellations of  unreachable
>> objects which form reference cycles.
> 
> I question how significant reference counting would be compared to
> everything else going on in the interpreter.  Python uses reference
> counting and seems to have decent performance compared to Ruby.
> 
> The bigger issue is that extension writers would have to rewrite their
> extensions to increment the reference count when they do an assignment.
> 
> Paul
> 
> 
> 

Well ... there have been probably *thousands* of CS papers written on 
the subject of garbage collection, including reference counting, 
mark-sweep vs. stop-copy, generational vs. stop-copy, etc. What I 
*haven't* seen is an instrumented Ruby (although I'm working on that) 
and a collection of *real-world* examples of *production* usage for the 
garbage collector.

So my challenge to the Ruby community is to come up with test suites for 
the garbage collector. Maybe I'm asking on the wrong list, though -- 
should I be asking for this on the Rails list?

<ducking>

P.S.: I hear implementing reference counting is so non-trivial that it 
would literally have to have a *compelling* performance advantage to be 
worth the effort. Again, someone needs to come up with the test suites.

P.P.S: If your Ruby application is spending a lot of time in the garbage 
collector, you may be doing something wrong at the Ruby code level. Or 
you might need to allocate a bigger heap (assuming that's possible 
without changing the interpreter at the source level -- I haven't looked 
at this yet.)