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
