[9, 8u40] RFR (XS): 8065985: Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D
vladimir.x.ivanov at oracle.com
Wed Nov 26 10:44:51 UTC 2014
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
Bimorphic inlining doesn't work here, because the call site has >2
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
Testing: nashorn unit tests, octane.
More information about the nashorn-dev