From: Rick DeNatale <rick.denatale@...>
Date: 2008-01-01T03:27:20+09:00
Subject: Re: Destroying an Object

On Dec 31, 2007 3:14 AM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
>
> On Dec 30, 2007, at 09:46 , Rick DeNatale wrote:
>
> > So both of these GC implementations return the space used by every
> > object at the instance the last reference to that object is lost?
>
> That wasn't what I was claiming of the GC I wrote, nor is that an
> attribute of conservative GCs (or any GC I know of). Instantaneous
> collection wasn't a part of this thread at all. The complaint (from
> Sam), as I interpreted it, was that conservative GCs sometimes NEVER
> collect an object (which is what makes them conservative), and that is
> all I was addressing.

Well NEVER is a long time.

Seriously, my point is that most GCs, conservative or not, tend to
trade off agressiveness, safety, and pragmatics. Every GC approach I'm
familiar with exhibits one or more of the following 'features'

1) They don't guaranteed to reclaim the space for every dead object,
for example, reference counting GCs won't collect circular garbage,
and many have reference counts which go something like 1, 2, 3 ...
2n-1, INFINITY for some usually small value of n, meaning that objects
which reach the maximum reference count (and those reachable by
transitive closure from those objects) will live as long as the
process does.

2) The reclamation of some objects can be delayed, sometimes rather
indefinitely.  Most GCs don't even attempt reclamation until space is
needed, and some families of GCs will partition objects into new
objects which are predicted to die soon and others which have lived
longer, get tenured and are considered for reclamation much less
frequently.

Now this happens with conservative and non-conservative GCs alike.
Conservative GCs do also keep 'objects' alive when they encounter a
pointer which might be pointing to an object.  These types of pointer
usually are on invocation stacks, and don't necessarily mean that the
objects are kept forever since what's on the stack is volatile, and
those 'pointer' values do tend to get overwritten as the program
executes.

-- 
Rick DeNatale

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