From: Rick DeNatale <rick.denatale@...>
Date: 2007-12-28T00:21:35+09:00
Subject: Re: Destroying an Object

On Dec 27, 2007 5:55 AM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
>
> On Dec 26, 2007, at 12:05 , Sam Smoot wrote:
>
> > BTW, objects in Ruby are not guaranteed to be GC'ed when there are no
> > more references to them. They can easily survive numerous cycles of
> > the GC and be found in the ObjectSpace. It's actually really
> > frustrating.
>
> That's conservative GC for ya... *shrug* It has never been much of an
> issue for me, but I can see where it can really hose you up.

It's a general feature of most GC algorithms, not just conservative*
ones.  The basic promise of a GC is that it WON'T reuse the storage
for an object as long as it's possible to be referenced.  In general
there's no guarantee of how fast the space for dead objects will be
reclaimed, often this won't happen until some heap runs out of space
when a new object is allocated, and sometimes not all dead objects
will be reclaimed even then. There are various trade-offs between
things like agressiveness and incrementalism (i.e. bounding the time
taken for GC pauses).

This delayed action of most GCs is one reason why it's a BAD idea to
use finalization to implement application logic.  You might want to do
something like closing a file in a finalizer, just in case it didn't
get closed otherwise, but you probably don't want to rely on
finalization to close those files.

* In my experience, the meaning of a conservative GC is that it treats
words on, say, the call stack as object pointers as long as they look
like they might be object pointers.  The MRI GC does this because it
has lots of C stack frames whose variables aren't all VALUEs but might
look so to the GC.

-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/