From: quixoticsycophant@... (Jeff Mitchell) Date: 2004-07-21T13:22:05+09:00 Subject: Re: Ruby Specification Joel VanderWerf 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.