Inlining heuristic trouble
forax at univ-mlv.fr
Tue Jun 21 00:31:13 PDT 2011
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
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev