A
TombStone is a design pattern, similar to (possibly a subset of)
BridgePattern - however,
TombStone serves a somewhat different purpose.
TombStones are commonly found in
GarbageCollectors/memory management systems,
VirtualMachines, and the like. A
TombStone is a fixed-size object, often containing little more than a pointer to a real object.
Some
GarbageCollectors and
VirtualMachines use
TombStones to decouple the references to an object stored elsewhere in the program (within other objects, or in variables) with its actual location. All references to the object are really references to the
TombStone; the
TombStone holds the sole pointer to the object itself. (The
TombStone might also hold a pointer to a
VeeTable or something similar; as a performance optimization - the important thing is that the
TombStone is of fixed size. Other metadata might appear as well, such as scratchpad space for the
GarbageCollector).
TombStones are typically held in their own area of memory (the
TombstonePool) as a cache optimization.
The
JavaVirtualMachine specification specifically allows (but does not require) use of
TombStones.
Anyone know which JVMs use TombStones and which don't? Many
SmallTalk implementations use
TombStones (see
ObjectTable,
ObjectTableEntry)
Consequences of using
TombStone:
- Operations and techniques like heap compaction, safe object destruction (destroying an object which still has references to it), WeakPointers, references that aren't memory pointers, etc. are easier to implement - the GC/VM need only alter the reference in the TombStone. (Of course, it may be cached in registers, which complicates things). Even conservative collectors can support heap compaction if TombStones are used. (The TombStone pool itself does not need compaction, as all TombStones are of fixed size and thus do not suffer fragmentation).
- Any dereferencing of an object reference now requires an additional memory access - to read the true address of the object from the TombStone. In many cases, the true address of an object can be cached in registers - at the expense of complicating any operation that alters that address.
- WeakReferences become trivial to implement - they are simply non-reference counted references through the TombStone. When the object is destroyed, the weak reference will point to an empty tombstone and thus will be able to report the object missing.
Is the above text attempting to describe a Smalltalk
ObjectPointer/
ObjectTableEntry? Is there a problem with using the terms
ObjectPointer and
ObjectTableEntry?
See also
BridgePattern EnvelopeLetter HandleBodyPattern DanglingPointer
Why are they called "tombstones"?
This sounds a lot like the Mac OS "handle" concept. --
TaralDragon
The tombstone I've heard of is the remnant of a deleted object in ActiveDirectory. You need something to say this object used to exist, so that replication from another copy that hadn't got the deletion doesn't accidentally resurrect the object. Called DeletionStubs in LotusNotes.
Conceptually it's subset of
ProxyPattern because outer object controls access to inner.
CategoryStructuralPatterns