[9] RFR(XS) 8059780: SPECjvm2008-MPEG performance regressions on x64 platforms

[Vladimir Kozlov]

On 11/3/14 9:40 AM, Dean Long wrote:
> By the way, do we know why the lcm change caused  a regression?  Is reordering the worklist
> using pop() a design feature?

No, putting last element in a place of removed one is not used here by "generate optimal code" design but because it is 
fastest way to remove element from array.
If we only used selection code at lines 534-548 it would not matter which is the order.
The problem in special nodes (lines 462-469) which depends on the order and this, I think caused, the problem.

Unfortunately this code in lcm does not produce as optimal code as we would like (see examples in RFEs).
We were unlucky that reordering of nodes due to Atom changes caused this regression.

Thanks,
Vladimir

>
> dl
>
> On 10/31/2014 5:58 PM, Vladimir Kozlov wrote:
>> I forgot to say that lcm.cpp changes were small part of 8052081 changes. The rest of changes will stay.
>>
>> Thanks,
>> Vladimir
>>
>> On 10/31/14 5:55 PM, Vladimir Kozlov wrote:
>>> http://cr.openjdk.java.net/~kvn/8059780/webrev/
>>> https://bugs.openjdk.java.net/browse/JDK-8059780
>>>
>>> We found performance regression (3-5%) on x64 after changes 8052081 [1]
>>> were pushed. It is caused by changes in lcm.cpp. Those changes were done
>>> because Atom is in-order cpu and some benchmarks on Atom showed benefit
>>> from these changes.
>>>
>>> But Atom is not our core platform and the regression is big.
>>>
>>> Backout changes made in lcm.cpp in jdk9 and 8u40 (8052081 was backported
>>> to 8u40).
>>>
>>> We have RFEs to improve block's instructions order which may help both
>>> platforms:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-6958833
>>> https://bugs.openjdk.java.net/browse/JDK-7101232
>>>
>>> Tested with SPECjvm2008-mpegaudio.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8052081
>