[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dependency info
On Tue, 26 Sep 1995 15:01:51 -0700
firstname.lastname@example.org (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
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
> [.... 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.