[self-interest] Re: compressing the code cache

[Jecel Assumpcao Jr]

On Saturday 02 February 2002 12:53, Mario Wolczko wrote:
> I tried to make the NIC not customize, and got most  of the way
> there, however, it   was still too  unreliable to  turn on  by 
> default. 

Too bad!

> The option is called  _ReuseNICMethods.  The only benefit
> of customization in the  current NIC is that  accessess to slots  in 
> self are inlined.

And with the new "local slot access" bytecodes in Self 4.1 only the 
"instance variables" still benefit from this.

> Surprisingly this doesn't buy very much performance
>  (most of the time is spent  running SIC code),  but customization
> costs  a great deal of memory, especially when running the ui.

Here is a very good paper about this:

 The Space Overhead of Customization (Technical Report) 
   by Sylvia Dieckmann and Urs Hölzle
   http://www.cs.ucsb.edu/oocsb/papers/TRCS97-21.html

> If you look at the SIC code, you really do want it to customize,
> because this enables a whole bunch of optimization opportunities that
> otherwise wouldn't be present (inlnining all sends to self).

But some of the methods with the most customized copies are then ones 
in which they are all exactly alike.

Here is an idea that I just had to filter out useless customization (it 
probably has lots of flaws...):

When the NIC first generates code for a given source method, all the 
call sites are initialized with inline caches instead of PICs. What if 
the second time the NIC had to generate code for the same source method 
(different receiver "type") we just made a link to the same code? This 
code would be shared until any one of the ICs misses. Then we copy the 
code, set its IC to the new value and let each customized version go on 
its own path from now on.

The SIC could check this sharing as a hint that it might not want to 
customize a given method. Obviously, any method that has aquired one or 
more PICs must be customized.

This still generates some identical copies, but at least it doesn't 
need more checking than we already have.

-- Jecel