Boxing, still a limit of invokedynamic?

[Charles Oliver Nutter]

On Mon, May 14, 2012 at 4:32 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:
> That it is slower at first is ok. Only I kind of assumed, that such
> things can be optimized away. The less the JIT can optimize, the more I
> have to do that and work around the limitations, making my runtime more
> complex. And with the next JVM update all that work might be for nothing.

This is a key point you will have to weigh.

You want to have Groovy 2.0 released by this fall, with invokedynamic
support. It's certainly possible that your uses of invokedynamic have
not gotten the optimization love they need, and that your results
won't be to your liking until that happens. Getting JRuby +
invokedynamic to work well was the product of several months of
back-and-forth between me and the Hotspot guys, tossing assembly dumps
around, tweaking inlining budgets, trying out new optimization
strategies. The initial performance was terrible, but we all
persevered and I continued to wire things up and play with handles.
Ultimately we (well, mostly the Hotspot guys) worked out all (well,
almost all) of the performance issues I saw; that would not have
happened without a lot of back-and-forth.

Even though indy isn't "perfect" yet, we're comfortable putting out a
JRuby 1.7 release in the next couple months that has invokedynamic
support...because it's looking pretty good now, I know that there's
more improvements coming, and I'm working to help find those perf
opportunities every day.

I *strongly* urge you to dig deeper than running benchmarks while
investigating this. It sounds like you may be looking at inlining
results, but don't trust that either (inlining might happen early on
and then get thrown away). Look into the assembly code to see the
actual work being done for your indy calls. If it's a lot more than
you get with your old logic, there's an opportunity to improve.

And when you get to that point and can't figure out why the assembly
for your indy stuff is more complicated than the assembly for the
non-indy logic, we can help you decide if it's a JVM issue or a Groovy
issue :)

My attitude has been this:

1. I assume invokedynamic should be fast.
2. If it's not, either I'm doing something wrong or the JVM's doing
something wrong.
3. We figure out which one it is and fix it.

- Charlie