RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue Jan 10 01:02:58 UTC 2017
I looked on linux test machines we run and they don't RTM :(
Or few machines with RTM are not used to run these particular tests.
Vladimir
On 1/5/17 12:18 PM, Gustavo Romero wrote:
> Hi Volker,
>
> Please see my comments inline.
>
> On 05-01-2017 11:18, Volker Simonis wrote:
>> Hi Gustavo,
>>
>> I finally got a Power machine which supports RTM.
>
> Good :)
>
>
>> 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:
>
> Yes, before my change TestRTMSpinLoopCount.java was just crashing the JVM. But
> after that the test is not passing yet. It looks like it is expecting fewer
> abortions and I'm wondering if it's because on Power the transaction is aborted
> if a signal is caught in the middle (the JVM uses signal quite frequently...),
> thus an intrinsic property of the JVM on Power. I'll continue the investigation.
>
>
>>
>> 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?
>
> I don't have access to a x64 machine w/ RTM at the moment, but IIRC some tests
> are failing as well, but fewer in comparison to Power. Much unfortunately I
> don't know when I'll be able to have a x64 machine available again...
>
> I've got the following tests status on a POWER8 machine:
>
> FAILED: compiler/rtm/locking/TestRTMAbortThreshold.java
> FAILED: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
> FAILED: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
> FAILED: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
> FAILED: compiler/rtm/locking/TestRTMLockingCalculationDelay.java
> FAILED: compiler/rtm/locking/TestRTMLockingThreshold.java
> FAILED: compiler/rtm/locking/TestRTMRetryCount.java
> FAILED: compiler/rtm/locking/TestRTMSpinLoopCount.java
> FAILED: compiler/rtm/locking/TestUseRTMXendForLockBusy.java
> FAILED: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java
> Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java
> Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java
> Passed: compiler/rtm/cli/TestRTMRetryCountOption.java
> Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java
> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
> Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java
> Passed: compiler/rtm/locking/TestRTMAbortRatio.java
> Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
> Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java
> Passed: compiler/rtm/locking/TestUseRTMDeopt.java
> Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
> Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
> Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
> Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
> Test results: passed: 28; failed: 10
>
> Hence similar to what you've reported, except for TestRTMAbortRatio.java
> which passed [1], although I would expect more aborts than what was
> reported.
>
>
>> 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?
>
> Exactly. I discussed that briefly with David here [2] when fixing [3]
> and I guess that's the reason for the regression 8171236 [4] not being
> detected firstly at the Oracle side.
>
>
> Regards,
> Gustavo
>
> [1] http://paste.fedoraproject.org/520455/83645916/raw/
> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024361.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8164987
> [4] https://bugs.openjdk.java.net/browse/JDK-8171236
>
>
>> @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