Re: dependency info

[chambers@cs.washington.edu (Craig Chambers)]

I wrote:

> > 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.

Jecel writes:
> 
> 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.

Remember that "true" and "false" are messages to self that search the global
name space to find the true and false objects.  So any method that uses these
"constants" introduces lots of dependencies on all the objects that are 
traversed while looking for true.  In the presence of optimization, most 
compiled methods will inline some method that mentions true or false, so most
compiled methods end up being linked to the roots of the inheritance hierarchy.

But my experience was with Self 2.0.  The current Self (4.0? 5.0?) may have
different empirical properties, due to changes in how name spaces are
organized.

> 
> > 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.

Yes, this dependency cache is used by our compiler's compile-time method 
lookup optimization; Self could be organized similarly.  (In the old so-called
"new" Self-91 compiler, there was such a cache, but it was used only during
the compilation of a single method, due to difficulties in GC of the Self
runtime system's data structures and the like.  Because our compiler is 
implemented in Cecil, a GC'd language, rather than C++, we don't have this
limitation :-).

-- Craig Chambers