Inlining heuristic trouble

[Rémi Forax]

On 06/20/2011 10:11 PM, Mark Roos wrote:
> Not that I am the expert here but...
>
> In the Smalltalk we are porting the typical call site supports only a 
> few actual classes.  So the method look up ( which is based on the 
> object class )
> only chooses from a small set ( mostly a single choice).  This set is 
> built up during run time by watching the classes which appear at the 
> site.
>
> So the basic operation is
>         test if the class coming in is one we have seen before
>                 if yes then jump to the method
>                 if not then do a lookup and compile of the new method 
> ( this is the slow path)
>                 put this into the local method cache by placing a new 
> GWT at the front of the chain
>                 execute the new method.
>
> Since there is only a few choices the guard with test is a very quick 
> way to test the class ( fast path )
> We end up with a chain of tests which ripple through the known classes 
> and then end with the real slow lookup of the new class.
> For a small amount of classes to check this is fast in 8086 code.
>
> So we do not have a path that can be assumed to be not taken (except 
> the last in the chain).

Sorry Mark and Tom, I should have been more clear.
The idea is to artificially put a "never seen" flag in front of the 
*last* fallback
in the GWT chain.

>
> Perhaps in the JVM this is a poor choice for implementation of a small 
> polymorphic inline cache.  Here I defer to the real experts
>
> regards
>  mark

cheers,
Rémi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110621/359a246f/attachment-0001.html