PICs and customization

[Jecel Assumpcao Jr]

On Monday 11 February 2002 14:55, Mario Wolczko wrote:
> When first generated, all call sites call the inline-cache-miss code;
> a transition to a PIC takes place only when after this code has been
> replaced with an inline cache, and then _that_ has missed.

Exactly.

> > [customization on IC to PIC transition]
>
> That sounds quite plausible to me.  It's an alternative to the
> implementation I was pursuing, which never customizes NIC code, but
> uses PICs within NIC methods.

A combination of the two ideas would probably be best. I was trying to 
handle the (adapted) example in Craig Chamber's ECOOP'95 paper ("The 
Cartesian Product Algorithm: Simple and Precise Type Inference Of 
Parametric Polymorphism"):

  max: a = ( a<self ifTrue: [self] False: [a] ).

If this is compiled for both SmallIntegers and Floats, we will note 
that "a" is also a SmallInteger or Float. If we don't customize this we 
will have to have PICs for both "self" and "a" and will generate 
complicated code, never noticing that only two of the possible self x a 
type combinations ever actually happen.

With my idea, we might first compile this for SmallIntegers and then 
try to share it with Floats. But this will cause the IC for "<" to miss 
so we create a new customized version for Floats.

The problem is that my scheme is too eager to customize. Imagine that 
we have native code A1 which calls B1 which calls C1. Now suppose that 
an IC miss in C1 causes us to create a new native code C2. In my 
proposal that would make us create a new B2 to call this C2 and a new 
A2 to call that. If we could have PICs in non customized code, then B1 
could be changed to call both C1 and C2 and non of its callers would be 
affected.

Of course, no solution is right for every situation. We need a 
heuristic that does a good job on average without any additional 
runtime tests beyond what we already have.

-- Jecel