[9, 8u40] RFR (XS): 8065985: Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D
hannes.wallnoefer at oracle.com
Wed Nov 26 19:37:27 UTC 2014
Thanks for looking into this!
Am 2014-11-26 um 11:44 schrieb Vladimir Ivanov:
> 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
> 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.
> Best regards,
> Vladimir Ivanov
More information about the nashorn-dev