[self-interest] resend (was: Multiple inheritance)

Jecel Assumpcao Jr jecel at merlintec.com
Mon Nov 7 18:52:24 UTC 2005


"J. Baltasar Garcia Perez-Schofield" wrote:
> >  That
> > means that any copy slots in "parent", "sharedStuff" and "moreStuff"
> > will be found and if there is more than one then a debugger will pop up.
> 
> 	That's the point.
> 	But I suppose that this means that at runtime time, each time a
> resend/"unqualified" message is sent, and more than one parent is found
> for the receiver (and provided the receiver can't satisfy the message),
> then all inheritance paths are explored in order to avoid the
> possibility of finding more than one receiver (and show the debugger if
> found).

Correct except for the "provided the receiver can't satisfy the message"
send the whole point of the resend is to skip any slots that the
receiver might have with that name.

> 	This can't be limited to the first time because Self is dynamic, the
> inheritance paths can change after a message is carried out due dynamic
> inheritance. So Self has to do it every time, and I guess this is quite
> expensive.
> 	Or maybe I am missing something ?

Michael Latta mentioned PICs and maps and other  virtual machine tricks,
but I suppose that is what you mean by "the first time". Note that in my
example all three parents were constant slots. And probably their
parents too and so on. In such cases you can be sure that nothing will
change between the first and second times.

If one of the parents had an associated assignment slot then you would
be correct: a lookup would have to be repeated on each message send. But
in practice such dynamic inheritance is rarely used. I actually came up
with a way to greatly speed up this situation but it didn't seem worth
the effort. And I eliminated this feature entirely from my own Neo
Smalltalk design.

> 	The depth search is maybe problematic in some sceneries, but is
> obviously better in the best case (the receiver is found in the first
> inheritance path) and in the average case, though equal in the worst
> case.

You should first find out how much run time is being "wasted" on look up
before trying to make it faster. On page 18 of Urs Hölzle's thesis we
have that the cost of a inline cache miss is 250 clocks and the cost of
a hit is 9 clocks. The miss rate was from 0.62% to 6.66% in the
benchmark programs. So making lookup twice as fast would speed up sends
by 8 to 50% (supposing the whole 250 clocks is look up, which isn't
true).
 
> > Some people prefer a depth first search but that has a nasty side effect
> > that just changing the order of "sharedStuff" and "moreStuff" in the
> > above code could change its meaning!
> 
> 	Absolutely.
> 	However, is it likely to happen ?. I mean, if a programmer knows that
> order of parents in the parent list (whatever syntax you choose) has a
> meaning, would that programmer change the order of parents without
> noticing ?

As Self currently is this would be very likely since you add the slots
graphically and they are shown in alphabetical order. But for some
scripting language this might be an interesting option. In early
versions of Self/R I did have a depth first search exactly as you
suggest but around the time I changed the name to Neo Smalltalk I
decided to get rid of parents entirely and make the programmers manually
order the "facets" which make up an object. The "tie breaker rule"
problems in early Self have made me avoid automatic solutions as much as
possible.

-- Jecel



More information about the Self-interest mailing list