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

[Vladimir Kozlov]

OK, then it makes sense to have MDO. An other thing. You actually don't need 
real MDO. Do you? As I understand you need MDO only during compilation then you 
should use CURRENT_ENV->get_empty_methodData() in ciMethodHandle::get_adapter()
to set call counters and assign it to created ciMethod._method_data.

Vladimir

Christian Thalinger wrote:
> 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
> 
>