Evaluating Message Passing Control Techniques in Smalltalk

Stéphane Ducasse
Software Composition Group, Universität Bern
[email protected]
http://www.iam.unibe.ch/ ducasse/ 
Appeared in JOOP (Journal of Object-Oriented Programming) June 1999

Abstract message passing control is not explicitly provided.

However, its reflective capabilities allows one to
In a language like Smalltalk in which objects com- define message passing control using various tech-
municate only via message passing, message pass- niques: The best-known is based on the definition of
ing control is a fundamental tool for the analysis so called minimal objects and the specialization of
of object behavior (trace, spying) or for the def- the doesNotUnderstand: method [Pas86, Lal90,
inition of new semantics (asynchronous messages, PWG93]. Some other techniques exist like the def-
proxy,...). Different techniques exist, from the well inition of method wrappers [Bra96] or anonymous
known approach based on the specialization of the classes[McA95].
doesNotUnderstand: method to the exploitation
the method lookup algorithm done by the virtual
machine. Until now no comparison between these
techniques has been made. In this article we com-
pare the different techniques taking into account the Up to now, no comparison between these tech-
reflective aspects used, the scope, the limit and the niques has been made that evaluates their applica-
cost of the control. bility, benefits and drawbacks. This is a problem be-
Keywords: message passing control, instance spe- cause each solution possesses good and bad points
cialization, doesNotUnderstand:, error handling, and often people apply a technique without check-
method compilation, anonymous class, minimal ob- ing all the consequences of their choice.
ject

1 Message Passing Control: A In this article we compare these techniques tak-

need ing into account the reflective aspects used, the con-
trolled objects, the integration of the control into the
Message passing control is the corner stone of a programming environment, the limit and the cost
broad range of applications from application anal- of the control. We start by giving an overview of
ysis (trace[BH90, PWG93], interaction diagrams, the different applications of message passing con-
class affinity graphs) to the introduction of new lan- trol in section 1.1. We define the criteria to com-
guage features (multiple inheritance[BI82], inter- pare the different techniques. For the sake of un-
faces [Sch96], distributed systems[GGM95, Ben87, derstanding, we summarize the reflective facilities
McC87], active objects [Bri89]...). CLOS is one of of Smalltalk on which such techniques are based.
the rare languages that made the effort to explic- We then present each main technique in detail: er-
itly provide message passing control at the meta- ror handling specialization in section 2, exploiting
level via its MOP [KdRB91, Bec95]. In Smalltalk, the VM method lookup in section 3, and modifica-
 This research is supported by the Swiss National Science tion of the compiled method in section 4. Finally
Foundation, grant 2000-46947.96. This article is an extension we conclude with a discussion of message passing
of the article [Duc97] control in other languages.

