Projects, which use JSR292

[Charles Oliver Nutter]

On Mon, Feb 21, 2011 at 10:08 AM, Christian Thalinger
<christian.thalinger at 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