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

tblanchard at mac.com tblanchard at mac.com
Wed Dec 11 18:14:16 UTC 2002


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