1
1.1 Message Passing Control Applica- Reification and Dynamic Creation. In
tions in Smalltalk Smalltalk, classes and methods are objects and
are described by classes. It is not only possible,
Applications1 which use message passing con- as in Java [Fla97], to access to the information
trol can be roughly sorted into three main cate- that represents such entities but also to modify and
gories. The first is application analysis and in- dynamically create instances of these classes.
trospection that is based on the development of In VisualWorks, classes are dynamically created
tools that display interaction diagrams, class affin- by invoking the method subclass:instanceVaria-
ity graphs, graphic traces [BH90, PWG93, Bra96, bleNames:classVariableNames:poolDictiona-
Mic96]. The second category is Smalltalk language ries:category: of the class Class. It is possible to
extension. In such a case message passing con- access and modify the inheritance link, the method
trol allows one to define new features from within dictionary and the methods defined in method
the language itself: Garf [GGM95], Distributed dictionary of a class (methods superclass, super-
Smalltalk [Ben87] or [McC87] introduce object dis- class:, methodDictionary:, compiledMethodAt:
tribution in a transparent manner. Language fea- of the class Behavior in VisualWorks).
tures like multiple inheritance [BI82], backtrack-
ing facilities [LG88], instance-based programming aClass
[Bec93b, Bec93a, Hop94], Java interfaces [Sch96] OrderedCollection aMethodDictionary
methodDict #add: CompiledMethod
or inter-objects connections [DBFP95] have been ... #collect
introduced. Futures [Pas86, Lal90] or atomic mes- ...
sages [FJ89, McA95] are also based on message
aCompiledMethod
passing control capabilities. The third category
bytes
is the definition of new object models, introducing 16666918 mclass #[21 68 68...]
sourceCode
concurrent aspects such as active objects (Actalk 1 #copyEmpty
2
[Bri89]) and synchronization between asynchronous
collect: aBlock
messages (Concurrent Smalltalk [YT87]). Other |newCollection|
work proposes new object models like the compo- newCollection := self copyEmpty: self size
[...
sition filter model [ABV92] or CodA that is a meta-
object protocol that controls all the activities of dis- Figure 1: Relationship between class, method dic-
tributed objects [McA95]. tionary and compiled method in VisualWorks. The
collect: method of the OrderedCollection class.
The instance variable sourceCode holds an index
1.2 Selected Reflective Features of that is used by the source manager to retrieve the
source code for the method.
Smalltalk
In VisualWorks, methods are instances of the
Even if Smalltalk is a reflective language [GR89, CompiledMethod class. They can be created
FJ89, Riv96], it is not possible to change all its as- by invoking the method compile:notifying: of
pects. Indeed, the virtual machine (VM) defines the class Behavior. As shown in figure 1, they are
way the objects are represented in memory, and how stored in the class method dictionary. A compiled
messages are handled. As message passing control method defines information to access its source code
implementations have to use the reflective facilities (sourceCode), its compiled byte codes (bytes), the
offered by the VM, we now summarize them. class that compiled it (mclass) and a variable part
The Smalltalk dialects referenced are: Visual- called the literal frame of the method that contains
Works (previously named ObjectWorks from Par- Smalltalk literal objects, such as the symbols, ar-
cPlace newly ObjectShare), IBM Smalltalk (inte- rays, numbers, byte-arrays and blocks defined in the
grated into the VisualAge environment of IBM) and method.
VisualSmalltalk (previously Smalltalk/V then Parts Note that the source code of a method is stored
of Digitalk). Note that the examples will be pre- separately from its byte codes and that a method
sented using VisualWorks and that we will discuss only needs its byte codes to be executed. The
the other solutions when there are significant differ- method source can be changed without changing
ences. the executable byte codes of the method. More-
1 Due to the space limitation we limited this short overview to over, a compiled method is similar to a Lisp lambda-
the use of message passing control in Smalltalk. expression because it does not know its selector. To

2
know the name of a method (its selector) the class The reification of the message is done by the VM
for which it was compiled is asked. A compiled by creating an instance of the class Message. For
method can be executed without being defined in a example, the message 3 zork: 4 leads to the invo-
method dictionary. cation of 3 doesNotUnderstand: aMessage for
Finally, it is possible to invoke a given method which aMessage possesses the following informa-
without first doing dynamic dispatch (methods tion:
valueWithReceiver:arguments: of class Com-
aMessage selector -> #zork:
piledMethod in VisualWorks and executeWithRe-
aMessage arguments -> #(4)
ceiver:andArguments in IBM Smalltalk). Note
that this last functionality did not exist in the first
implementations of Smalltalk. This recent addition A deontological remark. Some of the functional-
explains why only a few implementations are based ities presented above and used in the techniques to
on this possibility. be described are qualified as private in the Smalltalk
Moreover, the method perform:with: defined on versions and therefore are subject to change. It is
the class Object allows one to explicitly send a mes- common use and good style not to use such private
sage to any object in the system. anObject per- methods. However, the internal aspects of the pre-
form: #zork with:12 sends to anObject the mes- sented techniques imply their use. We stress that if
sage whose selector is zork and argument 12. such methods would had been really private some
interesting techniques would have been simply im-
Changing Reference. The become: primitive al- possible.
lows one to change object references. After invok-
ing a become: b all the pointers that pointed on
a point to b and conversely. Note that the seman- 1.3 Three Main Techniques
tics of this primitive depends on the Smalltalk im- First of all message passing control is not limited to
plementations: it is symmetric in VisualWorks and the definition of auxiliary methods executed before
asymmetric in IBM Smalltalk. and after the controlled method. Indeed, a full mes-
Changing of Class. An object can dynamically sage control should be able to modify the original
change its class, from a source class to a target class. arguments, to change the semantics of the message
This change can be perceived as pointer swap when as in remote-calls or even to refuse the execution of
the two classes possess the same instance struc- a method [DBFP95].
ture. In VisualWorks the method changeClassTo- We identified 6 different techniques to implement
ThatOf: takes as argument an object whereas in message passing control. However, some of them
IBM Smalltalk the method fixClassTo: takes a are difficult to reproduce or lead to unportable code.
class. The implementors of VisualWorks are then That’s why we briefly present and sort these tech-
sure that the target class is an instantiable class with- niques before describing the selected ones.
out having to test this at the VM level. The change1. Source code modification. One way to control
of class is only possible if the format of the source
message passing is to instrument the code via source
and target classes are compatible. The format of one
code modification and recompilation. In case of im-
class describes the memory layout of its instances plementing a control similating CLOS-like before
(methods format, setFormat: defined on the Be- and after methods, a controlled method setX:setY:
havior class in VisualWorks, and instanceShape, could look as follows after source code modifica-
instanceShape: defined on the class Class in IBM tion. As the object responsible for the message pass-
Smalltalk). ing control is not necessarily the receiver itself, we
Message Reification and Error Handling Spe- use an ellipsis to represent it. For example, in the
cialization. When an object receives an unknown case of meta-object approaches [McA95], the re-
message, the Smalltalk virtual machine sends the ceiver is not its own controller.
doesNotUnderstand: message to this object with setX: t1 setY: t2
the reification of the message leading to this er- ...before
ror. On the class Object the method doesNotUn- Original source code
derstand: raises an exception which, if it is not ...after
trapped (unhandled exception), opens the debugger.
This method can be specialized to support message Note that one might try to use the method aBlock
passing control as will be shown in 2. valueNowOrOnUnwindDo: anotherBlock that

3
allows one to trap the return out of a method. This The three last techniques can be implemented
method evaluates aBlock (the receiver) and when from within the language itself at a reasonable level
this block exits, it evaluates anotherBlock. How- of abstraction and, they are portable. That’s why we
ever, this is not appropriate, because, as we stated only will present and compare them in detail in the
earlier, the execution of the controlled method can following sections.
be delegated to the message passing control and not Note that we take into account only those tech-
limited to additional actions like before and after niques that introduce a control of standard message
method executions. Note that to simplify the pre- passing from the language itself. The key point here
sentation we will present controlling method body in is that we want to control objects already defined in
case of a control simulating before and after CLOS- the Smalltalk language. Therefore we exclude ap-
like methods and we will discuss how this can ex- proaches based on meta-interpreters that define their
tended to full control. own explicit message sending [Coi90].
The main drawbacks of this technique are: All
controlled methods have to be reparsed and recom- Remark. Message reification allows a particular
piled. Moreover, another recompilation is needed to interpretation of the message semantics such as
reinstall the original method. This technique is not asynchronous messages [Fer89]. However, message
applicable in deployed or stripped images in which reification on its own does not allow one to con-
scanners and compilers have been removed. trol specific objects [Fer89, DBFP95]. Moreover, as
mentioned by Adele Goldberg in [GR89] message
2. Byte code extension. Smalltalk is based on a
byte-code interpreter [GR89, IKM+ 97], so it is pos-
reification has only been introduced in Smalltalk
for error handling due to efficiency reasons. Nev-
sible to add new byte-code in order to introduce new
ertheless, the combination of message reification
message passing semantics, like in the Concurrent
and instance-based control techniques offers a wide
Smalltalk approach [YT87]. However as the result-
range of possibilities. For example, in CodA mes-
ing interpreter is no longer standard and the applica-
sage passing control is implemented using the tech-
tions are no longer portable, we do not discuss this
nique 5, but the message reification provided by the
technique.
technique 4 is also used for the various message se-
3. Byte code modification. Another way to con- mantics offered in CodA [McA95].
trol message passing is to directly insert new byte-
code representing the control into the compiled 1.4 Some Comparison Criteria
method byte-codes [MB85]. However, implement-
ing this technique is far from simple. More impor- To compare the techniques on a common basis we
tant, it heavily relies on knowledge of the byte code propose the following comparison criteria.
instructions used by the virtual machines. These Control granularity. Sometimes it is necessary to
codes are not standardized and can change. only control one specific message sent to one spe-
4. Specialization of error handling. The idea cific object. In other cases, all the messages sent
is to encapsulate controlled objects into so called to a set of objects should be controlled (note that
minimal objects that do not understand messages objects can share the same message passing control
and to specialize the doesNotUnderstand: method definition without belonging to the same class).
[Pas86, Bri89, PWG93] (see section 2). So a control can be applied to all the instances of
one class in a similar manner, or only to certain in-
5. Exploiting the VM method lookup implemen- stances, or only one instance. We call the first pos-
tation. This is realized by explicit subclassing or sibility a class-based control, the second a group-
by the introduction of anonymous classes in the in- based control and the third one an instance-based
stantiation chain [FJ89, McA95, Mic96, Riv97], or control.
by the definition of a method dictionary array in Moreover, we qualify a control as global if all the
VisualSmalltalk [Bec93b, Bec93a, Pel96] (see sec- messages sent to an instance are controlled, as class-
tion 3). based if all the methods of the class of the object are
controlled and as selective if it is possible to only
6. Method substitution. The idea is to change
control certain specific messages.
the compiled method associated to the selector in
class method dictionary [BH90, Bra96, Riv97] (see Environment Integration. Since Smalltalk im-
section 4). plementations offer rich programming environ-
ments, we also consider the impact of the techniques

4
on the proposed tools. It is important to know if Note that the use of the become: primitive is
the browsers and their functionality (senders, imple-only necessary when one needs to control exist-
mentors, messages, class references, instance vari- ing objects of the Smalltalk library [Pas86, Lal90,
PWG93, GGM95]. In [Ben87, McC87], the goal is
able references,. . . ) continue to work after applying
the message passing technique. not to control predefined objects but to define con-
trollable objects, so the reference exchange is not
Efficiency. To compare the execution costs we
necessary: messages are controlled because they are
consider that the code executed during the control,
simply unknown for the object. Note that for this
such as a display in a trace, to be constant for all
particular case the methods inherited from Object
the techniques. The cost takes into account only
class should be recompiled to include control and
the mechanism used to control the invoked method.
substitute primitives calls by controllable methods
Moreover, we evaluate if the process requires meth-
[McC87].
ods to be recompiled during the installation of and
during the reinstallation of the original methods.
Definition Cost. Finally we should mention if the
proposed solution is easy to implement or if it needs
quite complex mechanisms. 2.1 Minimal Object
Glossary. Controlling entities (classes and meth-
ods) are those that implement the message passing The creation of a minimal object [Bri89, PWG93],
control. Original entities are those that are normally also named capsule or encapsulator, is based on the
executed in absence of control. creation of a class that does not inherit from Ob-
ject class. Doing so all the messages sent to an
instance of such class invoke the doesNotUnder-
2 Error Handling Specialization stand: method and then are controlled. The code
to invoke the original method can be the following
As presented in 1.2, when an object receives an un- one:
known message the method doesNotUnderstand:
is invoked. The technique consists of defining min- MinimalObject>>doesNotUnderstand: aMessage
imal objects that will encapsulate the object being ...”control specific actions”
controlled. A minimal object is an object for which originalObject perform: aMessage selector
ideally each message provokes an error. Note that to withArguments: aMessage arguments
be viable in the Smalltalk environment such an ob- ...
ject should possess a minimal set of methods that do
not lead to an error. We use the become: primitive The creation of classes that inherit from nil
to substitute the object to be controlled by a minimal (the unique instance of the UndefinedObject class
object that encapsulates it. whose value means referring to nowhere) does not
The figure 2 illustrates the message passing con- lead to the desired solution. Indeed Smalltalk al-
trol: (1) the original message is sent, (2) the VM lows the creation of new root inheritance classes.
invokes the method doesNotUnderstand: and (3) To do so, the class creation protocol is redefined on
the original method is executed. the class UndefinedObject to permit the creation
of class that does not inherit from any other class.
old reference However, to integrate such classes in the Smalltalk
a capsule
or a spy environment, Smalltalk defines a specialized version
controlled object of the doesNotUnderstand: method that automati-
anObj cally and lazily copies the methods from the Object
class. We then obtain an incremental copy of Object
(3) anObj m
new reference (1) class.
capsule doesNot VM The right technique to create a minimal object
Understand: aMessage
(2) is the following: (1) creation of a subclass of Ob-
ject, (2) assignment of the superclass link to nil and
Figure 2: Installation of minimal objects and mes- (3) definition of the minimal behavior by copying
sage passing control by generation and control of the needed methods from Object. Here follows the
errors. code taken from Actalk [Bri89].

5
 controlled, this approach is the only one to offer the
MinimalObject class>>initialize
superclass := nil.
ability to control all the sent messages. It is not
#(doesNotUnderstand: error: ˜˜ isNil = mandatory to know in advance the potentially con-
== printString printOn: class inspect basicInspect trollable messages.
basicAt: basicSize instVarAt: instVarAt:put:) In addition to the above mentioned problems this
do: [:selector | self recompile: selec- approach is not efficient as shown in 5.1. Indeed,
tor from: Object] the control is based on the error of the lookup of
the method associated with the message. Thus each
control needs one additional lookup and a double
2.2 Problems
traversal of the execution stack due to exception
This approach implies three main problems identi- handling. Moreover, each control implies a message
fied by [PWG93]. instance creation.
This approach is simple to implement when one
The self problem. The variable self is a pseudo-
does not attempt to solve all its inherent problems
variable with which objects refers to themselves
such as those linked to the identity of the object.
without using explicit pointers. Messages that an
object sends to itself are not redirected to the min-
imal object and thus not controlled. Moreover, this 3 Exploiting of the VM Method
problem appears not only when an object sends mes- Lookup Algorithm
sages to itself. In fact a message can only be con-
trolled if: (1) the message is not sent by the object In object-oriented programming, the standard ap-
itself and (2) the reference from the sender of the proach for specializing behavior is subclassing. In
message to the receiver of the message (the origi- Smalltalk, when an object receives a message, the
nal object) was not installed via a reference to self lookup of the method starts in object class and fol-
[PWG93]. The authors of Spies [PWG93] proposed lows the inheritance link. The super variable allows
a delicate and costly solution based on the dynamic one to invoke overridden methods. Its semantics is
analysis of the execution stack to detect if the mes- to start the lookup in the superclass of the class in
sages sent should or should not be controlled. which the method was found.
Class Control. Control of classes is impossible Controlling sent messages is possible by interpos-
because classes can not be swapped by objects of ing between the object and its original class a new
different nature. The ClassBuilder uses become: class that specializes the looked up methods. This
when a class is incrementally defined but the swap can be achieved by an explicit traditional subclass-
is done between two classes. ing (see figure 3) or an implicit subclassing based on
anonymous classes associated to each instances and
Minimal Object. As already mentioned a mini- a class change (see figure 4).
mal object should define a minimal set of meth-
ods such as class, isKindOf,=, ==, instanceVarAt:, Common Principle. This approach is composed
myDependents... This leads to the problem of the by three aspects: (1) creation of the controlling class
interpretation by the minimal object of messages that will be interposed between the object and its
that were initially destined for the controlled object. original class, (2) definition of controlling methods
The problem is double because not only is the mes- in that class and (3) class change (see in 1.2). Con-
sage executed by the minimal object but the con- trolling methods should have the same selectors as
trolled object does not receive the message. the original methods.
Pascoe proposed a heavy solution that consists
in fully duplicating the inheritance hierarchy and to
prefix all the methods destined for minimal objects
3.1 Explicit Subclassing
with an E [Pas86]. Even if such a solution works The interposed class is created by invoking the class
well, it is heavy to set up and uses lots of memory. creation definition method. Moreover, an original
method can be invoked by the controlling method
2.3 Discussion
by use of the super variable.
This approach proposes an instance-based control The newly created class can be inserted using su-
with a global granularity: all the methods are con- perclass: into the class hierarchy, so the subclasses
trolled. Contrary to other approaches that presup- can benefit from the control of the methods. To sup-
pose the knowledge of the messages that should be port a control of all the instances of the class, the

