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

[Tom Rodriguez]

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