Re: dependency info

["Jecel Mattos de Assumpcao Jr." <jecel@lsi.usp.br>]

On Tue, 26 Sep 1995 15:01:51 -0700
chambers@cs.washington.edu (Craig Chambers) wrote:
> Self's dependency mechanism inspired some of our work in our ICSE'95 paper
> on selective recompilation mechanisms.

Great stuff! I found the idea of "no-more-methods" very interesting - I had
not noticed it while browsing through the Self VM sources. I look forward
to seeing if I can apply your ideas to other cacheing contexts, like
the user interface.

> One thing we tried to do was to
> solve the problem with Self's dependencies, where if you add a new slot to
> an object (e.g. define a new method or a new prototype), every lookup that
> traversed that object went out of date.  Since prototypes are (used to be?) 
> in the global name space, adding a new prototype ended up recompiling virtually
> all compiled methods.  And there was a substantial space cost for the fine-
> grained dependencies.

This wasn't at all obvious for me, as not that many methods refer to
global things ( like "l: list copy", for example ). It took me a long
time to see that a method is dependent not only on the parents through
which lookups succeeded, but even more on the parents for which they
failed! That is because a slot with the same name might be added to
them later.

I would expect this to be much less of a problem now that method
categories are done with annotations rather than with multiple
inheritance - many objects now have but a single parent.

> We introduced dependencies on method lookup results, and rechecked the method
> lookup whenever a source change made the lookup potentially out of date (like
> adding a method or prototype).  This "second chance" check made a big difference
> in squashing unnecessary recompilation after adds, inheritance graph changes,
> and the like.  We also described a generalization of this caching idea in
> the ICSE paper.

Maybe this lookup cached could be shared with an interpreter? Also,
lookup currently takes up 30% of Self's simple inlining compiler's
time.

> [.... stuff deleted ...]
> 
> The idea of using 32 classes of objects to save space is interesting.  To
> think this through, I'd suggest enumerating the different kinds of changes
> that are typically made during programming, and see how selective the 
> invalidations will become.  It seems that adding a new prototype or global
> would still be very expensive under this scheme.

We are moving in opposite directions here. You are looking for a more
selective system then what Self uses. I am asking if we couldn't get
by with an even worse system.

-- Jecel