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

[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