Inlining heuristic trouble

[Charles Oliver Nutter]

On Mon, Jun 20, 2011 at 3:11 PM, Mark Roos <mroos at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110620/29980a4b/attachment.html