On Mon, Feb 21, 2011 at 10:08 AM, Christian Thalinger <christian.thalin...@oracle.com> wrote: > On Feb 21, 2011, at 4:43 PM, Christian Thalinger wrote: >> I fixed that but it didn't change performance. I just tried bench_tak and >> there is still a regression. I will look at that next.
I'll spew some nonsense here and you tell me what I've got right and what I've got wrong. Hotspot weights recursive calls differently than non-recursive calls. I assume it treats non-recursive calls with priority, so that rather than inlining N levels of a method calling itself, it prefers to inline logic *around* the recursion that's likely doing the actual work of the method. Without such weighting, we'd end up with a giant method inlined into itself many times...but none of the work it actually does inlined. Correct? The fib recursive call is not treated as a recursive call when invoked via indy because although it is logically a recursive call, it has intervening frames for the MH logic. As a result it gets weighted the same as a regular call, and so too many recursive calls get inlined before other stuff gets inlined at each level. This causes a degradation since the actual work of fib is in the *other* calls it makes, and they're all CALL ops with no inlined optimizations anymore. We do *want* fib to inline into itself, but only if it's appropriate and only after other "leaf" calls inline and optimize first. Your fix teaches hotspot that an indy recursive call should be treated as a recursive call, putting it back in its place. I'm confused about the additional fix though. I assume the method gets too big with MaxRecursiveInlineLevel=1 because the method handle logic is also getting inlined and consuming the inlining budgets? And as a result, we're still pushing other important calls out of the inlining family, and performance degrades. It looks like you have a handle on things! I also eagerly await continued improvements, especially the logic to discount MH code from inlining budgets. It seems like that will be crucial for indy to compete with dynopt, since dynopt still performs quite a bit better but emits far too much bytecode right now. Another clarification for me: you are working against the main Hotspot repository now, yes? When and how can I get the fixes you've outlined? I will continue adding more invokedynamic paths and reporting how they behave. The improved timing for tak looks great, and with inlining tweaks I'm sure we can get indy-based fib and tak as fast or nearly as fast as jruby dynopt mode. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
