Thanks, Marcus.
I ran Octane with increased compilation limits
(MaxNodeLimit/LiveNodeCountInliningCutoff) and I didn't see any
regressions due to this change.
Best regards,
Vladimir Ivanov
On 11/26/14, 5:09 PM, Marcus Lagergren wrote:
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 <[email protected]> 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
