Eliminating superclass lookup in the VM (and dynamic composit ion of behavior)

Withers, Robert rwithers at quallaby.com
Wed Dec 11 18:42:39 UTC 2002


Stephen,

You are familiar with my EventualSending framework
(http://minnow.cc.gatech.edu/squeak/2410) includes a generic message lookup
interceptor, that would allow you to prototype different metaclass
constructions, if you wish.  The only messages that it won't catch are those
that the compiler inlines as bytecodes, like #==, if you recompile the vm
for redirector support.

You can subclass RedirectorContext, like in my BehavioralRedirectorContext
(which binds a Mixin Behavior instance).  lookup control is activated in the
method #redirectMessage:.  You can build a Redirected object reference with

	RedirectorContext on: anObject.

you can define a Mixin class
	RedirectorMixin newNamed: 'ProxyMixin'.
then compile methods into the mixin with
	ProxyMixin compile: methodString.
and create one with:
	(ProxyMixin proxyOn: Processor) inspect.

it is useful for exploring differents schemes.  I believe there was a
changeset out there for squeak where someone investigated the different
lookup schemes.  I don't have a link to it.

food for the mill,
rob

> -----Original Message-----
> From: Stephen Pair [mailto:spair at acm.org]
> Sent: Wednesday, December 11, 2002 1:30 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Eliminating superclass lookup in the VM (and dynamic
> composition of behavior)
> 
> 
> I guess what I'm really after is the ability to have more control over
> the manner in which behavior is composed.  So far, the best 
> platform for
> doing that seems to be Self.  However, even in Self, I think 
> the message
> binding algorithm is fixed.  It would be nice to be able to 
> override the
> default message binding algorithm that the VM employs.
> 
> - Stephen
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org 
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> > Behalf Of tblanchard at mac.com
> > Sent: Wednesday, December 11, 2002 1:14 PM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: Re: Eliminating superclass lookup in the VM (and 
> > dynamic composition of behavior)
> > 
> > 
> > I found myself sitting next to Ira Forman at an OOPSLA workshop in 
> > 1995.  At the time he was one of the main designers of IBM's SOM 
> > library.  It was something like his  3rd year presenting SOM. 
> >  We were 
> > talking about how he handles multiple inheritance and he said his 
> > solution was to basically copy the dispatch table (method 
> dict if you 
> > like) into each class.
> > 
> > Partly because SOM allowed you to attach before, after, and around 
> > methods to arbitrary locations in the class hierarchy and the 
> > bookkeeping got too hairy if the point of dispatch was 
> > somewhere other 
> > than the attachment class.
> > 
> > So I have heard of it being done.  Sounds like the classic 
> > size v speed 
> > tradeoff.  I'm a bit worried that the size of the image 
> will explode.
> > 
> > On Wednesday, December 11, 2002, at 04:40  PM, Stephen Pair wrote:
> > 
> > > I've been messing with the idea of traits recently (I 
> need them for 
> > > adding transactional behavior to arbitrary classes in the 
> > system).  To 
> > > satisfy my immediates needs, I've built a "mini-traits" 
> > capability (to 
> > > hold me over until Andrew and Nathanael gets their stuff out).  
> > > Anyway, I've found myself managing the visibility of trait 
> > methods in 
> > > my Smalltalk code.
> > >
> > > While doing this, a thought has occurred to me: does it even make 
> > > sense to have the VM traverse a superclass chain when 
> looking for a 
> > > method? Why not just have the VM just look at the single method 
> > > dictionary directly attached to a behavior and manage the 
> > visibility, 
> > > etc of methods in Smalltalk?  Primitive method 
> dictionaries (those 
> > > designed for consumption by the VM) would be nothing more than 
> > > flattened views of the
> > > methods that are applicable to a given class.  Methods that access
> > > instance variables should be the only ones that might need 
> > a physically
> > > different compiled form.  This would also have a side benefit of
> > > allowing subclasses to have a different instance variable 
> orderings 
> > > than
> > > their superclasses...which in turn might facilitate more 
> > creative ways
> > > of composing behavior.
> > >
> > > I mean heck; we even have places in the Smalltalk code 
> > where we have 
> > > to flush the VM method cache...these places would be 
> > exactly where we 
> > > would want to reconstruct the primitive method dictionaries.
> > >
> > > I've found that I'm managing the visibility of trait methods by 
> > > controlling what happens when adding an removing methods, 
> etc.  It 
> > > occurred to me that if I can do this with relative ease 
> > with traits, 
> > > why not do it with normal inheritance?
> > >
> > > Has this been done before?
> > >
> > > - Stephen
> > >
> > >
> > 
> > 
> > 
> 
> 



More information about the Squeak-dev mailing list