On Mon, Jun 20, 2011 at 3:11 PM, Mark Roos <mr...@roos.com> wrote:
> 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).
>
This is the same for JRuby. My assumption has been that the inlined version
of that chain of GWT would look like this to the JVM:
if (test1()) { target1(); }
else if (test2()) { target2(); }
else if (test3()) { target3(); }
else { fallback(); }
...and as a result the inlining heuristics would behave the same as if we'd
written the above in Java by hand. Interesting to note: currently, the first
cached result ends up further down the list. In other words, it's a PIC that
does not rebalance based on frequency. A PIC that rebalances might work
better in a heuristic where more weight is placed on the success paths.
Am I assuming too much?
- Charlie
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
