A couple garbage collector questions

[Samuel A. Falvo II]

On 4 Apr 2001 13:54:24 GMT, Joshua Marshall wrote:
>Or stop-and-copy collectors in general, which don't need to touch
>every object like mark-sweep collectors do.

I really like the stop and copy collector theory, but they have practical
disadvantages that significantly impact runtime performance.

First, you need to perform a memory to memory copy of each object that is
referenced.  Because of this, a large amount of time is spent moving chunks
of memory.  On the other hand, you pretty much never need to worry about
memory fragmentation.

Second, references to objects *must* be doubly indirect.  The reason is that
an object's location can change at any moment in time.  Fortunately, Intel
CPUs have hardware support for this in the form of local and global
descriptor tables.  Unfortunately, *only* Intel CPUs offer support for this
today, which means that it's not used in many operating systems.  In fact,
it's not being used at all in any OS designed after 1990, and Intel is
eschewing support for segmentation in later generations of their CPUs (e.g.,
the IA-64).

Pity.  Segmentation is *very* useful when properly used to their advantage.

As it is, the application itself must doubly-dereference object references,
which incurs overhead when accessing the fields of objects.

-- 
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA