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

[Vladimir Ivanov]

Hannes, Marcus, thanks for the reviews.

Best regards,
Vladimir Ivanov

On 11/26/14, 11:37 PM, Hannes Wallnoefer wrote:
> +1
>
> Thanks for looking into this!
>
> Hannes
>
> Am 2014-11-26 um 11:44 schrieb Vladimir Ivanov:
>> 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
>