RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0

Volker Simonis volker.simonis at gmail.com
Thu Jan 5 13:18:25 UTC 2017 

Hi Gustavo,

I finally got a Power machine which supports RTM.
So before pushing this change, I  thought I run the RTM jtreg tests.

Obviously your change improves the situation by preventing crashes
because of RTMSpinLoopCount=0. But I still get 10 failures when
running the RTM tests (test/compiler/rtm) on linux/ppc64:

compiler/rtm/locking/TestRTMAbortRatio.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Expected to get exit
value of [0]
compiler/rtm/locking/TestRTMAbortThreshold.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Expected that method with
rtm lock elision was deoptimized after 1 lock attempts: expected 10000
to equal 1
compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Two uncommon traps with
reason rtm_state_change should be fired.: expected 0 to equal 2
compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Expected to get only one
deoptimization due to rtm state change: expected 0 to equal 1
compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Expected to get only one
deoptimization due to rtm state change: expected 0 to equal 1
compiler/rtm/locking/TestRTMLockingCalculationDelay.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: At least one
deoptimization due to rtm_state_chage is expected: expected 0 > 0
compiler/rtm/locking/TestRTMLockingThreshold.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: VM output should contain
two RTM locking statistics entries.: expected 1 to equal 2
compiler/rtm/locking/TestRTMRetryCount.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: It is expected to get 2
aborts: expected 3 to equal 2
compiler/rtm/locking/TestRTMSpinLoopCount.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Total aborts count (2001)
should be less or equal to 1001: expected that 2001 <= 1001
compiler/rtm/locking/TestUseRTMXendForLockBusy.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: VM output should contain
exactly one rtm locking statistics entry for method
compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
                                 Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: RTM locking statistics
should contain non zero total aborts count: expected 0 > 0

On the other hand, the situation on linux/x86_64 seems similar (with
7-9 failures depending on the run):

compiler/rtm/locking/TestRTMAbortThreshold.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: Expected that
method with rtm lock elision was deoptimized after 1 lock attempts:
expected 10000 to equal 1
compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: Two uncommon traps
with reason rtm_state_change should be fired.: expected 0 to equal 2
compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: Expected to get
only one deoptimization due to rtm state change: expected 0 to equal 1
compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: After
LockThreshold was reached, method should be recompiled with rtm lock
eliding.: expected null to not equal null
compiler/rtm/locking/TestRTMLockingCalculationDelay.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: At least one
deoptimization due to rtm_state_chage is expected: expected 0 > 0
compiler/rtm/locking/TestRTMLockingThreshold.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: VM output should
contain two RTM locking statistics entries.: expected 1 to equal 2
compiler/rtm/locking/TestRTMTotalCountIncrRate.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: VM output should
contain exactly one RTM locking statistics entry for method
compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0
to equal 1
compiler/rtm/locking/TestUseRTMXendForLockBusy.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: VM output should
contain exactly one rtm locking statistics entry for method
compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
                                          Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: RTM locking
statistics should contain non zero total aborts count: expected 0 > 0

Are these the same results you are seeing as well?

The JDK 9 Early Access Build Test Results site at
http://download.java.net/openjdk/testresults/9/testresults.html
reports these tests as passed, but I think that may be because they
run on hardware which doesn't support RTM?

@Vladimir, David: do you regularly run the RTM tests on linux/x86_64
and do they really all pass in your environment? (I've tested with
Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7
on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and
coreinfo.exe both support RTM).

Thank you and best regards,
Volker

On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero
<gromero at linux.vnet.ibm.com> wrote:
> Hi
>
> On 03-01-2017 16:08, Volker Simonis wrote:
>> Hi David,
>>
>> thanks for looking at this change.
>> As this is ppc64-only, I'll sponsor it.
>>
>> Regards,
>> Volker
>
> David, thanks for reviewing the change.
>
> Volker, thanks for sponsoring it.
>
> Vladimir, thanks for setting the proper priority and fix version tag.
>
>
> Regards,
> Gustavo
>
>> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> Seems fine.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>> On 30/12/2016 11:59 PM, Gustavo Romero wrote:
>>>>
>>>> Hi,
>>>>
>>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but
>>>> since
>>>> I understand that a formal review has to be submitted to the hs ML I
>>>> resent it.
>>>>
>>>> Is any thing missing on my side?
>>>>
>>>> Thank you.
>>>>
>>>>
>>>> Regards,
>>>> Gustavo
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>>>>
>>>> On 15-12-2016 19:03, Gustavo Romero wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Could the following change be reviewed please?
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>>>>> bug   : https://bugs.openjdk.java.net/browse/JDK-8171266
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Gustavo
>>>>>
>>>>
>>>
>>
>

More information about the ppc-aix-port-dev mailing list