Object Table Techniques
An object table is a vector of identically sized
header objects or Object Table Entries. The application objects
are all built from a single OTE and one or more indirect blocks. OTE's
do not move in memory, but since they are identically sized, free-list techniques
The blocks hanging off the OTE provide the room for more data when the object would
be large than the OTE. Note that this system uses an extra level of indirection
in order to create a GC'd heap with some useful properties:
- Blocks can be compactified (or even moved to disk, compressed etc) without
affecting the application or changing the value of pointers. Pointers always
point to the OTE, and the indirect references are treated as volatile across
- Pointers never change, so that hashing of objects by address is possible.
- The object table can be treated as an array, and pointers can be integer indices into
it. Thus for small heaps pointers can be held compactly without wastage.
- Well-known objects can be pre-assigned an index in the table, without making
any non-portable assumptions about available address-space.
- Blocks can be atomically replaced by longer ones, should an object have to
- Pointers can be saved on disk and be valid in later runs of the same system.
Object Table methods can be added to most other existing algorithms, and already
provide the double-indirection needed to make incrementalal (or even concurrant)
Problems with Object Tables
- Inefficient extra indirection is required (although a limited number of fields can be
directly in the OTE.
- If the OT grows large, it cannot (in general) be shrunk again as objects free up
- Position in the object table cannot be kept related to age, so locality of reference
(for good cache-performance) in a generational GC is compromised.
- Allocation is more expensive since more than one piece of memory has to be allocated
and made to refer to each other.
Last updated by firstname.lastname@example.org
Tue 16 January 1996