A couple garbage collector questions
Hannah Schroeter
hannah at schlund.de
Tue Apr 10 10:08:24 EDT 2001
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.
More information about the Python-list
mailing list