Inlining heuristic trouble

[Rémi Forax]

On 06/17/2011 11:50 AM, Christian Thalinger wrote:

[...]

>> I wonder if I haven't introduce a bug in my logic,
>> there is a the boxing/unboxing of the return value of the test that
>> should not occur.
>> Question, does EA is also disable when MH.invokeExact is called  ?
> Yes, as MH.invokeExact is a native method:
>
> [EA] computing results for java/lang/invoke/MethodHandle.invokeExact
> Skipping method because: method is native.
>
> There needs to be special machinery to handle that case.
>
>>   @ 34   java.lang.Boolean::valueOf (14 bytes)   inline (hot)
>>   @ 43   java.lang.invoke.MethodHandle::invokeExact (26 bytes)   inline (hot)
>>     @ 11   java.lang.Boolean::booleanValue (5 bytes)   inline (hot)
>>
>>
>> I will check my code.
>>
>>> Hmm.  I'm a little curious about how fallbackOpLeft becomes the fallback path.  Usually this is/was done with a guardWithTest.  Is selectAlternative doing this?
>> isSelectAlternative is the internal method called when you create a
>> guardWithTest
>> with ricochet frame enabled.
> I see.
>
>>> I think what's happening here is, we propagate the call site count from the hIot MH call site to all its callees through the MH chain and since fallbackOpLeft is in there it gets the same call site count making it hot, while actually it isn't.
>> Yes, one solution is to always set the fallback as cold.
>> A better solution is to record the usage of each branch when interpreted.
> We do that.  I'm just not sure how to get to that information from the method handle compiler.

Sorry, I was thinking recording which branch of the GWT is taken and 
storing them in the GWT.
Two GWTs should not share the same metadata.
> -- Christian

Rémi