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

[Christian Thalinger]

On May 6, 2011, at 5:48 PM, Vladimir Kozlov wrote:
> I don't see changing inline sizes for 292 methods. Do you not need it anymore?

No, with that change it's not required anymore, which is good.


> Also question, how many call sites mh adapter has? I thought adapter has only one call site. Then why generate MDO only to propagate counter for one call site?

I has only one call site to the target, right, but I can have additional invokes to helpers, e.g.:

0 aload_3
1 checkcast 3 <java/lang/Integer>
  0   bci: 1    ReceiverTypeData    count(82944) entries(0)
4 astore_3
5 aload_3
6 checkcast 4 <java/lang/Integer>
  24  bci: 6    ReceiverTypeData    count(82944) entries(0)
9 astore_3
10 aload_3
11 invokevirtual 9 <java/lang/Integer.intValue()I> 
  48  bci: 11   VirtualCallData     count(82944) entries(0)
14 istore #4
16 aload_2
17 checkcast 10 <java/lang/Integer>
  72  bci: 17   ReceiverTypeData    count(82944) entries(0)
20 astore_2
21 aload_2
22 checkcast 11 <java/lang/Integer>
  96  bci: 22   ReceiverTypeData    count(82944) entries(0)
25 astore_2
26 aload_2
27 invokevirtual 16 <java/lang/Integer.intValue()I> 
  120 bci: 27   VirtualCallData     count(82944) entries(0)
30 istore #5
32 aload_1
33 iload #5
35 iload #4
37 invokespecial 21 <java/lang/invoke/MethodHandle.invokeExact(II)I> 
  144 bci: 37   CounterData         count(82944)
40 ireturn

I want them all to be inlined.

-- Christian

> 
> Vladimir
> 
> On 5/6/11 6:49 AM, Christian Thalinger wrote:
>> On May 5, 2011, at 10:29 PM, Tom Rodriguez wrote:
>>>>> 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.
>>> 
>>> I do have one concrete thought about this but it would require some investigation.  The method handle chains themselves aren't profiled but presumably the base call site is.  Maybe we should be looking back through method handle calls to find the frequency of the base call site and feeding that into the frequent call site logic.
>> 
>> Yeah, I suppose that's how it should work.  What about this?
>> 
>> http://cr.openjdk.java.net/~twisti/7042122/
>> 
>> I get the same performance but without any tweaking of any inline thresholds.
>> 
>> -- Christian