A TombStone is a design pattern, similar to (possibly a subset of) BridgePattern - however, TombStone serves a somewhat different purpose. TombStone''''''s are commonly found in GarbageCollector''''''s/memory management systems, VirtualMachine''''''s, and the like. A TombStone is a fixed-size object, often containing little more than a pointer to a real object.

Some GarbageCollector''''''s and VirtualMachine''''''s use TombStone''''''s 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). TombStone''''''s 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 TombStone''''''s. ''Anyone know which JVMs use TombStone''''''s and which don't?'' Many SmallTalk implementations use TombStone''''''s (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), WeakPointer''''''s, 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 TombStone''''''s are used. (The TombStone pool itself does not need compaction, as all TombStone''''''s 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.

	* WeakReference''''''s 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 DeletionStub''''''s in LotusNotes.''
----
Conceptually it's subset of ProxyPattern because outer object controls access to inner.
----
CategoryStructuralPatterns