Object Table 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 allocation calls.
• 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 be grown.
• 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) GC feasible.

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.

[INCOMPLETE]