Boxing, still a limit of invokedynamic?

[Jochen Theodorou]

Am 14.05.2012 17:19, schrieb 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.

This fall? Ahem... ideally it would have been out already by now ;) If 
possible 1 month only is left.... that is late enough

> 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.

that might be, but I find some quite basic things that I really wonder 
if they are not really of relevance for your cases. The boxing issues I 
can understand, but that performance drops so drastically (it halves) 
once you use a catch guard is something I find strange... you are not 
using that one?

> 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.

Yes the question is only if they are as eager on supporting my stuff. 
Nothing against John and all the other Hotspot guys, really, but their 
time is at least as limited as mine.

[...]
> 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 :)

well, if you offer to help, I take you by your word ;)

> 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.

yes, that is my approach as well, but you can see on the feedback on my 
catch exception guard problem, that this doesn't mean I will ever get to 
a fix in the JVM. It may happen or not... depending on the available 
time slots. Or maybe I should rant more ? ;)

bye Jochen

-- 
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org