RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
Gustavo Romero
gromero at linux.vnet.ibm.com
Thu Jan 5 20:18:09 UTC 2017
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