From: Rick DeNatale <rick.denatale@...>
Date: 2007-10-03T21:59:24+09:00
Subject: Re: Reference vs. Reference

On 10/3/07, Xavier Noria <fxn@hashref.com> wrote:
> On Oct 3, 2007, at 5:23 AM, Rick DeNatale wrote:
>
> > One way to implement an object memory/heap is to use a level of
> > indirection, an object is represented by what's effectively an element
> > in an array of pointers, with the pointer holding the address of an
> > object's state.  Variables refer not to the object directly but to the
> > pointer, which is called a handle.  This allows the objects to be
> > moved (during GC for example) without requiring all references to the
> > object to be relocated.
> >
> > Two uses of object handles were in the earliest implementations of
> > Smalltalk, and in the old Macintosh OS.
>
> I think the JVM does (or did) something similar using an intermediate
> object table.

Perhaps, but I don't think that its a widely used implementation
strategy these days.  The main advantage seems to be that it's a
little easier to understand than more modern GC architectures.  On the
other hand it tends to limit the total number of objects because of
the need for an object handle table.

One of the things which the early Smalltalk memory management design
did was to enable the become method.  In Smalltalk one could say:

    object1 become: object2

and the objects referenced by object1 and object2 would swap
identities, kind of a 'Freaky Friday' effect
http://www.imdb.com/title/tt0322330/  This was used mostly to allow
collection objects to be resized.

To get around the limitations of a fixed size object table, it became
standard practice to let the handles exist in the heap along with the
objects, or perhaps in a separate heap.  The handle contained a
pointer to the bulk of the object and a few bit fields used for GC and
other housekeeping.

These days it's much more common to find object references to be
direct pointers with bit tagging to identify special immediate
references, and the non-pointer contents of the handle moved into
header fields in non-immediate objects.  The need for become: in
Smalltalk was obviated by refactoring the collection classes to hold
their contents in a separate array so that resizing could be done by
copying the contents array to a larger array rather than copying self
to a larger version and doing self become:largerSelf  at the same time
the semantics of become: changed from the two-way swapping to a
one-way version which scanned object memory for references to the old
object and changing them to point to the new.

Many modern GC designs move objects during GC, and some of these still
use indirect forwarding pointers to a limited extent, usually
temporarily during GC.

-- 
Rick DeNatale

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