RFR(xs): 8205578: jtreg: Fix failing TestRTMAbortRatio on PPC64
Hi, Could the following simple change be reviewed please? bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/ Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test. I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power. Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected. So it fixes the following test on Power: +Passed: compiler/rtm/locking/TestRTMAbortRatio.java Thank you and best regards, Gustavo
Hi Gustavo, looks fine to me. Thanks, -- Igor
On Jun 25, 2018, at 1:29 AM, Gustavo Romero <gromero@linux.vnet.ibm.com> wrote:
Hi,
Could the following simple change be reviewed please?
bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/
Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test.
I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power.
Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected.
So it fixes the following test on Power:
+Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Thank you and best regards, Gustavo
Hi Igor, On 06/28/2018 03:26 AM, Igor Ignatyev wrote:
Hi Gustavo,
looks fine to me.
Thanks! Could I get a second review please? Regards, Gustavo
Thanks, -- Igor
On Jun 25, 2018, at 1:29 AM, Gustavo Romero <gromero@linux.vnet.ibm.com> wrote:
Hi,
Could the following simple change be reviewed please?
bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/
Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test.
I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power.
Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected.
So it fixes the following test on Power:
+Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Thank you and best regards, Gustavo
Looks good. Thanks, Vladimir On 6/28/18 6:13 AM, Gustavo Romero wrote:
Hi Igor,
On 06/28/2018 03:26 AM, Igor Ignatyev wrote:
Hi Gustavo,
looks fine to me.
Thanks!
Could I get a second review please?
Regards, Gustavo
Thanks, -- Igor
On Jun 25, 2018, at 1:29 AM, Gustavo Romero <gromero@linux.vnet.ibm.com> wrote:
Hi,
Could the following simple change be reviewed please?
bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/
Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test.
I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power.
Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected.
So it fixes the following test on Power:
+Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Thank you and best regards, Gustavo
Hi Vladimir, On 06/28/2018 02:43 PM, Vladimir Kozlov wrote:
Looks good.
Thanks a lot for reviewing it. :) Regards, Gustavo
Thanks, Vladimir
On 6/28/18 6:13 AM, Gustavo Romero wrote:
Hi Igor,
On 06/28/2018 03:26 AM, Igor Ignatyev wrote:
Hi Gustavo,
looks fine to me.
Thanks!
Could I get a second review please?
Regards, Gustavo
Thanks, -- Igor
On Jun 25, 2018, at 1:29 AM, Gustavo Romero <gromero@linux.vnet.ibm.com> wrote:
Hi,
Could the following simple change be reviewed please?
bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/
Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test.
I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power.
Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected.
So it fixes the following test on Power:
+Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Thank you and best regards, Gustavo
Hi, I'm going to push it to jdk/jdk11 after running the tests if there are no objections. Thanks, Gustavo On 06/28/2018 03:00 PM, Gustavo Romero wrote:
Hi Vladimir,
On 06/28/2018 02:43 PM, Vladimir Kozlov wrote:
Looks good.
Thanks a lot for reviewing it. :)
Regards, Gustavo
Thanks, Vladimir
On 6/28/18 6:13 AM, Gustavo Romero wrote:
Hi Igor,
On 06/28/2018 03:26 AM, Igor Ignatyev wrote:
Hi Gustavo,
looks fine to me.
Thanks!
Could I get a second review please?
Regards, Gustavo
Thanks, -- Igor
On Jun 25, 2018, at 1:29 AM, Gustavo Romero <gromero@linux.vnet.ibm.com> wrote:
Hi,
Could the following simple change be reviewed please?
bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/
Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test.
I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power.
Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected.
So it fixes the following test on Power:
+Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Thank you and best regards, Gustavo
On 07/17/2018 04:06 AM, Gustavo Romero wrote:
I'm going to push it to jdk/jdk11 after running the tests if there are no objections.
All tests passed: mach5-one-gromero-JDK-8205578-20180718-1954-31578: Build tasks PASSED. Test tasks SUCCESSFUL. Pushing it. Thanks, Gustavo
Thanks, Gustavo
On 06/28/2018 03:00 PM, Gustavo Romero wrote:
Hi Vladimir,
On 06/28/2018 02:43 PM, Vladimir Kozlov wrote:
Looks good.
Thanks a lot for reviewing it. :)
Regards, Gustavo
Thanks, Vladimir
On 6/28/18 6:13 AM, Gustavo Romero wrote:
Hi Igor,
On 06/28/2018 03:26 AM, Igor Ignatyev wrote:
Hi Gustavo,
looks fine to me.
Thanks!
Could I get a second review please?
Regards, Gustavo
Thanks, -- Igor
On Jun 25, 2018, at 1:29 AM, Gustavo Romero <gromero@linux.vnet.ibm.com> wrote:
Hi,
Could the following simple change be reviewed please?
bug : https://bugs.openjdk.java.net/browse/JDK-8205578 webrev: http://cr.openjdk.java.net/~gromero/8205578/v1/
Currently native method pageSize() is used to cause deliberate transactional aborts. However in test TestRTMAbortRatio pageSize() is not marked to be compilable and as a consequence it's never called through the code path of SharedRuntime::generate_native_wrapper(). As that code path is never exercised no 'tabort' on JNI call is executed and the test fails on Power because of fewer aborts than expected by the test.
I can't say for sure why that test is getting the correct number of aborts on x86. Nonetheless I can confirm that even on x86 the aborts do not come from the native wrapper, i.e. from 'xabort' in SharedRuntime::generate_native_wrapper(). I suspect the aborts on x86 are occurring a bit latter when the native function is called and a "Far Call" is executed in the native method by chance and not in a controlled way. As far as I know there is no way to inspect the exact address when a transaction failed on Intel as it's possible on Power.
Anyway, marking pageSize() as compilable does not cause any regression on Intel (at the same time it starts to exercise the generate_native_wrapper code path) and makes the test pass on Power as expected.
So it fixes the following test on Power:
+Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Thank you and best regards, Gustavo
participants (3)
-
Gustavo Romero
-
Igor Ignatyev
-
Vladimir Kozlov