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

[Marcus Lagergren]

I previously ran this and seem to recall some benchmark regressions, possibly due to the larger byte code size of the very common method JSType.toNumeric. If you can no longer reproduce this (this was a while ago), and your cutoff flag increases may have helped this, you get a +1 from me.

Thanks for analyzing this.

/M


> On 26 Nov 2014, at 11:44, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> 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