6
reference to the original class in the system dictio- aClass aMethodDictionary
nary class should be changed to refer the subclass. ’Point’ #m1 aCMethod
the original method
aClass aMethodDictionary 3@3
aMethodDictionary
’Point’ #m1 aCMethod a controlling method
#m1
aClass aCMethod
3@3 the original method ’’
aMethodDictionary
2@2 aMethodDictionary
aClass aClass #m1 aCMethod
#m1 aCMethod
’CPoint’ ’’ a controlling method
1@1
a controlling method invoking the original
invoking the original
1@1 4@4 2@2

Figure 3: Explicit subclassing to control message Figure 4: Implicit subclassing using anonymous
passing. The CPoint class defines its own method classes to provide instance-based control message
dictionary containing controlled methods. Thus, passing in VisualWorks.
1@1 and 4@4 are controlled whereas 3@3 and
2@3 are not controlled.
4. Compile in nCl the methods that should be
controlled.
Discussion. The control offered by this approach
is a group-based or class-based control and pos-
sesses a selective granularity. Note that it could be
possible to create as many classes as controlled in-
stances but this would result in a proliferation of ex- VisualWorks Implementation. A possible instal-
plicit classes. lation of the control is illustrated in the following
The control is removed by another class change example method. The line number corresponds to
(see in 1.2). The execution cost is equal to the cost the previous mentioned steps.
of a method execution. The main drawback of this
solution is the creation of an explicit class, so this Object>>specialize
|nCl|
solution is not transparent from the point of view of
(1) nCl := Behavior new
the controlled objects. (2) setInstanceFormat: self class format;
(2) superclass: self class;
3.2 Implicit Subclassing methodDictionary: MethodDictionary new.
(3) self changeClassToThatOf: nCl basicNew
Another solution is to interpose an anonymous class
between the object and its class and to define con- The fourth step is implemented by invoking the
trolling methods local to this specific object as method compile:notifying: of the class Behavior
shown by Fig. 4. with a string representing the controlling method.
The following steps define the control installa-
Such a method source code can be automatically
tion:
generated. In the case of a control implementing
before and after CLOS-like methods, the control-
1. Create an anonymous class, nCl, instance
2 ling method for the method named setX:setY: could
of Behavior in VisualWorks or instance of
look like:
Class in IBM Smalltalk.
anAnonymousClass>>setX: t1 setY: t2
2. Copy the class instance description (format) ... before
from the class to nCl and assign the inheritance super setX: t1 setY: t2
link of nCl to the original class of the object. ... after

