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 _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
