A couple garbage collector questions

[Hannah Schroeter]

Hello!

In article <slrn9cmnou.hcj.kc5tja at garnet.armored.net>,
Samuel A. Falvo II <kc5tja at armored.net> wrote:
>[... stop and copy GC ...]

>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.

Read up on copying generational GCs. Yes, they do copy long-lived objects
a few times, but less than you might think if you think about a simple
two-space copying GC.

And OTOH, you gain *fast* allocation in copying or otherwise compacting
GCs. (check if alloc-pointer + alloc-size > alloc-limit, if yes, trigger
GC, if no, allocated <- alloc-pointer, alloc-pointer += alloc-size;
that check can be done once per basic-block, using a conservative
approximation of the complete basic-block allocation amount for the
check) So, short lived heap objects are about / nearly as fast as
stack allocation, and long lived objects are not too bad if you use
generational GC techniques instead of simplistic copying GC.

>Second, references to objects *must* be doubly indirect.  The reason is that
>an object's location can change at any moment in time.

No. Read up about a simple iterative technique for two-space copying
which fixes up all object pointers during GC time. No double indirection
in there!

However, you need a write barrier for writes into older generations,
if you use a generational GC scheme. THAT can be a performance hit
if it's not done well.

>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).

Segmentation is coarse grained and cannot be used to alleviate fine-grained
double indirections.

>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.

See above.

Kind regards,

Hannah.