3. Change the class of the instance to refer to nCl.

2 According to McAffer, Peter Deutsch mentioned that the

class Behavior had been originally designed to allow such im- IBM Smalltalk Implementation. Joseph Pelrine
plementations [McA95] p. 68. in [Pel96] describes a similar implementation:

7
Object>>specialize anAnonymousClass>>setX: t1 setY: t2
|nCl| ˆ self meta control: #setX:setY:
(1) nCl := Class new call: [super setX: t1 setY: t2]
(2) superclass: self class; withArgs: (Array with: t1 with: t2)
(2) instanceShape: self class instanceShape
(2) instVarNames: self class instVarNames;
setMethodDictionary: MethodDictionary new.
(3) self fixClassTo: class

Integration and semantics of class. A good inte-

gration into the programming environment redefines 3.3 The VisualSmalltalk Solution
locally in the anonymous class the class method.
Without that the control cannot be transparent: a
user could ask for the original class and obtain
Contrary to VisualWorks and IBM Smalltalk, in
the anonymous class. This method can be com-
which each object refers to its class that has a
piled on the anonymous class as shown in the fol-
method dictionary, in VisualSmalltalk, each object
lowing method. Note that an access to the anony-
refers to an array of method dictionaries. Such an
mous class is also compiled. basicCompile: is a
array can be shared amongst all the instances of
method that invokes in a protected manner the com-
a class. Each method dictionary possesses an in-
pile:notifying: method defined in superclasses of
stance variable called class referring to the class to
the original class.
which it belongs as shown in 5. The method dictio-
AnonymousClass>>installEssentialMethods naries are sorted from the class to its superclasses.
self basicCompile: ’class ˆ super class superclass’. This different implementation allows one to control
self basicCompile: ’isControlled ˆ true’. message passing by using the VM method lookup
self basicCompile: ’anonymousClass ˆ super class’ [Bec93b, Bec93a,
aPoint Pel96] as shown in fig. 6.
class anArray aMethodDictionary
x 15
y 10
Invocation of the original method. The original
method could be invoked from within the control-
ling method defined in the anonymous class. An ob- aClass
vious solution is to directly invoke the method using aMethodDictionary aCompiled
the super variable. However such a solution is only name ’Point’ #m1 Method
possible if the control is done by the receiver via the methods
anonymous class implementation and not by another aCompiled
#m2 Method
object like in CodA [McA95] or in FLO [DBFP95].
A possible solution in that case is to define the call Figure 5: Relationship between instances, classes,
to the original method via a block ( [super selector method dictionaries and compiled methods in Vi-
args]) that will be activated later by a value method. sualSmalltalk: 15@10 an instance of Point does
This solution is costly because this kind of block not refer to its class directly. It refers to an array
closure cannot be optimized by the compiler. An- of method dictionaries to which the class Point also
other solution is to refer to the compiled method in- refers to as method dictionary.
stance in the controlling method using the same trick
as in MethodWrapper (see 4.2) and invoke directly
the method (valueWithReceiver:arguments:).
When the control is done by another object (like In VisualSmalltalk controlling a message sent to
a meta-object), the following code can be automat- a specific instance is done by the following steps:
ically generated for the original method with se- (1) creation of a copy of method dictionary array of
lector setX:setY:. Here the meta-object defines a the object, (2) in the first place of this array addition
method control:call:withArgs: that effectively does of a new method dictionary and (3) definition of the
the control. controlling methods in this method dictionary.

