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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
