Joel VanderWerf <vjoel / PATH.Berkeley.EDU> wrote in message news:<40FC2CD0.7090408 / path.berkeley.edu>...
> Mark Sparshatt wrote:
> > The problem would come if someone did release an alternate 
> > implementation of Ruby with reference counting GC. Then if people who 
> > were used to alternate Ruby moved to standard ruby they might expect the 
> > same behaviour, and assume it's a bug when standard ruby behaves 
> > differently.
> 
> In my understanding, ruby makes no guarantees about memory management, 
> except that unreferenced objects will eventually get recycled. A ruby 
> specification should state explicitly that, aside from this guarantee, 
> behavior is unspecified.
> 
> Of course, if programmers don't read the spec, they can still get bitten...

Technically there is not even a guarantee that an unreferenced object
will be recycled.  Data on the stack can collide with a non-immediate
VALUE, causing the GC to believe a reference still exists after the
"real" references are gone.

Of course the probability of such a collision is small, but it doesn't
hurt to know it is there.  For long-running daemons using many objects
and/or ruby C code using lots of stack space it may possibly be
something to consider, though I haven't looked at the numbers yet.