+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
