From: Joel VanderWerf Date: 2004-07-21T13:31:23+09:00 Subject: Re: Ruby Specification Jeff Mitchell wrote: > 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. True. I was forgetting that the GC is conservative. So "eventually" may mean "before the interpreter exits".