8
 aPoint anArray
class aMethod
A
controlled x15 Dictionary
point
y 10 with controlled
methods
aClass
aMethod tional method execution. However, these techniques
anArray Dictionary can only control methods that are known in advance
name ’Point’
to be controlled.
methods aMethod The implementation of these approaches is rela-
aPoint Dictionary
tively simple and adaptable in the various dialects.
class However, an error during the installation can ir-
x 24 A reparably break the system. Indeed method dictio-
normal
y 6 point naries and format of the instances are crucial in-
formation for the VM. Moreover, method compila-
tion is not necessary to install the control because
Figure 6: Instance specialization in VisualSmalltalk:
the controlling methods can be copied and installed
15@10 is controlled whereas 24@6 is not.
from predefined method skeletons (see 4.2). There-
fore these techniques have a good installation speed
and can be applied on deployed applications.
Object>>isSpecialized
Finally, as a last important point, these methods
ˆself methodDictionaryArray
== self class methodDictionaries do not raise the problem of object identity because
the receiver of a controlled message is the object it-
Object>>specialize self (see in 2.2).
self isSpecialized ifTrue:[ˆself].
self addBehavior: MethodDictionary new. 4 Method Substitution
Object>>specialize: aString In Smalltalk, the methods defined in a class are
|assoc| stored in a method dictionary associated with the
self specialize. class. Such a dictionary associates each method se-
assoc := Compiler compile: aString in: self class. lector (a symbol) with an instance of class Com-
self methodDictionaryArray first add: assoc piledMethod as shown in fig. 1.
As shown in figure 7, changing the compiled
The argument aString represents the source of a method associated with a selector supports message
controlling method. passing control. TRACER [BH90] and Method-
Wrappers [Bra96] use this technique. NeoClasstalk
3.4 General Discussion
[Riv97] generalizes it. The original method can be
The technique based on anonymous classes is briefly simply stocked in the method dictionary associated
mentioned in [FJ89], that qualified such classes as with another symbol as in TRACER or it can be en-
lightweight classes, and in CodA [McA95]. McAf- capsulated in the controlling method like in Method-
fer uses this technique to implement meta-objects Wrappers.
and to control message passing. Ernest Micklei pro-
posed a similar approach [Mic96]. However the 4.1 Hidden Methods
meta-class is also controlled and his approach is Another technique to control message passing is
more complex. NeoClasstalk uses this technique to associate a new selector (Xm1 in Fig. 7) with
coupled with a method code change to implement the original method and to associate a controlled
dynamic specialization [Riv97] (see in 4.3). method with the original method selector (m1) in
These approaches support both instance-based the method dictionary. In case of before and after
control and selective control. Note that they can also CLOS-like methods a controlling method could be
support class-based, or group-based control by shar- schematically as:
ing the anonymous class amongst the controlled ob-
jects. Moreover, when all the instances of a given aClass>>setX: t1 setY: t2
class have to share the same control, the method ...before...
allInstances can be used to access to the instances self XsetX: t1 setY: t2
of the original class. ... after....
These approaches are at the same time flexible As compiled methods do not refer explicitly to
and efficient as shown in 5.1. The lookup and ex- their selector, it is not necessary to recompile the
ecution of methods defined by the VM are used methods when they are associated with different se-
at their optimum. As the control is not based on lectors. Moreover, the installation of the controlled
method lookup failure, the cost is only one addi- methods can be done by copying method skeletons

9
 aClass aMethodDictionary the class Point below, the class method on:inClass:
