There are some tricks that can be used to minimize indirection tests.

First remember that most object state accesses (with the exception of some
primitives) only occur within an method activation where the accessed
object is the receiver. So if the invariant that "the receiver of the
active context must not be a forwarder" is maintained then most routines
(eg instance variable access) will not have to worry about checking for
forwarders. This invariant can be maintained by the context activation code
on sends and returns.

Some other "naked" deferencing accesses can be made safe by special case
restrictions on the use of becomes:  For example, don't allow an
Association used as global binding to be forwarded. (This is one of several
reasons it is a good idea to use some specialized subclass of Association
for global findings.)

One significant use of become: is to "mutate" existing instances when a
class definition is changed in a manner that adds or removes instance
variables. The entire object space needs to be scanned for existing
instances and each of them must be becomed to its new representation.
Unfortunately, often this is wasted effort because the program(er)
immediately throws away the existing instances. At Tektronix I invented a
technique called "lazy mutation" which was latter used quite successfully
in Digitalk Smalltalks. Instead of doing an allInstances and multiple
becomes (both expensive operations in an OT-less implementation) when a
class definition is changed the existing behavior object (the class
referenced by all existing instances) is modified such that message lookup
will fail (make its superclass nil and give it a method dictionary
containing only #messageNotUnderstood:). Its message not understood
behavior is defined to create an instance of the revised class and to
become the old instance to the new instance (the devil is in the details).
When execution resumes if an old instance is discard no become is every
performed on it. If an old instance is continued to be used then the first
time a message is sent to it, it is transparently mutated into its new
representation.

Allen Wirfs-Brock

At 04:10 PM 10/15/98 -0700, Tim Rowledge wrote:
>On Thu 15 Oct, lex at cc.gatech.edu wrote:
>
>> It doesn't have to.  Suppose one does "A become: B".  The system could
overwrite A wit
>> h an "indirection object" which points to B; call it I(B).  Whenever the
system sends 
>> a message to the object that used to be A, it will see an I(B) sit
>> ting there, and forward the message on to B.  
>> 
>> The efficiency should be about that of using an indirection table for
all objects, but
>>  it would only take effect for objects that have had a "become:" done to
them.
>There is also the cost of a test everytime you might possibly find an
>indirector. I'm sure I've read about some analysis of this sort of cost
>somewhere - could it have been in Ungar's PhD thesis? Anybody know? Eliot,
you
>still have my copy, can you look and see :-)
>
>Don't forget that the check would not only be during message sends, but
>anywhere that an oop is 'dereferenced' which is in quite a lot of places.
>
>tim
>-- 
>How do I love thee?  My accumulator overflows.
>Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
> tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>
>
>