Request for review (S): 7042122: JSR 292: adjust various inline thresholds for JSR 292 API methods and method handle adapters

[Charles Oliver Nutter]

FWIW I hope to be able to spend more time on JRuby perf analysis with larger benchmarks and more asm inspection this coming week, in prep for turning Indy on full-time soon. If there are other flags I should try playing with other than MaxInlineSize and InlineSmallCode I'd be happy to iterate over them to provide more empirical data.

With the tweaks Christian suggested, more and more code is running faster under indy than using our existing IC, which is great. I need to add code to JRuby for other forms of Ruby invocations to get a more holistic picture, but I'm very pleased with the results so far.

- Charlie (mobile)

On May 5, 2011, at 15:00, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:

> 
> On May 5, 2011, at 12:53 PM, Christian Thalinger wrote:
> 
>> On May 5, 2011, at 9:35 PM, John Rose wrote:
>>> On May 5, 2011, at 12:11 PM, Tom Rodriguez wrote:
>>> 
>>>> I'm not sure we want to enshrine these just yet, do we?
>>> 
>>> We know we want more aggressive inlining along deep linear MH chains.  (They don't look like bytecodes.)  But we need a knob to tune.  I think we should have at least one non-specific number like -XX:MethodHandleInlineFactor=50 .  Or is there a better way to do it?
>>> 
>>>> These settings will affect all code that's in java/lang/invoke, not just method handle call chains.  I would expect that some policy that takes into account the calling chain would do better than just tweaking the inline size and small code values.
>>> 
>>> You are right, and a better policy would want to take into account named factors such as the above, for tuning experiments.
>>> 
>>> Christian, would your change work if the inlining changes were restricted to calls nested within a MH.invoke*?  That would probably address the issue Tom raised about effects on code in j/l/i other than MH call chains.
>> 
>> I guess that would work.  I will check on that tomorrow.
>> 
>> The reason I came up with something like band-aid fix is because I didn't have enough time to do something more sophisticated and we need something that works in Java 7.  JRuby wants to enable invokedynamic by default for the current development version as soon as we have heuristic that makes out-of-the-box performance good enough (reads: equally or better than non-indy).
>> 
>> Tom, do you have a better idea how we could handle that?
> 
> Given where we are I thought your patch was a fine band aid.  I was just a bit leery of adding a real exposed flag before we've really had a chance to make a policy.  If we're fine with potentially abandoning that flag later then I'm fine with adding it.
> 
> tom
> 
>> 
>> -- Christian
>