’Point’ the original method returns a wrapped method that can further be in-
#setX:setY:
aCMethod stalled on a compiled method by invoking the
#XsetX:setY:
aCMethod method install.
a controlling method (MethodWrapper on: #color inClass: Point) install
1@1 2@2 invoking the original

Figure 7: Addition of a new selector that refers to

the controlled method and association. aClass aMethodDictionary
’Point’ #m1 aMethodWrapper
mclass
and changing some method information: if we com- clientMethod
sourceCode
pare two controlling methods, the only difference is 1
that they send different selectors to invoke their orig- aCMethod
inal methods. The selector that is used for such an mclass copyEmpty:
1@1 2@2 sourceCode ....
invocation can be easily changed by replacing it in
the method’s literal frame. Therefore, to install a
controlling method from a skeleton one only needs Figure 8: After installation: the original method is
to change the selector, to set up the mclass instance encapsulated into a method wrapper.
variable to refer to the class (see 1.2) and to change
MethodWrapper class also specializes the
the source code to refer to the source code of the
method valueWithReceiver:arguments to intro-
original method.
duce message passing control as follows. Note
that in such a case the control is limited to before
4.2 MethodWrappers and after method executions implemented by helper
method beforeMethod and afterMethod.
The previous solution has the serious drawback of
introducing new selector-method associations in the WrapperMethod>>valueWithReceiver: anObject ar-
method dictionary and to polluting the interface of guments: args
self beforeMethod.
the controlled object class. Although it is unlikely
ˆ [clientMethod valueWithReceiver: object
that a user will invoke a hidden method, this solution arguments: args]
is not good when inspecting the system. Method- valueNowOrOnUnwindDo: [self afterMethod]
Wrappers is a clever approach that does not stock
the original methods in the method dictionary of the A controlling method definition ensures that the
controlled objects class but in the compiled meth- method valueWithReceiver:arguments: is called.
ods themselves [Bra96]. Instead of creating a new The following method source, that is automatically
association selector-compiled method, the original generated, shows how the arguments are managed.
method is substituted by a method that encapsulates
the original one – the wrapper has a reference to the aClass>>originalSelector: t1
original method as shown in Fig. 8. |t2|
(t2 := Array new: 1) at: 1 put: t1.
4.2.1 Definition. ˆ#() valueWithReceiver: self arguments: t2

The following code describes the class Method- When a message is sent to an object, it is neces-
Wrapper subclass of CompiledMethod. The in- sary to invoke certain methods on the method wrap-
per itself (like valueWithReceiver:arguments in
stance variable clientMethod refers to the original
method and selector represents the original methodthe previous code). But Smalltalk does not offer
selector. a pseudo-variable to refer to the current invoked
method. Instead of using the thisContext pseudo-
CompiledMethod variableSub-
class #MethodWrapper variable that costly reifies the method execution con-
instanceVariableNames: ’clientMethod selector’ text, the author of MethodWrappers modifies the lit-
classVariableNames: ’’ erals of the method wrapper. He uses the #() literal
poolDictionaries:’’ object in the previous code to reserve place to put a
category: ’Method Wrappers’ reference during the installation to the method wrap-
per itself. Note that using the self pseudo-variable
As shown by the control of the method color of in the source code of the prototype shown above was

10
not the right solution because self represents the ob-
TraceAllMessages>>generateApplyBodyOn: aStream
ject on which the method was invoked and not the aStream nextPutAll: ’|window|
method itself. window := self transcript.
As in the hidden method approach, MethodWrap- cm printNameOn: window.
pers do not need to be compiled to be installed. The window cr; endEntry.’.
controlling method can be copied from a method super generatedApplyBodyOn: aStream
skeleton having the same number of arguments.
Then, the mclass instance variable, the literal and To control the class Point one should invoke the
the clientMethod should be set. Moreover, to be temporalComposition: method as follows:.
fully and transparently integrated in the Smalltalk
TraceAllMessages new temporalComposition: Point.
environment, the source code of the controlling
method references the source code of controlled one TraceAllMessages new creates an implicit class
as shown in Fig. 8. with method wrappers. temporalComposition:
Point changes the class of the class Point so that
it will be instance of the class TraceAllMessages.
4.3 NeoClasstalk
A part of the Framework. As shown below,
NeoClasstalk is a new implementation of Smalltalk the method applyMethod defined on the class
that introduces explicit meta-classes [Riv97]. Neo- TemporalComposition specifies the definition of
Classtalk allows the definition of class properties the source code of the method execute:receiver:-
such as method trace, instance variable access trace arguments:. A part of this definition is under
and pre- and post- conditions. These properties the responsibility of the method generateApply-
are based on a controlled modification of method BodyOn:. The method applyMethod ensures a se-
source code. It proposes a framework for the com- mantic context of the generated method such as the
position of the different control policies. A meta- insurance that the original method will be invoked
programmer can specify a part of the method source (as shown by the message super execute:... be-
code that will be automatically compiled in the con- low).
trolled methods.
TemporalComposition>>applyMethod
The NeoClasstalk implementation uses similar
”rec is the receiver, args are the arguments
techniques to MethodWrapper (prototype and lit- of the method, cm is the currently reified method”
eral modification) but gives the control to the class.
Moreover, NeoClasstalk uses a dynamic change of |ws|
class based on the definition of anonymous classes ws := (String new: 100) writeStream.
(as shown in 3.2). ws nextPutAll: ’execute: cm receiver: rec argu-
ments: args’;crtab;
nextPutAll: ”system generated method”;cr;crtab.
Control Definition. In NeoClasstalk the execu- self generateBodyOn:ws. ”<-
tion of a method is invoked by the method execute:- the method to override”
receiver:arguments: defined on the class Ab- ˆ ws contents
stractClass. The definition (source code) of
this method is defined by the method generate-
TemporalComposition>>generateApplyBodyOn: aStr
BodyOn: of the class TemporalComposition.
Let us suppose that we want to define a mes- aStr crtab;
sage passing control that realizes a trace of the nextPutAll: ’ˆ super execute: cm receiver: rec ar-
invoked methods. To do so, we define a new guments: args’
class TraceAllMessages (subclass of Temporal-
Composition) and we specialize the method gen- Note that by changing the method generateAp-
erateApplyBodyOn: that controls a part of the plyBodyOn: it is also possible to change the com-
method source code generation of execute:recei- plete semantics of the control.
ver:arguments:. The following code shows the ad-
dition of the textual definition (source code part) of 4.4 Discussion
a trace to the normal method definition. The last line These techniques possess a class-based control and
ensures that the normal behavior of the method will a selective granularity. Indeed all the instances of
be added in this definition. a class are controlled without the ability to select

11
them. The control execution cost is the cost of a Technique entity message integration
method execution. Error han- instance- global average
dling based
The first solution based on the definition of new Explicit group-
selective average
association selector/method in the method dictio- Subclassing based
nary polluted the interface of the objects. This prob- Anonymous instance-
selective good
lem does not appear with the other approaches. Neo- Class based
Classtalk takes in charge the recompilation of the Hidden class-
selective bad
methods and proposes a well defined context for the Methods based
definition and the composition of the method con- Method class-
selective good
trol. However, its solution is complex, and this com- Wrapper based
plexity is not due to the concepts used as the auto- NeoClasstalk class-
class good
based
matic recompilation, but by the framework defini-
tion based on explicit meta-classes3 . Contrary to the The next table compares the different approaches
other approaches the reproduction of the mechanism for the runtime overhead. These tests were per-
is difficult. formed on a Power Mac 7100/166 with 24MB
Finally, contrary to the approach based on iden- memory using Visualworks2.5. The results are the
tity change, the main advantage of message passing mean over five series of 10000 calls with 0,1,2 and
control by means of anonymous classes (see in 3.2) 3 arguments. Moreover, during our numerous tests
or method wrappers (MethodWrappers and Neo- such results show some variability, therefore we
Classtalk) is that the tools defined in the browsers consider that a difference up to 10 milliseconds is
such as (implementors, senders...) continue to fully not really significant.
function.
Technique 0 1 2 3
Explicit Subclass- 40.0 40.0 46.6 39.8
ing
Anonymous Class 40.0 40.2 43.2 43.2
5 Summary and Conclusion Hidden Methods 40.0 43.2 43.2 43.4
Method Wrapper 200 233 243.4 250
Inlined Method 100 126 140 153
Before presenting how other object-oriented lan- Wrapper
guages support message passing control, we sum- Error handling 213.4 229 233.4 240
marize and compare the techniques.
As we can expect, the comparison shows that the
techniques based on the explicit and implicit sub-
classing (anonymous classes) have the same over-
5.1 Overview head. Moreover, these two techniques have the same
overhead than the technique based on hidden meth-
The following table gives a quick overview of the ods. It shows that the lookup of the method via su-
presented techniques in terms of the criteria de- per in the two first approaches is equivalent to the
fined in 1.4. We present here only the main or de- lookup via self in the hidden method approach. This
fault characterics. For a deeper analysis, the reader is not surprising in presence of method cache mech-
should refer to the previous discussions. The en- anisms performed by the Virtual Machine. This
tity column refers to the granularity of the control comparison shows that the technique based on error
that states which entities can be controlled, the mes- handling is five times slower. The method wrapper
sage criteria shows if all or some messages can be approach has the same cost. This situation comes
controlled, the last criteria establishes if the solu- from the fact that method wrappers must create ar-
tion is well integrated in the Smalltalk environment rays for their arguments and that in our tests we
in terms of browser functionality (senders and im- do not remove the call of the valueNowOrOnUn-
plementors) and transparency from the user point of windDo: method.
view. As an experiment, we change the Method
Wrapper’s implementation, the controlling method
continued to call the method valueWithRe-
3 Note that NeoClasstalk proposes tools for selecting class ceiver:arguments: but we remove the call to the
properties that simplifies the life of the lambda programmer. method valueNowOrOnUnwindDo:. The results,

12
named Inlined Method Wrapper are two times faster implies that they cannot be specialized. Moreover,
than the normal Method Wrapper. Moreover, this only the Java VM can create new instances of these
approach could be optimized by inlining in the call classes. Only the value of the instance variables can
inside the controlling method body instead of calling be modified and the methods can be invoked using
the method valueWithReceiver:arguments: de- the handle() method. Such an approach was nec-
fined on the class MethodWrapper. essary to offer tools comparable to the Smalltalk
browsers in Java. However, this reification is not
5.2 Message Passing Control in Other causally connected to the language. There is no pos-
Languages. sibility to modify the methods or the classes from
within the language itself. This means the reflective
CLOS is the object system integrated into Common facilities are not really adapted to extend or modify
Lisp. It is one of the few class based languages to of- the language.
fer the ability to define instance specific methods us-
ing the eql specializer[Kee89]. Moreover CLOS is 5.3 Conclusion
also one of the rare languages to provide a meta ob-
This comparison highlights that the most com-
ject protocol (MOP) in which message passing con-
monly used technique based on the specialization of
trol is an entry point [KdRB91].
the doesNotUnderstand: method is not the best
In CLOS the message passing concept is replaced
4 one. As a first explanation of this situation, one
by the generic function The CLOS MOP allows
should note that the ability to directly execute a
one to control all the aspects of the generic func-
method has only lately been introduced in the inter-
tion application: the application of the generic func-
preters (methods valueWithReceiver:arguments:
tion (compute-discriminatingfunction), the appli-
on CompiledMethod class in VisualWorks and
cation of the effective method (compute-effective-
executeWithReceiver:andArguments: in IBM
method-function) or the application of a single
Smalltalk). Moreover, this comparison shows that
method composing the effective method (compute-
the techniques based on VM lookup method or
method-function).
method wrappers should be considered by more pro-
In the prototype based languages, Moostrap al-
grammers than it is currently the case.
lows a message passing control based on the defi-
The reflective aspects of Smalltalk and their
nition of a reflective protocol: object meta-object is
causal connection to the language itself offer strong
responsible for the method lookup and application
advantages for the language extensions or modifica-
[MC93].
tions 5 . We illustrate them by showing how message
In the realm of less flexible languages, the defi-
passing control is possible by different approaches.
nition of OpenC++ -that can be perceived in its last
This study shows the power offered by languages
version as an open compiler [Chi95] - shows the in-
like CLOS or Smalltalk that provide reflective facil-
terest for a control of message passing. More re-
ities that are not limited to introspective reflection
cently, the definition of MetaJava offers the ability
like in the new version of Java (1.1).
to control message passing in Java [Gol97]. In this
implementation anonymous classes called shadow
classes are interposed between the instance and its Acknowledgments. The author would like to
original class (see in 3.2). However, in the new thank J. Brant, P. Cointe, M. Fornarino, J. McAf-
version called MetaXa, the interpreter is extended fer, E. Micklei, O. Nierstrasz, F. Pachet, J. Pelrine,
by the introduction of new byte-codes. As a direct M. Rieger and F. Rivard.
consequence MetaXa’s applications are no longer
portable. References
Java in its newest version 1.1 reified certain as-
pects of the language such as the classes, the meth- [ABV92] M. Aksit, L. Bergmans, and S. Vural. An object-
oriented language-database integration model: The
ods and the instance variables (see Core Reflection composition-filters approach. In ECOOP’92, LNCS
API [Fla97]). However, this reification is only in- 615, pp 372–395, 1992.
trospective reflection. Indeed, the classes Field, [Bec93a] K. Beck. Instance specific behavior: Digitalk imple-
Method and Constructor are declared as final. This mentation and the deep meaning of it all. Smalltalk
Report, 2(7), May 1993.
4A generic function is a group of methods. During the appli-
cation of a generic function, methods from that group are selected 5 A reflective aspect of a language is said causal if any change

to constitute an effective method application. This is the effective in the reified aspect immediately influences the represented as-
method that is executed. pect and conversely.

13
[Bec93b] K. Beck. Instance specific behavior: How and why. [LG88] W. R. LaLonde and M. V. Gulik. Building a Back-
Smalltalk Report, 2(6), Mar 1993. tracking Facility in Smalltalk Without Kernel Sup-
port. In Proceedings of OOPSLA’88, pp 105–122,
[Bec95] K. Beck. A modest meta proposal. Smalltalk Report,
July/August 1995. 1988.
[MB85] S. L. Messick and K. Beck. Active Variables in
[Ben87] J. K. Bennett. The Design and Implementation of
Smalltalk-80. Cr-85-09, Tektronix, Computer Re-
Distributed Smalltalk. In OOPSLA’87, pp 318–330,
search Lab., 1985.
1987.
[MC93] P. Mulet and P. Cointe. Definition of a reflective ker-
[BH90] H.-D. Böcker and J. Herczeg. What tracers are made
nel for a prototype-based langage. In ISOTAS’93,
of. In OOPSLA/ECOOP’90, pp 89–99, 1990.
LNCS 742, pp 128–144, 1993.
[BI82] A. H. Borning and D. H. Ingalls. Mutiple Inheritance
[McA95] J. McAffer. A Meta-Level Architecture for Prototyp-
in Smalltalk-80. In Proc. of NCAI AAAI, pp 234–
ing Object Systems. PhD thesis, University of Tokyo,
237, 1982.
1995.
[Bra96] J. Brant. Method Wrappers. http://st-www.cs.uiuc.-
[McC87] P. L. McCullough. Transparent Forwarding: First
edu/users/brant/Applications/MethodWrappers.ht-
steps. In OOPSLA’87, pp 331–341, 1987.
ml, 1996.
[Mic96] E. Micklei. Spying messages to objects. Esug Tuto-
[Bri89] J. Briot. Actalk: A Testbed for Classifying and De-
rial, 1996.
signing Actor Languages in the Smalltalk-80 Envi-
ronment. In ECOOP’89, pp 109–129, 1989. [Pas86] G. A. Pascoe. Encapsulators: A new software
paradigm in Smalltalk-80. In OOPSLA’86, pp 341–
[Chi95] S. Chiba. A Metaobject Protocol for C++. In OOP-
346, 1986.
SLA’95, pp 285–299, 1995.
[Pel96] J. Pelrine. Meta-level programming in smalltalk.
[Coi90] P. Cointe. The ClassTalk System: A Labora-
Esug Tutorial, 1996.
tory to Study Reflection in Smalltalk. In OOP-
SLA/ECOOP’90 Workshop on Reflection and Met- [PWG93] F. Pachet, F. Wolinski, and S. Giroux. Spying as an
alevel Architectures, 1990. Object-Oriented Programming Paradigm. In TOOLS
EUROPE’93, pp 109–118, 1993.
[DBFP95] S. Ducasse, M. Blay-Fornarino, and A. Pinna. A
Reflective Model for First Class Dependencies. In [Riv96] F. Rivard. Smalltalk : a Reflective Language. In
OOPSLA’95, pp 265–280, 1995. REFLECTION’96, pp 21–38, 1996.
[Duc97] S. Ducasse. Des techniques de contrôle de l’envoi de [Riv97] F. Rivard. Evolution du comportement des objets
message en smalltalk. L’Objet, 3(4), 1997. Numero dans les langages à classes réflexifs, 1997. Ecole des
Special Smalltalk. Mines de Nantes, Thèse de l’Université de Nantes.
[Fer89] J. Ferber. Computational reflection in class based [Sch96] B. Schaeffer. Smalltalk: Elegance and Efficiency.
object oriented languages. In OOPSLA’89, pp 317– Ecoop Tutorial, 1996.
326, 1989. [YT87] Y. Yokote and M. Tokoro. Experience and Evolution
[FJ89] B. Foote and R. E. Johnson. Reflective facilities in of Concurrent Smalltalk. In OOPSLA’87, pp 406–
Smalltalk-80. In OOPSLA’89, pp 327–336, 1989. 415, 1987.
[Fla97] D. Flanagan. Java in a Nutshell. O’Reilly, 2nd edi-
tion, 1997.
[GGM95] B. Garbinato, R. Guerraoui, and K. Mazouni. Im-
plementation of the GARF replicated objects plate-
form. Distributed Systems Engineering Journal,
Mar. 1995.
[Gol97] M. Golm. Design and Implementation of a Meta Ar-
chitecture for Java. Master’s thesis, IMMD at F.A.
University, Erlangen-Nuernberg, 1997.
[GR89] A. Goldberg and D. Robson. Smalltalk-80: The
Language and its implementation. Addison-Wesley,
1989. ISBN: 0-201-13688-0.
[Hop94] T. Hopkins. Instance-Based Programming in
Smalltalk. Esug Tutorial, 1994.
[IKM+ 97] D. Ingalls, T. Kaehler, J. Maloney, S. Wallace, and
A. Kay. Back to the Future: The Story of Squeak,
A Practical Smalltalk Written in Itself. In OOPSLA
’97, 1997.
[KdRB91] G. Kiczales, J. des Rivieres, and D. G. Bobrow. The
Art of the Metaobject Protocol. MIT Press, 1991.
[Kee89] S. E. Keene. Object-Oriented Programming in
Common-Lisp. Addison-Wesley, 1989.
[Lal90] W. Lalonde. Inside Smalltalk (volume two). Prentice
Hall, 1990.

14