> My PICs only have three entries. My current plan is to defer that
> problem until we've got real application benchmarks suffering because
> of it. ;-)

Sure this is the best strategy. I was just curious and I noticed that a 
lot of
methodes are not that polymorphic in fact.

> But megamorphic methods are not that common, printOn: will
> only be megamorphic if a lot of classes are all being called from the
> same message, chances are most calls of printOn: will only see a
> few receivers.

ok yes I see so indeed this cuts a lot of potential.

> However there are a few options that I've thought about.
>
> One is to recompile the method with a larger PIC. The plan is for
> Exupery to be driven by dynamic feedback to automatically
> compile the hotspots. This is one reason why I've used a slow
> algorithm for register allocation that generates good code.

So if I'm correct in all this strategy the game is to see if the 
feedback
and the recompilation is worth the extra tests needed at run-time when
the method is "normally" executed.

> Another is to move the type tests into compiled code. So the PIC is
> just used to find new senders. If they are called a lot then they
> could be slowly inlined into the calling method which means they will
> no longer be in the PIC.
>
> Another is to replace the PIC with a local hash lookup. Choose a
> better data structure for dealing with large numbers of receivers. A
> PIC is just a sequence of dynamicly generated "if class = x then jump
> to y" instructions. This is not a great structure for large numbers of
> receivers.
>
> Another option is just to ignore them. If the PIC fails then I will
> use the interpreters lookup which already uses a hash table. It might
> be sensible to disable PICs for frequently called megamorphic calls
> so it doesn't flush the code cache.

ok I see.

> Without knowing how the megamorphic call fits into the surrounding
> code it's hard to say which solution will work best.

Yes I was always amazed by the papers :).

> Once Exupery is being used seriously then instrumentation should help 
> make this
> decision. Instrumentation first to design a set of solutions then to
> dynamically choose between them.
>
> The problem of a megamorphic send is really the same as the problem
> of generating code for a large case statement. Which means a quick
> literature search should find a lot more options.