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

Stephen Pair spair at acm.org
Wed Dec 11 16:26:16 UTC 2002


One issue with it would be super sends.  But, I think you could come up
with a reasonable way of handling that.

On the space efficiency side, you'd be sharing most of the compiled
methods, but yeah, you would lose a little, though I suspect that in the
grand scheme of things it wouldn't much matter.

However, in the even grander scheme of things...this means that a
superclass must know about its subclasses...which is not so bad in the
case of Smalltalk.  But, in the context of Self...would be quite
horrible.  You could always brute force your way through the entire
object memory, but that wouldn't perform very well and would limit the
situations in which you would consider dynamically altering behavior.
Sometimes I really wish Squeak was running on top of a VM that had the
capabilities of Self.

- Stephen

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Andreas Raab
> Sent: Wednesday, December 11, 2002 10:55 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: RE: Eliminating superclass lookup in the VM (and 
> dynamic composition of behavior)
> 
> 
> Stephen,
> 
> Now there's an interesting idea! I think this should work 
> pretty nicely if every class can handle #doesNotUnderstand: 
> appropriately (I believe that's the only critical message 
> here). You could try an experiment along the lines of 
> disabling superclass lookup for all but DNU and see what happens ;-)
> 
> Efficiency-wise I would guess that you will be spending quite 
> a number of bytes on the method dictionaries of the classes 
> since you'd have everything from Object/Morph in each of the 
> leaf classes. But other than that I don't see anything problematic.
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: squeak-dev-admin at lists.squeakfoundation.org
> > [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> > Behalf Of Stephen Pair
> > Sent: Wednesday, December 11, 2002 4:41 PM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: Eliminating superclass lookup in the VM (and dynamic 
> > composition of behavior)
> > 
> > 
> > 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