Request for review (S): 7042122: JSR 292: adjust various inline thresholds for JSR 292 API methods and method handle adapters
tom.rodriguez at oracle.com
Thu May 5 12:58:12 PDT 2011
On May 5, 2011, at 12: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?
Adding factors onto existing knobs seems dubious to me. Iit would be fine transitionally but it's almost impossible to reason about since it applies so broadly. I think the broadness also may limit it's effectiveness since the more you turn it up the more likely you will bad effects as well as good effects.
>> 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 think as a short term fix Christians change is fine, particularly since it's apparently the result of some actual testing. But it was done based on tweaking existing knobs because that's all there is. I'd rather see some more directed thinking about how this should work in the next release.
> -- John
More information about the hotspot-compiler-dev