The OOPSLA'86 paper by Pat Caudill and I describes a technique we
originally developed for Tektronix Smalltalk and have used quite
successfully several times since then.

The basic idea, is that the data portion of a binary indexable object
(actually in Tek Smalltalk all indexable objects) is allowed to be remote
from the object header. This requires  one bit of encoding space (the
"remote bit") in the object header of indexable objects. If the remote bit
is clear, you have a normal object whose indexable fields are immediately
adjacent to the object header. If the remote bit is set, the indexable
fields are remote from the object header. In this case the header is
immediate followed by a pointer (the "Remote Pointer) to a "Remote Object
Descriptor" (called a BOT entry in the OOPSLA paper). The Remote Object
Descriptor contains a pointer to the actual data fields, the size of the
indexable part, and any memory management state (for example, if and how to
deallocate it) required for the remote data.

When accessing a binary indexable object the remote bit must be checked. If
it is clear, the field are accessed in the normal manner, relative to the
base address of the object. If the bit is set, a double indirection is
performed through the Remote Pointer and the Remote Object Descriptor to
access the indexable fields. Because objects with remote fields are
relatively rare, the cost of this for most array accesses is a single bit
test and a not-taken conditional branch.

At first it might seem that support of remote objects would have a
pervasive impact throughout the virtual machine implementation. In fact,
this wasn't the case. This is because binary indexable fields are only
accessed via at/atput primitives and a small number of specialized
primitives (for example bitblt). It is only those primitives that actually
need to be modified. Things are additionally simplified if care is taken to
ensure the constraint that instances of Float, CompiledMethod, contexts,
etc. never have a remote indexable part.

In addition to allowing the indexable part of an object to be fixed in
memory or to be in a non-Smalltalk data area other good things fall out of
having remote indexable parts:

"Large" objects are, by definition,  always indexable objects. If "large"
objects are always allocated with remote indexable fields then very
different memory policies can be used to manage small and large objects.

The data portion of a remote large object does not need to be copied, by a
copying collector.

The size field in the object header can be significantly smaller because it
does not need to describe large objects. If you're trickly you might
eliminte an entire header word.

#become: can be optimized in many ways, for example becoming two objects
with remote indexable fields is often simply a matter of swapping their
Remote Pointers.

Objects can be dynamically converted from non-remote to remote objects
allowing on demand "pinning" of object data.

A copying collector can dynamically convert objects from remote to
non-remote if appropiate.


Allen_Wirfs-Brock at Instantiations.com