[9, 8u40] RFR (XS): 8065985: Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D

[Hannes Wallnoefer]

+1

Thanks for looking into this!

Hannes

Am 2014-11-26 um 11:44 schrieb Vladimir Ivanov:
> http://cr.openjdk.java.net/~vlivanov/8065985/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8065985
>
> Inlining failure of Number.doubleValue() for Double case in 
> JSType.toNumeric() costs ~15% peak performance on some of the Octane 
> benchmarks (e.g. Box2D).
>
> Current inlining heuristics in HotSpot aren't stable enough for this 
> particular case. Depending on the execution sequence and gathered 
> profile data, Number.doubleValue() can be devirtualized to 
> Double.doubleValue() or emitted as a pure virtual call.
>
> The problem is that Number.doubleValue() is a polymorphic call site. 
> Most of the time it has Double receiver, but sometimes it's Integer 
> and (very) rarely something else.
>
> Most of the time, Double case matches major receiver heuristic ( 
> TypeProfileMajorReceiverPercent [=90%]), but if compilation is 
> triggered earlier, profile data could be "incomplete" (Double cases 
> <90% of all cases).
>
> Bimorphic inlining doesn't work here, because the call site has >2 
> receivers.
>
> The fix is to introduce a special case for Double and separate it from 
> other cases. After the fix JSType.toNumeric() method size (35) still 
> fits MaxInlineSize[=35] in HotSpot.
>
> I want to integrate this fix into 9 & 8u40. LambdaForm sharing-related 
> changes (JEP-210) triggers inlining failures in JSType.toNumeric() 
> much more frequently.
>
> Testing: nashorn unit tests, octane.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov