dependency info

[Jecel Mattos de Assumpcao Jr.]

On Wed, 27 Sep 1995 16:53:00 -0700
chambers at cs.washington.edu (Craig Chambers) wrote:
> Jecel writes:
> > 
> > [ depend on all parents, not just those for which lookup succeeds ]
> > 
> > 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.

Let's take a quick look at the sources in Self 3.0 ( 4.0 is divided into
subdirectories, so this would be harder ):

How many lines use true?

           grep true * | wc -l
           858

Of these, about how many are not slot initializations?

           grep true * | grep  -cv =
           388

Wow! There sure are a lot of methods that refer to true!!
We should get the same thing for false:

           grep false * | grep -cv =
           371

That means over 700 methods will be invalidated on any change to
any prototype! Of course, it would be easy to fix this particular
problem by moving true and false to the lobby itself.

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

In Self 2.0 "normal" parents had lower priorities than parents that
existed just to split the methods into categories. Didn't that reduce
the problem a little ( if you find a slot in a parent, you shouldn't
depend on any lower priority parent, right? )?

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

That *is* a nasty problem. But I got myself a public domain GC for C
and it is holding up fine so far ( see ftp://ftp.parc.xerox.com/pub/gc/gc.html
for details, though I guess it is well known to the people in this list ).
This is just a way for me not worry about these things right now, as
I will be redoing the GC shortly anyway. Then I'll be able to write
the Self compiler in Self... I hope...

-- Jecel