From ningsheng.jian at linaro.org Fri Dec 1 01:56:54 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Fri, 1 Dec 2017 09:56:54 +0800 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> Message-ID: Hi, Can anyone please help to push this small change reviewed by aph? Felix is not available these days, and may not help to commit the patch. http://cr.openjdk.java.net/~njian/8191955/webrev.01/ Thanks, Ningsheng On 30 November 2017 at 09:39, Ningsheng Jian wrote: > Thank you Andrew! > > Regards, > Ningsheng > > On 29 November 2017 at 18:17, Andrew Haley wrote: >> On 29/11/17 02:43, Ningsheng Jian wrote: >>> Thanks for the review! Because of the constraint func, with and >>> without the patch it will report an error for -1 input. But since the >>> constraint func is called after get_processor_features, I've updated >>> the patch to leave -1 to be handled by the constraint func. >>> >>> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ >> >> OK. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Fri Dec 1 02:24:24 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 18:24:24 -0800 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> Message-ID: <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> I submitted pre-integration testing to make sure the test pass on all our platforms. Thanks, Vladimir On 11/30/17 8:31 AM, Andrew Haley wrote: > On 30/11/17 16:28, Boris Ulasevich wrote: >> Thanks for good points! >> >> Updated webrew (with asserts and renamed test moved to better location): >> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ > > Great, that's good to go. > > I think you have to get someone from Oracle to help because it > includes a new test case. > From vladimir.kozlov at oracle.com Fri Dec 1 06:23:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 22:23:37 -0800 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> Message-ID: <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> Testing passed clean. You can push it - we don't use JPRT anymore for pushes. Thanks, Vladimir On 11/30/17 6:24 PM, Vladimir Kozlov wrote: > I submitted pre-integration testing to make sure the test pass on all our platforms. > > Thanks, > Vladimir > > On 11/30/17 8:31 AM, Andrew Haley wrote: >> On 30/11/17 16:28, Boris Ulasevich wrote: >>> Thanks for good points! >>> >>> Updated webrew (with asserts and renamed test moved to better location): >>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >> >> Great, that's good to go. >> >> I think you have to get someone from Oracle to help because it >> includes a new test case. >> From boris.ulasevich at bell-sw.com Fri Dec 1 06:37:39 2017 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 1 Dec 2017 09:37:39 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> Message-ID: <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> Thank you! Boris Ulasevich 01.12.2017 09:23, Vladimir Kozlov ?????: > Testing passed clean. You can push it - we don't use JPRT anymore for > pushes. > > Thanks, > Vladimir > > On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >> I submitted pre-integration testing to make sure the test pass on all >> our platforms. >> >> Thanks, >> Vladimir >> >> On 11/30/17 8:31 AM, Andrew Haley wrote: >>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>> Thanks for good points! >>>> >>>> Updated webrew (with asserts and renamed test moved to better >>>> location): >>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>> >>> Great, that's good to go. >>> >>> I think you have to get someone from Oracle to help because it >>> includes a new test case. >>> From vladimir.x.ivanov at oracle.com Fri Dec 1 11:03:46 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 14:03:46 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> Message-ID: Hold on, I observed a failure in the newly added test on linux-x64: ----------messages:(4/497)---------- command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server -XX:-TieredCompilation -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling reason: User specified action: run main/othervm -Xbootclasspath/a:. -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server -XX:-TieredCompilation -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling Mode: othervm [/othervm specified] elapsed time (seconds): 21.462 ----------configuration:(0/0)---------- ----------System.out:(0/0)---------- ----------System.err:(13/992)---------- java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should deoptimize for actual type check) at compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Best regards, Vladimir Ivanov On 12/1/17 9:37 AM, Boris Ulasevich wrote: > Thank you! > > Boris Ulasevich > > 01.12.2017 09:23, Vladimir Kozlov ?????: >> Testing passed clean. You can push it - we don't use JPRT anymore for >> pushes. >> >> Thanks, >> Vladimir >> >> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>> I submitted pre-integration testing to make sure the test pass on all >>> our platforms. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>> Thanks for good points! >>>>> >>>>> Updated webrew (with asserts and renamed test moved to better >>>>> location): >>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>> >>>> Great, that's good to go. >>>> >>>> I think you have to get someone from Oracle to help because it >>>> includes a new test case. >>>> From dmitry.chuyko at bell-sw.com Fri Dec 1 11:38:45 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 1 Dec 2017 14:38:45 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> Message-ID: <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> There's at least one thing missing in the test, there should be -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the run below was probably fastdebug. After adding that I see the test passing on my x86 and latest sources. Maybe it would make sense not to fail if some deopt doesn't occur. -Dmitry On 12/01/2017 02:03 PM, Vladimir Ivanov wrote: > Hold on, I observed a failure in the newly added test on linux-x64: > > ----------messages:(4/497)---------- > command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI > -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server > -XX:-TieredCompilation -XX:TypeProfileLevel=020 > compiler.profiling.TestTypeProfiling > reason: User specified action: run main/othervm -Xbootclasspath/a:. > -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement > -server -XX:-TieredCompilation -XX:TypeProfileLevel=020 > compiler.profiling.TestTypeProfiling > Mode: othervm [/othervm specified] > elapsed time (seconds): 21.462 > ----------configuration:(0/0)---------- > ----------System.out:(0/0)---------- > ----------System.err:(13/992)---------- > java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should > deoptimize for actual type check) > ????at > compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) > ????at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > ????at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ????at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ????at java.base/java.lang.reflect.Method.invoke(Method.java:564) > ????at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) > ????at java.base/java.lang.Thread.run(Thread.java:844) > > Best regards, > Vladimir Ivanov > > On 12/1/17 9:37 AM, Boris Ulasevich wrote: >> Thank you! >> >> Boris Ulasevich >> >> 01.12.2017 09:23, Vladimir Kozlov ?????: >>> Testing passed clean. You can push it - we don't use JPRT anymore >>> for pushes. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>>> I submitted pre-integration testing to make sure the test pass on >>>> all our platforms. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>>> Thanks for good points! >>>>>> >>>>>> Updated webrew (with asserts and renamed test moved to better >>>>>> location): >>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>>>> >>>>> >>>>> Great, that's good to go. >>>>> >>>>> I think you have to get someone from Oracle to help because it >>>>> includes a new test case. >>>>> From vladimir.x.ivanov at oracle.com Fri Dec 1 12:37:16 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 15:37:16 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> Message-ID: > There's at least one thing missing in the test, there should be > -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the run > below was probably fastdebug. Yes, it was fastdebug. > After adding that I see the test passing on my x86 and latest sources. > Maybe it would make sense not to fail if some deopt doesn't occur. The problem is related to -Xcomp. (I don't know why, but jtreg doesn't list -Xcomp in the log. It was passed passed as a CLI argument to jtreg.) Best regards, Vladimir Ivanov > On 12/01/2017 02:03 PM, Vladimir Ivanov wrote: >> Hold on, I observed a failure in the newly added test on linux-x64: >> >> ----------messages:(4/497)---------- >> command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI >> -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server >> -XX:-TieredCompilation -XX:TypeProfileLevel=020 >> compiler.profiling.TestTypeProfiling >> reason: User specified action: run main/othervm -Xbootclasspath/a:. >> -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement >> -server -XX:-TieredCompilation -XX:TypeProfileLevel=020 >> compiler.profiling.TestTypeProfiling >> Mode: othervm [/othervm specified] >> elapsed time (seconds): 21.462 >> ----------configuration:(0/0)---------- >> ----------System.out:(0/0)---------- >> ----------System.err:(13/992)---------- >> java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should >> deoptimize for actual type check) >> ????at >> compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) >> ????at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> ????at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> ????at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> ????at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> ????at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >> >> ????at java.base/java.lang.Thread.run(Thread.java:844) >> >> Best regards, >> Vladimir Ivanov >> >> On 12/1/17 9:37 AM, Boris Ulasevich wrote: >>> Thank you! >>> >>> Boris Ulasevich >>> >>> 01.12.2017 09:23, Vladimir Kozlov ?????: >>>> Testing passed clean. You can push it - we don't use JPRT anymore >>>> for pushes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>>>> I submitted pre-integration testing to make sure the test pass on >>>>> all our platforms. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>>>> Thanks for good points! >>>>>>> >>>>>>> Updated webrew (with asserts and renamed test moved to better >>>>>>> location): >>>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>>>>> >>>>>> >>>>>> Great, that's good to go. >>>>>> >>>>>> I think you have to get someone from Oracle to help because it >>>>>> includes a new test case. >>>>>> > From boris.ulasevich at bell-sw.com Fri Dec 1 13:45:49 2017 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 1 Dec 2017 16:45:49 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> Message-ID: <517af166-2fdd-cdce-ee61-6e1f11d97482@bell-sw.com> Hi Vladimir, Many thanks to you for this finding! I have added vm.compMode=="Xmixed" check and -XX:-BackgroundCompilation option. Now it should work Ok. http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.03/ best regards, Boris 01.12.2017 15:37, Vladimir Ivanov ?????: >> There's at least one thing missing in the test, there should be >> -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the >> run below was probably fastdebug. > > Yes, it was fastdebug. > >> After adding that I see the test passing on my x86 and latest sources. >> Maybe it would make sense not to fail if some deopt doesn't occur. > > The problem is related to -Xcomp. > > (I don't know why, but jtreg doesn't list -Xcomp in the log. It was > passed passed as a CLI argument to jtreg.) Yes, it was confusing > Best regards, > Vladimir Ivanov > >> On 12/01/2017 02:03 PM, Vladimir Ivanov wrote: >>> Hold on, I observed a failure in the newly added test on linux-x64: >>> >>> ----------messages:(4/497)---------- >>> command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI >>> -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server >>> -XX:-TieredCompilation -XX:TypeProfileLevel=020 >>> compiler.profiling.TestTypeProfiling >>> reason: User specified action: run main/othervm -Xbootclasspath/a:. >>> -XX:+WhiteBoxAPI -XX:-BackgroundCompilation >>> -XX:-UseOnStackReplacement -server -XX:-TieredCompilation >>> -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling >>> Mode: othervm [/othervm specified] >>> elapsed time (seconds): 21.462 >>> ----------configuration:(0/0)---------- >>> ----------System.out:(0/0)---------- >>> ----------System.err:(13/992)---------- >>> java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should >>> deoptimize for actual type check) >>> ????at >>> compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) >>> ????at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> >>> ????at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >>> ????at >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> ????at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> ????at >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>> >>> ????at java.base/java.lang.Thread.run(Thread.java:844) >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 12/1/17 9:37 AM, Boris Ulasevich wrote: >>>> Thank you! >>>> >>>> Boris Ulasevich >>>> >>>> 01.12.2017 09:23, Vladimir Kozlov ?????: >>>>> Testing passed clean. You can push it - we don't use JPRT anymore >>>>> for pushes. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>>>>> I submitted pre-integration testing to make sure the test pass on >>>>>> all our platforms. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>>>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>>>>> Thanks for good points! >>>>>>>> >>>>>>>> Updated webrew (with asserts and renamed test moved to better >>>>>>>> location): >>>>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>>>>>> >>>>>>> >>>>>>> Great, that's good to go. >>>>>>> >>>>>>> I think you have to get someone from Oracle to help because it >>>>>>> includes a new test case. >>>>>>> >> From vladimir.x.ivanov at oracle.com Fri Dec 1 14:46:05 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 17:46:05 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <517af166-2fdd-cdce-ee61-6e1f11d97482@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> <517af166-2fdd-cdce-ee61-6e1f11d97482@bell-sw.com> Message-ID: <9b3b50f0-33f0-13fb-b3db-a356a40f3519@oracle.com> > http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.03/ Looks good. Best regards, Vladimir Ivanov > 01.12.2017 15:37, Vladimir Ivanov ?????: >>> There's at least one thing missing in the test, there should be >>> -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the >>> run below was probably fastdebug. >> >> Yes, it was fastdebug. >> >>> After adding that I see the test passing on my x86 and latest >>> sources. Maybe it would make sense not to fail if some deopt doesn't >>> occur. >> >> The problem is related to -Xcomp. >> >> (I don't know why, but jtreg doesn't list -Xcomp in the log. It was >> passed passed as a CLI argument to jtreg.) > > Yes, it was confusing > >> Best regards, >> Vladimir Ivanov >> >>> On 12/01/2017 02:03 PM, Vladimir Ivanov wrote: >>>> Hold on, I observed a failure in the newly added test on linux-x64: >>>> >>>> ----------messages:(4/497)---------- >>>> command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI >>>> -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server >>>> -XX:-TieredCompilation -XX:TypeProfileLevel=020 >>>> compiler.profiling.TestTypeProfiling >>>> reason: User specified action: run main/othervm -Xbootclasspath/a:. >>>> -XX:+WhiteBoxAPI -XX:-BackgroundCompilation >>>> -XX:-UseOnStackReplacement -server -XX:-TieredCompilation >>>> -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling >>>> Mode: othervm [/othervm specified] >>>> elapsed time (seconds): 21.462 >>>> ----------configuration:(0/0)---------- >>>> ----------System.out:(0/0)---------- >>>> ----------System.err:(13/992)---------- >>>> java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should >>>> deoptimize for actual type check) >>>> ????at >>>> compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) >>>> ????at >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>> ????at >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> >>>> ????at >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> >>>> ????at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>> ????at >>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>>> >>>> ????at java.base/java.lang.Thread.run(Thread.java:844) >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 12/1/17 9:37 AM, Boris Ulasevich wrote: >>>>> Thank you! >>>>> >>>>> Boris Ulasevich >>>>> >>>>> 01.12.2017 09:23, Vladimir Kozlov ?????: >>>>>> Testing passed clean. You can push it - we don't use JPRT anymore >>>>>> for pushes. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>>>>>> I submitted pre-integration testing to make sure the test pass on >>>>>>> all our platforms. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>>>>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>>>>>> Thanks for good points! >>>>>>>>> >>>>>>>>> Updated webrew (with asserts and renamed test moved to better >>>>>>>>> location): >>>>>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>>>>>>> >>>>>>>> >>>>>>>> Great, that's good to go. >>>>>>>> >>>>>>>> I think you have to get someone from Oracle to help because it >>>>>>>> includes a new test case. >>>>>>>> >>> From ci_notify at linaro.org Sat Dec 2 08:32:10 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 2 Dec 2017 08:32:10 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1830615670.8438.1512203531441.JavaMail.jenkins@d711a2dbcc6b> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/335/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.79x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 69.19, Server: 114.76 Client 69.19 / Client 2014-04-01 (43.00): 1.61x Server 114.76 / Server 2014-04-01 (71.00): 1.62x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Mon Dec 4 08:36:42 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 4 Dec 2017 08:36:42 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <2120297417.8544.1512376603575.JavaMail.jenkins@d711a2dbcc6b> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/337/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.84x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.58, Server: 115.7 Client 70.58 / Client 2014-04-01 (43.00): 1.64x Server 115.7 / Server 2014-04-01 (71.00): 1.63x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From tobias.hartmann at oracle.com Mon Dec 4 08:58:40 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 4 Dec 2017 09:58:40 +0100 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> Message-ID: Hi Ningsheng, I'll take care of pushing the fix directly into jdk/jdk to make sure it goes into JDK 10 (see Jesper's rules [1]). Best regards, Tobias [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029476.html On 01.12.2017 02:56, Ningsheng Jian wrote: > Hi, > > Can anyone please help to push this small change reviewed by aph? > Felix is not available these days, and may not help to commit the > patch. > > http://cr.openjdk.java.net/~njian/8191955/webrev.01/ > > Thanks, > Ningsheng > > On 30 November 2017 at 09:39, Ningsheng Jian wrote: >> Thank you Andrew! >> >> Regards, >> Ningsheng >> >> On 29 November 2017 at 18:17, Andrew Haley wrote: >>> On 29/11/17 02:43, Ningsheng Jian wrote: >>>> Thanks for the review! Because of the constraint func, with and >>>> without the patch it will report an error for -1 input. But since the >>>> constraint func is called after get_processor_features, I've updated >>>> the patch to leave -1 to be handled by the constraint func. >>>> >>>> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ >>> >>> OK. >>> >>> -- >>> Andrew Haley >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ningsheng.jian at linaro.org Mon Dec 4 09:08:42 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Mon, 4 Dec 2017 17:08:42 +0800 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> Message-ID: Thank you, Tobias! Regards, Ningsheng On 4 December 2017 at 16:58, Tobias Hartmann wrote: > Hi Ningsheng, > > I'll take care of pushing the fix directly into jdk/jdk to make sure it goes into JDK 10 (see Jesper's rules [1]). > > Best regards, > Tobias > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029476.html > > On 01.12.2017 02:56, Ningsheng Jian wrote: >> Hi, >> >> Can anyone please help to push this small change reviewed by aph? >> Felix is not available these days, and may not help to commit the >> patch. >> >> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ >> >> Thanks, >> Ningsheng >> >> On 30 November 2017 at 09:39, Ningsheng Jian wrote: >>> Thank you Andrew! >>> >>> Regards, >>> Ningsheng >>> >>> On 29 November 2017 at 18:17, Andrew Haley wrote: >>>> On 29/11/17 02:43, Ningsheng Jian wrote: >>>>> Thanks for the review! Because of the constraint func, with and >>>>> without the patch it will report an error for -1 input. But since the >>>>> constraint func is called after get_processor_features, I've updated >>>>> the patch to leave -1 to be handled by the constraint func. >>>>> >>>>> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ >>>> >>>> OK. >>>> >>>> -- >>>> Andrew Haley >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Tue Dec 5 12:31:10 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 Dec 2017 13:31:10 +0100 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert Message-ID: Hi, I see an assert in MacroAssembler::mov(Register, address) failing occasionally on 'addresses' like 0xdeaddead that are generated in some places, e.g. sharedRuntime_aarch64.cpp. Seems like 0xdeaddead can actually point into the heap :-) I propose to fix it by removing the assert. It looks like it's not present in jdk9 and 10. The patch changes MacroAssembler::mov() to be like 9 and 10. http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.00/ An alternative could be to keep the assert in place, but use a better dead value, e.g. badHeapOop from globalDefinitions.hpp . In this case I would bring 9 and 10 in sync too. What do you think? Roman From adinn at redhat.com Tue Dec 5 14:00:50 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 5 Dec 2017 14:00:50 +0000 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert In-Reply-To: References: Message-ID: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> Hi Roman, On 05/12/17 12:31, Roman Kennke wrote: > An alternative could be to keep the assert in place, but use a better > dead value, e.g. badHeapOop from globalDefinitions.hpp . In this case I > would bring 9 and 10 in sync too. > > What do you think? I think it is a good idea to keep the assert. So, badheapOop it is . . . regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From ci_notify at linaro.org Wed Dec 6 08:59:50 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 6 Dec 2017 08:59:50 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <222087628.8814.1512550791863.JavaMail.jenkins@d711a2dbcc6b> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/339/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/05 pass: 1,580; fail: 11 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 7: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 7: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.83x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.22, Server: 115.7 Client 70.22 / Client 2014-04-01 (43.00): 1.63x Server 115.7 / Server 2014-04-01 (71.00): 1.63x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From rkennke at redhat.com Wed Dec 6 12:46:46 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Dec 2017 13:46:46 +0100 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert In-Reply-To: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> References: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> Message-ID: Am 05.12.2017 um 15:00 schrieb Andrew Dinn: > Hi Roman, > > On 05/12/17 12:31, Roman Kennke wrote: > >> An alternative could be to keep the assert in place, but use a better >> dead value, e.g. badHeapOop from globalDefinitions.hpp . In this case I >> would bring 9 and 10 in sync too. >> >> What do you think? > I think it is a good idea to keep the assert. So, badheapOop it is . . . Ok. That makes the fix simpler: http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ Ok? I'd push it into aarch64-port/jdk8u and let aarch64-port/jdk8u-shenandoah pick it up through regular merge-flow. Do you think it's worth to also put it upstream? We don't have this problem there because the assert is not present in upstream. I'd have to put back both the assert and the badHeapOop change. ? Thanks, Roman From adinn at redhat.com Wed Dec 6 13:06:22 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 6 Dec 2017 13:06:22 +0000 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert In-Reply-To: References: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> Message-ID: <819d7fb5-ec7b-86a2-c772-14bfcde69fd0@redhat.com> On 06/12/17 12:46, Roman Kennke wrote: > Ok. That makes the fix simpler: > http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ > > Ok? I'd push it into aarch64-port/jdk8u and let > aarch64-port/jdk8u-shenandoah pick it up through regular merge-flow. > > Do you think it's worth to also put it upstream? We don't have this > problem there because the assert is not present in upstream. I'd have to > put back both the assert and the badHeapOop change. ? Oh, downstream only changes? That's above my paygrade. I fink you'll 'ave to arsk the guvnor abaht tha' wun (in CC). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Wed Dec 6 13:16:38 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Dec 2017 13:16:38 +0000 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert In-Reply-To: References: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> Message-ID: <648fc65f-a387-1b9e-d2b9-84c750cfdd14@redhat.com> On 06/12/17 12:46, Roman Kennke wrote: > Am 05.12.2017 um 15:00 schrieb Andrew Dinn: >> Hi Roman, >> >> On 05/12/17 12:31, Roman Kennke wrote: >> >>> An alternative could be to keep the assert in place, but use a better >>> dead value, e.g. badHeapOop from globalDefinitions.hpp . In this case I >>> would bring 9 and 10 in sync too. >>> >>> What do you think? >> I think it is a good idea to keep the assert. So, badheapOop it is . . . > > Ok. That makes the fix simpler: > http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ > > Ok? I'd push it into aarch64-port/jdk8u and let > aarch64-port/jdk8u-shenandoah pick it up through regular merge-flow. > > Do you think it's worth to also put it upstream? We don't have this > problem there because the assert is not present in upstream. I'd have to > put back both the assert and the badHeapOop change. ? Please don't. I tidied this stuff up for 9, so it shouldn't be a problem there. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Wed Dec 6 13:19:09 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Dec 2017 14:19:09 +0100 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert In-Reply-To: <648fc65f-a387-1b9e-d2b9-84c750cfdd14@redhat.com> References: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> <648fc65f-a387-1b9e-d2b9-84c750cfdd14@redhat.com> Message-ID: <41b9ad8b-9728-a151-72b9-1587eb4e5b1d@redhat.com> Am 06.12.2017 um 14:16 schrieb Andrew Haley: > On 06/12/17 12:46, Roman Kennke wrote: >> Am 05.12.2017 um 15:00 schrieb Andrew Dinn: >>> Hi Roman, >>> >>> On 05/12/17 12:31, Roman Kennke wrote: >>> >>>> An alternative could be to keep the assert in place, but use a better >>>> dead value, e.g. badHeapOop from globalDefinitions.hpp . In this case I >>>> would bring 9 and 10 in sync too. >>>> >>>> What do you think? >>> I think it is a good idea to keep the assert. So, badheapOop it is . . . >> >> Ok. That makes the fix simpler: >> http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ >> >> Ok? I'd push it into aarch64-port/jdk8u and let >> aarch64-port/jdk8u-shenandoah pick it up through regular merge-flow. >> >> Do you think it's worth to also put it upstream? We don't have this >> problem there because the assert is not present in upstream. I'd have to >> put back both the assert and the badHeapOop change. ? > > Please don't. I tidied this stuff up for 9, so it shouldn't be a > problem there. > It is not a problem in jdk9 and jdk10. So... I'll push it to aarch64-port/jdk8u only, is that ok? Roman From aph at redhat.com Wed Dec 6 13:23:06 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Dec 2017 13:23:06 +0000 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert In-Reply-To: <41b9ad8b-9728-a151-72b9-1587eb4e5b1d@redhat.com> References: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> <648fc65f-a387-1b9e-d2b9-84c750cfdd14@redhat.com> <41b9ad8b-9728-a151-72b9-1587eb4e5b1d@redhat.com> Message-ID: On 06/12/17 13:19, Roman Kennke wrote: > Am 06.12.2017 um 14:16 schrieb Andrew Haley: >> On 06/12/17 12:46, Roman Kennke wrote: >>> Am 05.12.2017 um 15:00 schrieb Andrew Dinn: >>>> Hi Roman, >>>> >>>> On 05/12/17 12:31, Roman Kennke wrote: >>>> >>>>> An alternative could be to keep the assert in place, but use a better >>>>> dead value, e.g. badHeapOop from globalDefinitions.hpp . In this case I >>>>> would bring 9 and 10 in sync too. >>>>> >>>>> What do you think? >>>> I think it is a good idea to keep the assert. So, badheapOop it is . . . >>> >>> Ok. That makes the fix simpler: >>> http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ >>> >>> Ok? I'd push it into aarch64-port/jdk8u and let >>> aarch64-port/jdk8u-shenandoah pick it up through regular merge-flow. >>> >>> Do you think it's worth to also put it upstream? We don't have this >>> problem there because the assert is not present in upstream. I'd have to >>> put back both the assert and the badHeapOop change. ? >> >> Please don't. I tidied this stuff up for 9, so it shouldn't be a >> problem there. >> > > It is not a problem in jdk9 and jdk10. > > So... I'll push it to aarch64-port/jdk8u only, is that ok? The patch is fine, but I can see no bug report. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Wed Dec 6 14:47:07 2017 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 Dec 2017 15:47:07 +0100 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert In-Reply-To: References: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> <648fc65f-a387-1b9e-d2b9-84c750cfdd14@redhat.com> <41b9ad8b-9728-a151-72b9-1587eb4e5b1d@redhat.com> Message-ID: Am 06.12.2017 um 14:23 schrieb Andrew Haley: > On 06/12/17 13:19, Roman Kennke wrote: >> Am 06.12.2017 um 14:16 schrieb Andrew Haley: >>> On 06/12/17 12:46, Roman Kennke wrote: >>>> Am 05.12.2017 um 15:00 schrieb Andrew Dinn: >>>>> Hi Roman, >>>>> >>>>> On 05/12/17 12:31, Roman Kennke wrote: >>>>> >>>>>> An alternative could be to keep the assert in place, but use a better >>>>>> dead value, e.g. badHeapOop from globalDefinitions.hpp . In this case I >>>>>> would bring 9 and 10 in sync too. >>>>>> >>>>>> What do you think? >>>>> I think it is a good idea to keep the assert. So, badheapOop it is . . . >>>> >>>> Ok. That makes the fix simpler: >>>> http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ >>>> >>>> Ok? I'd push it into aarch64-port/jdk8u and let >>>> aarch64-port/jdk8u-shenandoah pick it up through regular merge-flow. >>>> >>>> Do you think it's worth to also put it upstream? We don't have this >>>> problem there because the assert is not present in upstream. I'd have to >>>> put back both the assert and the badHeapOop change. ? >>> >>> Please don't. I tidied this stuff up for 9, so it shouldn't be a >>> problem there. >>> >> >> It is not a problem in jdk9 and jdk10. >> >> So... I'll push it to aarch64-port/jdk8u only, is that ok? > > The patch is fine, but I can see no bug report. > I created a bug report: https://bugs.openjdk.java.net/browse/JDK-8193133 One possible fix is to remove the assert and change the code to what make it exactly the same as jdk9 and 10: http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.00/ The other way to fix it is to use a truly impossible heap value instead of 0xDEADDEAD and keep the assert: http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ Let me know which fix you prefer. Thanks, Roman From shade at redhat.com Thu Dec 7 15:00:03 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Dec 2017 16:00:03 +0100 Subject: [aarch64-port-dev ] =?utf-8?q?Build_failure=3A_invalid_register_n?= =?utf-8?b?YW1lIGZvciDigJhyX2V4Y2hhbmdlX3ZhbHVl4oCZ?= Message-ID: <3e420e60-2945-7bc3-8eeb-0979d441377c@redhat.com> Hi, Seeing weird build failures in aarch64/jdk8u and aarch64/jdk8u-shenandoah during aarch64 cross-compilation: /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/hotspot/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp: In member function ?void AccessFlags::atomic_set_bits(jint)?: /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/hotspot/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp:128:18: error: invalid register name for ?r_exchange_value? register jint r_exchange_value asm("w0") = exchange_value; ^~~~~~~~~~~~~~~~ Seems to be coming from: changeset: 9155:7fc149d14601 user: enevill date: Tue Mar 29 10:07:54 2016 +0000 summary: 8151775: aarch64: add support for 8.1 LSE atomic operations Bugreport mentions the fix had come to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/03fb00b96355 What is concerning is that the change in aarch64/8u is *different*, it has the assembly block where the build fails: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/7fc149d14601 What's going on here? Shouldn't aarch64-port version be closer to jdk9? Edward? Thanks, -Aleksey From aph at redhat.com Thu Dec 7 15:26:14 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Dec 2017 15:26:14 +0000 Subject: [aarch64-port-dev ] RFR: JDK8u-only: Fix MacroAssembler::mov() over-strict assert In-Reply-To: References: <5ab5578e-e5bb-2fc1-04b6-4c1b0f3b860d@redhat.com> <648fc65f-a387-1b9e-d2b9-84c750cfdd14@redhat.com> <41b9ad8b-9728-a151-72b9-1587eb4e5b1d@redhat.com> Message-ID: <845106ad-333a-3b24-1ce2-7676d324cc54@redhat.com> On 06/12/17 14:47, Roman Kennke wrote: > I created a bug report: > https://bugs.openjdk.java.net/browse/JDK-8193133 > > One possible fix is to remove the assert and change the code to what > make it exactly the same as jdk9 and 10: > > http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.00/ > > > The other way to fix it is to use a truly impossible heap value instead > of 0xDEADDEAD and keep the assert: > > http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ > > Let me know which fix you prefer. This one: http://cr.openjdk.java.net/~rkennke/aarch64-jdk8u-movoops/webrev.01/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From roman at kennke.org Thu Dec 7 16:29:29 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 07 Dec 2017 16:29:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 8193133: Assertion failure because 0xDEADDEAD can be in-heap Message-ID: <201712071629.vB7GTTsW015450@aojmv0008.oracle.com> Changeset: 97df73117bbe Author: rkennke Date: 2017-12-07 17:23 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/97df73117bbe 8193133: Assertion failure because 0xDEADDEAD can be in-heap Reviewed-by: aph, adinn ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp From roman at kennke.org Thu Dec 7 16:37:10 2017 From: roman at kennke.org (roman at kennke.org) Date: Thu, 07 Dec 2017 16:37:10 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 2 new changesets Message-ID: <201712071637.vB7GbAGO018836@aojmv0008.oracle.com> Changeset: 97df73117bbe Author: rkennke Date: 2017-12-07 17:23 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/97df73117bbe 8193133: Assertion failure because 0xDEADDEAD can be in-heap Reviewed-by: aph, adinn ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Changeset: c2c56efaefbf Author: rkennke Date: 2017-12-07 17:33 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c2c56efaefbf Merge ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp From aph at redhat.com Fri Dec 8 17:50:19 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Dec 2017 17:50:19 +0000 Subject: [aarch64-port-dev ] RFR: 8193260: AArch64: JVMCI: Implement trampoline calls Message-ID: <338e82df-fb2b-47ba-2c75-15e530be5aa4@redhat.com> AArch64 call instructions only have a 26-bit range, so if the code cache is greater than 128 megabytes (and it is by default) compilations will fail with out-of-range branches. C1 and C2 solve this by generating trampolines for Java calls. The Aarch64 JVMCI CodeInstaller doesn't ganerate trampolines, and we should fix it so that it does. Note that this webrev includes the necessary Graal changes. Graal is maintained separately, so these are only included FYI: they will have to be reviewed after these JVMCI changes are in HotSpot. Also note that this includes changes to shared and x86 code, so it'll need a sponsor. http://cr.openjdk.java.net/~aph/8193260-1/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Dec 8 17:54:14 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Dec 2017 17:54:14 +0000 Subject: [aarch64-port-dev ] =?utf-8?q?Build_failure=3A_invalid_register_n?= =?utf-8?b?YW1lIGZvciDigJhyX2V4Y2hhbmdlX3ZhbHVl4oCZ?= In-Reply-To: <3e420e60-2945-7bc3-8eeb-0979d441377c@redhat.com> References: <3e420e60-2945-7bc3-8eeb-0979d441377c@redhat.com> Message-ID: <35857db7-dda5-fc07-9dfe-34534771b90c@redhat.com> On 07/12/17 15:00, Aleksey Shipilev wrote: > /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/hotspot/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp: > In member function ?void AccessFlags::atomic_set_bits(jint)?: > /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/hotspot/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp:128:18: > error: invalid register name for ?r_exchange_value? > register jint r_exchange_value asm("w0") = exchange_value; w0 is a legitimate register name. This is a bug in GCC. You can try "x0" to see what happens. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Fri Dec 8 19:07:55 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 8 Dec 2017 19:07:55 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV Message-ID: Hello, The Aarch64 backend decompresses klass pointers using XOR if the size of the compressed classes space is less then the base address. However, in JDK 10 CompressedClassSpaceSize doesn't represent the range of the compressed shared classes area, which is set to 4GB. https://bugs.openjdk.java.net/browse/JDK-8193266 http://cr.openjdk.java.net/~smonteith/8193266/webrev/ I've speculatively put up a patch which deals with the issue on Aarch64. While I understand the problem with the generated aarch64 code, I don't believe understand the CDS code sufficiently at this point to determine if there is a bug within the CDS code regarding the CompressedClassSpaceSize parameter. Thanks, Stuart From ci_notify at linaro.org Sat Dec 9 01:25:13 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 9 Dec 2017 01:25:13 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <562828591.9238.1512782713956.JavaMail.jenkins@d711a2dbcc6b> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/341/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 8: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 7: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 8: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 8: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 8: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 7: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 8: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 8: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.86x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 69.53, Server: 114.76 Client 69.53 / Client 2014-04-01 (43.00): 1.62x Server 114.76 / Server 2014-04-01 (71.00): 1.62x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Sat Dec 9 02:09:09 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 9 Dec 2017 02:09:09 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <2092373875.9243.1512785350616.JavaMail.jenkins@d711a2dbcc6b> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2017/342/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/jan/18 pass: 672; fail: 44; error: 3 Build 1: aarch64/2017/feb/04 pass: 672; fail: 44; error: 3 Build 2: aarch64/2017/feb/24 pass: 672; fail: 44; error: 3 Build 3: aarch64/2017/mar/29 pass: 672; fail: 44; error: 3 Build 4: aarch64/2017/apr/05 pass: 672; fail: 44; error: 3 Build 5: aarch64/2017/apr/20 pass: 673; fail: 44; error: 3 Build 6: aarch64/2017/jun/12 pass: 713; fail: 6; error: 2 Build 7: aarch64/2017/jun/26 pass: 713; fail: 6; error: 2 Build 8: aarch64/2017/jul/21 pass: 708; fail: 12; error: 2 Build 9: aarch64/2017/aug/16 pass: 708; fail: 12; error: 2 Build 10: aarch64/2017/aug/19 pass: 708; fail: 12; error: 2 Build 11: aarch64/2017/aug/31 pass: 708; fail: 12; error: 2 Build 12: aarch64/2017/oct/25 pass: 715; fail: 6; error: 2 Build 13: aarch64/2017/nov/15 pass: 715; fail: 6; error: 2 Build 14: aarch64/2017/dec/08 pass: 715; fail: 6; error: 2 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/jan/18 pass: 5,683; fail: 213; error: 36 Build 1: aarch64/2017/feb/04 pass: 5,667; fail: 234; error: 41 Build 2: aarch64/2017/feb/24 pass: 5,701; fail: 217; error: 27 Build 3: aarch64/2017/mar/29 pass: 5,686; fail: 225; error: 34 Build 4: aarch64/2017/apr/05 pass: 5,677; fail: 235; error: 33 Build 5: aarch64/2017/apr/20 pass: 5,671; fail: 254; error: 34 Build 6: aarch64/2017/jun/12 pass: 5,765; fail: 175; error: 23 Build 7: aarch64/2017/jun/26 pass: 5,757; fail: 174; error: 23 Build 8: aarch64/2017/jul/21 pass: 5,768; fail: 172; error: 22 Build 9: aarch64/2017/aug/16 pass: 5,753; fail: 188; error: 21 Build 10: aarch64/2017/aug/19 pass: 5,763; fail: 177; error: 23 Build 11: aarch64/2017/aug/31 pass: 5,754; fail: 183; error: 26 Build 12: aarch64/2017/oct/25 pass: 5,766; fail: 181; error: 21 Build 13: aarch64/2017/nov/15 pass: 5,773; fail: 175; error: 21 Build 14: aarch64/2017/dec/08 pass: 5,778; fail: 165; error: 26 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/jan/18 pass: 3,098; error: 13 Build 1: aarch64/2017/feb/04 pass: 3,094; error: 17 Build 2: aarch64/2017/feb/24 pass: 3,106; error: 6 Build 3: aarch64/2017/mar/29 pass: 3,105; fail: 2; error: 5 Build 4: aarch64/2017/apr/05 pass: 3,104; fail: 2; error: 6 Build 5: aarch64/2017/apr/20 pass: 3,101; fail: 2; error: 10 Build 6: aarch64/2017/jun/12 pass: 3,109; fail: 2; error: 2 Build 7: aarch64/2017/jun/26 pass: 3,109; fail: 2; error: 2 Build 8: aarch64/2017/jul/21 pass: 3,110; fail: 2; error: 2 Build 9: aarch64/2017/aug/16 pass: 3,111; fail: 2; error: 1 Build 10: aarch64/2017/aug/19 pass: 3,111; fail: 2; error: 1 Build 11: aarch64/2017/aug/31 pass: 3,110; fail: 2; error: 2 Build 12: aarch64/2017/oct/25 pass: 3,111; fail: 2; error: 1 Build 13: aarch64/2017/nov/15 pass: 3,111; fail: 2; error: 1 Build 14: aarch64/2017/dec/08 pass: 3,111; fail: 2; error: 1 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/jan/18 pass: 673; fail: 43; error: 3 Build 1: aarch64/2017/feb/04 pass: 673; fail: 43; error: 3 Build 2: aarch64/2017/feb/24 pass: 673; fail: 43; error: 3 Build 3: aarch64/2017/mar/29 pass: 673; fail: 43; error: 3 Build 4: aarch64/2017/apr/05 pass: 673; fail: 43; error: 3 Build 5: aarch64/2017/apr/20 pass: 674; fail: 43; error: 3 Build 6: aarch64/2017/jun/12 pass: 714; fail: 5; error: 2 Build 7: aarch64/2017/jun/26 pass: 714; fail: 5; error: 2 Build 8: aarch64/2017/jul/21 pass: 709; fail: 11; error: 2 Build 9: aarch64/2017/aug/16 pass: 709; fail: 11; error: 2 Build 10: aarch64/2017/aug/19 pass: 709; fail: 11; error: 2 Build 11: aarch64/2017/aug/31 pass: 709; fail: 11; error: 2 Build 12: aarch64/2017/oct/25 pass: 716; fail: 5; error: 2 Build 13: aarch64/2017/nov/15 pass: 716; fail: 5; error: 2 Build 14: aarch64/2017/dec/08 pass: 716; fail: 5; error: 2 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/jan/18 pass: 5,690; fail: 206; error: 36 Build 1: aarch64/2017/feb/04 pass: 5,669; fail: 214; error: 59 Build 2: aarch64/2017/feb/24 pass: 5,701; fail: 221; error: 23 Build 3: aarch64/2017/mar/29 pass: 5,696; fail: 222; error: 27 Build 4: aarch64/2017/apr/05 pass: 5,692; fail: 229; error: 24 Build 5: aarch64/2017/apr/20 pass: 5,705; fail: 220; error: 34 Build 6: aarch64/2017/jun/12 pass: 5,778; fail: 161; error: 24 Build 7: aarch64/2017/jun/26 pass: 5,770; fail: 159; error: 25 Build 8: aarch64/2017/jul/21 pass: 5,769; fail: 168; error: 25 Build 9: aarch64/2017/aug/16 pass: 5,761; fail: 181; error: 20 Build 10: aarch64/2017/aug/19 pass: 5,768; fail: 175; error: 20 Build 11: aarch64/2017/aug/31 pass: 5,761; fail: 177; error: 25 Build 12: aarch64/2017/oct/25 pass: 5,769; fail: 178; error: 21 Build 13: aarch64/2017/nov/15 pass: 5,785; fail: 161; error: 23 Build 14: aarch64/2017/dec/08 pass: 5,775; fail: 172; error: 22 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/jan/18 pass: 3,102; error: 9 Build 1: aarch64/2017/feb/04 pass: 3,099; error: 12 Build 2: aarch64/2017/feb/24 pass: 3,109; error: 3 Build 3: aarch64/2017/mar/29 pass: 3,104; fail: 2; error: 6 Build 4: aarch64/2017/apr/05 pass: 3,105; fail: 2; error: 5 Build 5: aarch64/2017/apr/20 pass: 3,098; fail: 2; error: 13 Build 6: aarch64/2017/jun/12 pass: 3,109; fail: 2; error: 2 Build 7: aarch64/2017/jun/26 pass: 3,109; fail: 2; error: 2 Build 8: aarch64/2017/jul/21 pass: 3,110; fail: 2; error: 2 Build 9: aarch64/2017/aug/16 pass: 3,110; fail: 2; error: 2 Build 10: aarch64/2017/aug/19 pass: 3,110; fail: 2; error: 2 Build 11: aarch64/2017/aug/31 pass: 3,110; fail: 2; error: 2 Build 12: aarch64/2017/oct/25 pass: 3,111; fail: 2; error: 1 Build 13: aarch64/2017/nov/15 pass: 3,110; fail: 2; error: 2 Build 14: aarch64/2017/dec/08 pass: 3,110; fail: 2; error: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.95x Relative performance: Server critical-jOPS (nc): 0.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 57.61, Server: 108.58 Client 57.61 / Client 2014-04-01 (43.00): 1.34x Server 108.58 / Server 2014-04-01 (71.00): 1.53x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-12-22 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2016/356/results/ 2017-01-18 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/018/results/ 2017-02-06 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/035/results/ 2017-02-25 pass rate: 5176/5176, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/055/results/ 2017-03-29 pass rate: 8484/8485, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/088/results/ 2017-04-05 pass rate: 8484/8485, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/095/results/ 2017-04-20 pass rate: 8484/8485, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/110/results/ 2017-06-13 pass rate: 8484/8485, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/163/results/ 2017-06-27 pass rate: 8484/8485, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/177/results/ 2017-08-16 pass rate: 8484/8485, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/228/results/ 2017-08-19 pass rate: 8484/8485, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/231/results/ 2017-08-31 pass rate: 8484/8485, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/243/results/ 2017-10-26 pass rate: 8489/8490, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/298/results/ 2017-11-15 pass rate: 8489/8490, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/319/results/ 2017-12-09 pass rate: 8490/8491, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2017/342/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From aph at redhat.com Sat Dec 9 11:37:15 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 9 Dec 2017 11:37:15 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: Message-ID: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> Hi, On 08/12/17 19:07, Stuart Monteith wrote: > The Aarch64 backend decompresses klass pointers using XOR if the > size of the compressed classes space is less then the base address. > However, in JDK 10 CompressedClassSpaceSize doesn't represent the > range of the compressed shared classes area, which is set to 4GB. > > https://bugs.openjdk.java.net/browse/JDK-8193266 > http://cr.openjdk.java.net/~smonteith/8193266/webrev/ > > I've speculatively put up a patch which deals with the issue on > Aarch64. While I understand the problem with the generated aarch64 > code, I don't believe understand the CDS code sufficiently at this > point to determine if there is a bug within the CDS code regarding the > CompressedClassSpaceSize parameter. Good catch! Hmm. This sort-of papers over the problem, in that it disables XOR- encoding of class metadata. I would have thought it makes more sense to set narrow_klass_base high enough so that this does not happen. We really want narrow_klass_shift to be zero if we can, which should be OK if the shared klasses are in a 4G range. I think that I see the logic of your patch, but I think it's a very complicated way of saying if (narrow_klass_base() > 1ul << 32 << narrow_klass_shift()) Also, beware of putting any more complexity into use_XOR_for_compressed_class_base because it's executed very often. We should perhaps do it once, when we allocate the metaspace. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat Dec 9 19:02:19 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 9 Dec 2017 19:02:19 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> Message-ID: On 09/12/17 11:37, Andrew Haley wrote: > Hmm. This sort-of papers over the problem, in that it disables XOR- > encoding of class metadata. I would have thought it makes more sense > to set narrow_klass_base high enough so that this does not happen. We > really want narrow_klass_shift to be zero if we can, which should be > OK if the shared klasses are in a 4G range. And I now see that in the very odd code in question the shift is set to 3, regardless of the fact that it's not necessary. Something to do with AOT, which I guess always does the shift. I'd prefer AArch64 always to set the shift to zero, and we could then search for a suitable base. We never need a shift for compressed classes, given that 4G seems to be hard-wired as a maximum size. We could establish the convention that the shift is always zero on AArch64, and then this problem would go away completely. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Sun Dec 10 09:04:45 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 10 Dec 2017 09:04:45 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <194548692.9431.1512896686122.JavaMail.jenkins@d711a2dbcc6b> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/343/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 8: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,584; fail: 10 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 7: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 8: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 Build 9: aarch64/2017/dec/09 pass: 7,558; fail: 727; error: 22 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 8: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 Build 9: aarch64/2017/dec/09 pass: 3,830; fail: 4; error: 2 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 8: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,588; fail: 10; error: 1 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 7: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 8: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 Build 9: aarch64/2017/dec/09 pass: 7,570; fail: 716; error: 21 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 8: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Build 9: aarch64/2017/dec/09 pass: 3,832; fail: 3; error: 1 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.99x Relative performance: Server critical-jOPS (nc): 0.84x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 69.88, Server: 112.92 Client 69.88 / Client 2014-04-01 (43.00): 1.63x Server 112.92 / Server 2014-04-01 (71.00): 1.59x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ 2017-12-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/343/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Sun Dec 10 09:46:33 2017 From: aph at redhat.com (Andrew Haley) Date: Sun, 10 Dec 2017 09:46:33 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> Message-ID: On 09/12/17 19:02, Andrew Haley wrote: > We could establish the convention that the shift is always zero > on AArch64, and then this problem would go away completely. Ahh, I just realized that this too is too simple, because we don't know where the metaspace is going to be, so we have to generate code which can run wherever the metaspace is. It's tricky. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Mon Dec 11 13:43:33 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 11 Dec 2017 13:43:33 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> Message-ID: I've copied and pasted the calculation for UnscaledClassSpaceMax in use_XOR_for_compressed_class_base to match the variable of the same name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces - I did this for ease of reference while we decide what to do. I guess you're referring to this piece of code: As far as I can tell, the parameter CompressedClassSpaceSize is ignored. On 10 December 2017 at 09:46, Andrew Haley wrote: > On 09/12/17 19:02, Andrew Haley wrote: > >> We could establish the convention that the shift is always zero >> on AArch64, and then this problem would go away completely. > > Ahh, I just realized that this too is too simple, because we don't > know where the metaspace is going to be, so we have to generate code > which can run wherever the metaspace is. It's tricky. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Dec 11 13:54:54 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Dec 2017 13:54:54 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> Message-ID: On 11/12/17 13:43, Stuart Monteith wrote: > I've copied and pasted the calculation for UnscaledClassSpaceMax in > use_XOR_for_compressed_class_base to match the variable of the same > name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces - > I did this for ease of reference while we decide what to do. Yes, I get that. I don't want to pessimize the "normal" use of OpenJDK AArch64 for the sake of this weird case. I guess that as long as no- one explicitly sets the base of the metaspace below 32 bits it doesn't matter anyway. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Tue Dec 12 09:08:09 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 12 Dec 2017 09:08:09 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <2137146238.9618.1513069690282.JavaMail.jenkins@d711a2dbcc6b> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/345/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 8: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,584; fail: 10 Build 10: aarch64/2017/dec/11 pass: 1,584; fail: 10 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 7: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 8: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 Build 9: aarch64/2017/dec/09 pass: 7,558; fail: 727; error: 22 Build 10: aarch64/2017/dec/11 pass: 7,559; fail: 732; error: 19 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 8: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 Build 9: aarch64/2017/dec/09 pass: 3,830; fail: 4; error: 2 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 4; error: 1 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 8: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,588; fail: 10; error: 1 Build 10: aarch64/2017/dec/11 pass: 1,589; fail: 9; error: 1 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 7: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 8: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 Build 9: aarch64/2017/dec/09 pass: 7,570; fail: 716; error: 21 Build 10: aarch64/2017/dec/11 pass: 7,584; fail: 705; error: 21 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 8: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Build 9: aarch64/2017/dec/09 pass: 3,832; fail: 3; error: 1 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 3; error: 2 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.00x Relative performance: Server critical-jOPS (nc): 0.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 69.19, Server: 111.14 Client 69.19 / Client 2014-04-01 (43.00): 1.61x Server 111.14 / Server 2014-04-01 (71.00): 1.57x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ 2017-12-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/343/results/ 2017-12-12 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/345/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From adinn at redhat.com Tue Dec 12 15:27:18 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 12 Dec 2017 15:27:18 +0000 Subject: [aarch64-port-dev ] RFR: 8193260: AArch64: JVMCI: Implement trampoline calls In-Reply-To: <338e82df-fb2b-47ba-2c75-15e530be5aa4@redhat.com> References: <338e82df-fb2b-47ba-2c75-15e530be5aa4@redhat.com> Message-ID: <22e19f80-9c62-084c-0c52-efb86fb1ddab@redhat.com> On 08/12/17 17:50, Andrew Haley wrote: > AArch64 call instructions only have a 26-bit range, so if the code > cache is greater than 128 megabytes (and it is by default) > compilations will fail with out-of-range branches. > > C1 and C2 solve this by generating trampolines for Java calls. The > Aarch64 JVMCI CodeInstaller doesn't ganerate trampolines, and we > should fix it so that it does. > > Note that this webrev includes the necessary Graal changes. Graal is > maintained separately, so these are only included FYI: they will have > to be reviewed after these JVMCI changes are in HotSpot. > > Also note that this includes changes to shared and x86 code, so it'll > need a sponsor. > > http://cr.openjdk.java.net/~aph/8193260-1/ This looks ok by eyeball and OpenJDK builds and runs ok for non-Graal runs on AArch64. So, on those grounds it is reviewed. I also patched and built a latest checkout Graal tree in order to test Graal, pointed it at my jdkdev/hs build (aka, for now, jdk10) using --jdkhome /path/to/jdkdev/hs/build/... and then tried to run a few things. This was fine when running Hello World which did nto need to load Graal compiler code. However, it barfed when I tried running netbeans apparently because of having to eat compiler class files with version 54 (jdk10). So, building Graal with jdk10 doesn't actually work yet: Caused by: java.lang.UnsupportedClassVersionError: Unsupported class file version: 54.0 at jdk.internal.vm.compiler/org.graalvm.compiler.replacements.classfile.Classfile.(Classfile.java:69) at jdk.internal.vm.compiler/org.graalvm.compiler.replacements.classfile.ClassfileBytecodeProvider.getClassfile(ClassfileBytecodeProvider.java:129) I fixed this by tweaking the offending class above, Classfile, to allow bytecode versions up to 54 and it then successfully ran netbeans (the relevant diff is included below). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander --- a/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java +++ b/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/classfile/Classfile.java @@ -47,7 +47,7 @@ public class Classfile { private final List codeAttributes; private static final int MAJOR_VERSION_JAVA7 = 51; - private static final int MAJOR_VERSION_JAVA9 = 53; + private static final int MAJOR_VERSION_JAVA10 = 54; private static final int MAGIC = 0xCAFEBABE; /** @@ -65,7 +65,7 @@ public class Classfile { int minor = stream.readUnsignedShort(); int major = stream.readUnsignedShort(); - if (major < MAJOR_VERSION_JAVA7 || major > MAJOR_VERSION_JAVA9) { + if (major < MAJOR_VERSION_JAVA7 || major > MAJOR_VERSION_JAVA10) { throw new UnsupportedClassVersionError("Unsupported class file version: " + major + "." + minor); } From Derek.White at cavium.com Tue Dec 12 18:24:50 2017 From: Derek.White at cavium.com (White, Derek) Date: Tue, 12 Dec 2017 18:24:50 +0000 Subject: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? Message-ID: Hi folks, I have some suggestions for topics for our next fireside chat. These are motived by aspects of the new 6-month release cycle: 1. New features tend to drop in without a lot of warning, so we should be proactive in looking for these features as early as possible. 2. We have a shorter window to get new aarch64 features into a release, so bigger features may need to be targeted to a release early, and may need a coordinated push to get them in. 3. And finally, we have more parties working on the aarch64 port, so we don't want to duplicate effort accidentally. As mentioned earlier, I've started tracking these issues on https://docs.google.com/spreadsheets/d/1JT3lFsiju60JSU43DWN8NjuCjjNVhkp7TltajdJCOr8/edit?usp=sharing Some topics for discussion: * Does anyone have further info on which new Java features (JEPs or Projects) need porting or testing, or know that they don't need porting? * Does anyone want to investigate any of these feature? * Is anyone already working on a feature? * What is the status of the work? * Is help needed? * Do people have opinions on the priorities of this porting work? * Do we want to explicitly target some of these features for JDK 11, 12, or 1024? * In particular, I'd like to talk about the Graal related features - AOT and JIT. * Status of Graal on aarch64. * Thanks Redhat! * Anyone else pitching in? * Is there aarch64 work to be done in hotspot to support AOT/JIT (jvmci, etc)? * Do we want to target a working AOT or JIT on aarch64 to a particular JDK release? * Do we need more people to make this happen? For implementation, testing, etc. * I have concerns about the SIMD/Vector API work going on as part of Project Panama, but primarily to get someone to look at the API to make sure it's OK for SVE, not necessarily to implement it soon. Does this sound like enough for a meeting? If so, I'll leave it to Stuart to set things up. Feel free to update the web page or email out questions or status beforehand. Thanks, * Derek From stuart.monteith at linaro.org Wed Dec 13 15:25:38 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 13 Dec 2017 15:25:38 +0000 Subject: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? In-Reply-To: References: Message-ID: Hello Derek, I can certainly set up a meeting. I suggest making a break with the past and not scheduling this on Thursdays. I suggest we either suggest something next week, or in January. I just need to know people's preferences. I'm in all week next week, my last day is Friday and return on January 2nd. BR, Stuart On 12 December 2017 at 18:24, White, Derek wrote: > Hi folks, > > I have some suggestions for topics for our next fireside chat. These are motived by aspects of the new 6-month release cycle: > > 1. New features tend to drop in without a lot of warning, so we should be proactive in looking for these features as early as possible. > 2. We have a shorter window to get new aarch64 features into a release, so bigger features may need to be targeted to a release early, and may need a coordinated push to get them in. > 3. And finally, we have more parties working on the aarch64 port, so we don't want to duplicate effort accidentally. > > As mentioned earlier, I've started tracking these issues on https://docs.google.com/spreadsheets/d/1JT3lFsiju60JSU43DWN8NjuCjjNVhkp7TltajdJCOr8/edit?usp=sharing > > Some topics for discussion: > > * Does anyone have further info on which new Java features (JEPs or Projects) need porting or testing, or know that they don't need porting? > * Does anyone want to investigate any of these feature? > * Is anyone already working on a feature? > * What is the status of the work? > * Is help needed? > * Do people have opinions on the priorities of this porting work? > * Do we want to explicitly target some of these features for JDK 11, 12, or 1024? > * In particular, I'd like to talk about the Graal related features - AOT and JIT. > * Status of Graal on aarch64. > * Thanks Redhat! > * Anyone else pitching in? > * Is there aarch64 work to be done in hotspot to support AOT/JIT (jvmci, etc)? > * Do we want to target a working AOT or JIT on aarch64 to a particular JDK release? > * Do we need more people to make this happen? For implementation, testing, etc. > * I have concerns about the SIMD/Vector API work going on as part of Project Panama, but primarily to get someone to look at the API to make sure it's OK for SVE, not necessarily to implement it soon. > > Does this sound like enough for a meeting? If so, I'll leave it to Stuart to set things up. > > Feel free to update the web page or email out questions or status beforehand. > > Thanks, > > * Derek From stuart.monteith at linaro.org Wed Dec 13 15:56:21 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 13 Dec 2017 15:56:21 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> Message-ID: Hello, Here's most latest patch: http://cr.openjdk.java.net/~smonteith/8193266/webrev-2/ Things to note: I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp and metaspaceShared.cpp MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is the same value as UnscaledOopHeapMax. Perhaps that should be used instead of UnscaledClassSpaceMax in all three places. I'm using the constant in MacroAssembler_aarch64.hpp in the MacroAssembler constructor instead of CompressedClassSpaceSize. The calculation has changed - "1u" has changed to "1ul" as the address "0x100000000" is not representable as a 32 bit value. The test has changed from ">" to ">=" as the greatest offset for 4GB is "0xffffffff", and so 0x100000000 and upwards are all acceptable for XORing offsets to. The intention is to prevent bad code from being generated if the compressed class addresses range changes. BR, Stuart On 11 December 2017 at 13:54, Andrew Haley wrote: > On 11/12/17 13:43, Stuart Monteith wrote: >> I've copied and pasted the calculation for UnscaledClassSpaceMax in >> use_XOR_for_compressed_class_base to match the variable of the same >> name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces - >> I did this for ease of reference while we decide what to do. > > Yes, I get that. I don't want to pessimize the "normal" use of OpenJDK > AArch64 for the sake of this weird case. I guess that as long as no- > one explicitly sets the base of the metaspace below 32 bits it doesn't > matter anyway. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Derek.White at cavium.com Wed Dec 13 18:43:59 2017 From: Derek.White at cavium.com (White, Derek) Date: Wed, 13 Dec 2017 18:43:59 +0000 Subject: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? In-Reply-To: References: Message-ID: Thanks Stuart, Next Tuesday (the 19th) at 12 EST works great for Cavium-US. But I can make time Mon-Thurs. Otherwise January it is. - Derek > -----Original Message----- > From: Stuart Monteith [mailto:stuart.monteith at linaro.org] > Sent: Wednesday, December 13, 2017 10:26 AM > To: White, Derek > Cc: aarch64-port-dev > Subject: Re: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? > > Hello Derek, > I can certainly set up a meeting. I suggest making a break with the past and > not scheduling this on Thursdays. I suggest we either suggest something next > week, or in January. > > I just need to know people's preferences. I'm in all week next week, my last > day is Friday and return on January 2nd. > > > > > BR, > Stuart > > > > > > On 12 December 2017 at 18:24, White, Derek > wrote: > > Hi folks, > > > > I have some suggestions for topics for our next fireside chat. These are > motived by aspects of the new 6-month release cycle: > > > > 1. New features tend to drop in without a lot of warning, so we should be > proactive in looking for these features as early as possible. > > 2. We have a shorter window to get new aarch64 features into a release, > so bigger features may need to be targeted to a release early, and may need > a coordinated push to get them in. > > 3. And finally, we have more parties working on the aarch64 port, so we > don't want to duplicate effort accidentally. > > > > As mentioned earlier, I've started tracking these issues on > > > https://docs.google.com/spreadsheets/d/1JT3lFsiju60JSU43DWN8NjuCjjNVh > k > > p7TltajdJCOr8/edit?usp=sharing > > > > Some topics for discussion: > > > > * Does anyone have further info on which new Java features (JEPs or > Projects) need porting or testing, or know that they don't need porting? > > * Does anyone want to investigate any of these feature? > > * Is anyone already working on a feature? > > * What is the status of the work? > > * Is help needed? > > * Do people have opinions on the priorities of this porting work? > > * Do we want to explicitly target some of these features for JDK 11, 12, or > 1024? > > * In particular, I'd like to talk about the Graal related features - AOT and > JIT. > > * Status of Graal on aarch64. > > * Thanks Redhat! > > * Anyone else pitching in? > > * Is there aarch64 work to be done in hotspot to support AOT/JIT > (jvmci, etc)? > > * Do we want to target a working AOT or JIT on aarch64 to a particular > JDK release? > > * Do we need more people to make this happen? For implementation, > testing, etc. > > * I have concerns about the SIMD/Vector API work going on as part of > Project Panama, but primarily to get someone to look at the API to make sure > it's OK for SVE, not necessarily to implement it soon. > > > > Does this sound like enough for a meeting? If so, I'll leave it to Stuart to set > things up. > > > > Feel free to update the web page or email out questions or status > beforehand. > > > > Thanks, > > > > * Derek From stewartd.qdt at qualcommdatacenter.com Wed Dec 13 19:35:14 2017 From: stewartd.qdt at qualcommdatacenter.com (stewartd.qdt) Date: Wed, 13 Dec 2017 19:35:14 +0000 Subject: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? In-Reply-To: References: Message-ID: <4116e0977178482aac468a5a0172e537@NASANEXM01E.na.qualcomm.com> I would like to join the discussion and next Tuesday works fine with my schedule. However, going forward Tuesdays & Thursdays are bad for me and would prefer Monday, Wednesday, or Friday for meetings starting in January. Thanks, Daniel Stewart -----Original Message----- From: aarch64-port-dev [mailto:aarch64-port-dev-bounces at openjdk.java.net] On Behalf Of White, Derek Sent: Wednesday, December 13, 2017 1:44 PM To: Stuart Monteith Cc: aarch64-port-dev Subject: Re: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? Thanks Stuart, Next Tuesday (the 19th) at 12 EST works great for Cavium-US. But I can make time Mon-Thurs. Otherwise January it is. - Derek > -----Original Message----- > From: Stuart Monteith [mailto:stuart.monteith at linaro.org] > Sent: Wednesday, December 13, 2017 10:26 AM > To: White, Derek > Cc: aarch64-port-dev > Subject: Re: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? > > Hello Derek, > I can certainly set up a meeting. I suggest making a break with the > past and not scheduling this on Thursdays. I suggest we either suggest > something next week, or in January. > > I just need to know people's preferences. I'm in all week next week, > my last day is Friday and return on January 2nd. > > > > > BR, > Stuart > > > > > > On 12 December 2017 at 18:24, White, Derek > wrote: > > Hi folks, > > > > I have some suggestions for topics for our next fireside chat. These > > are > motived by aspects of the new 6-month release cycle: > > > > 1. New features tend to drop in without a lot of warning, so we > > should be > proactive in looking for these features as early as possible. > > 2. We have a shorter window to get new aarch64 features into a > > release, > so bigger features may need to be targeted to a release early, and may > need a coordinated push to get them in. > > 3. And finally, we have more parties working on the aarch64 port, > > so we > don't want to duplicate effort accidentally. > > > > As mentioned earlier, I've started tracking these issues on > > > https://docs.google.com/spreadsheets/d/1JT3lFsiju60JSU43DWN8NjuCjjNVh > k > > p7TltajdJCOr8/edit?usp=sharing > > > > Some topics for discussion: > > > > * Does anyone have further info on which new Java features (JEPs or > Projects) need porting or testing, or know that they don't need porting? > > * Does anyone want to investigate any of these feature? > > * Is anyone already working on a feature? > > * What is the status of the work? > > * Is help needed? > > * Do people have opinions on the priorities of this porting work? > > * Do we want to explicitly target some of these features for JDK 11, 12, or > 1024? > > * In particular, I'd like to talk about the Graal related features - AOT and > JIT. > > * Status of Graal on aarch64. > > * Thanks Redhat! > > * Anyone else pitching in? > > * Is there aarch64 work to be done in hotspot to support AOT/JIT > (jvmci, etc)? > > * Do we want to target a working AOT or JIT on aarch64 to a particular > JDK release? > > * Do we need more people to make this happen? For implementation, > testing, etc. > > * I have concerns about the SIMD/Vector API work going on as part of > Project Panama, but primarily to get someone to look at the API to > make sure it's OK for SVE, not necessarily to implement it soon. > > > > Does this sound like enough for a meeting? If so, I'll leave it to > > Stuart to set > things up. > > > > Feel free to update the web page or email out questions or status > beforehand. > > > > Thanks, > > > > * Derek From ci_notify at linaro.org Thu Dec 14 01:56:59 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 14 Dec 2017 01:56:59 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <163251282.9771.1513216620857.JavaMail.jenkins@d711a2dbcc6b> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/347/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 8: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,584; fail: 10 Build 10: aarch64/2017/dec/11 pass: 1,584; fail: 10 Build 11: aarch64/2017/dec/13 pass: 1,585; fail: 9 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 7: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 8: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 Build 9: aarch64/2017/dec/09 pass: 7,558; fail: 727; error: 22 Build 10: aarch64/2017/dec/11 pass: 7,559; fail: 732; error: 19 Build 11: aarch64/2017/dec/13 pass: 7,558; fail: 725; error: 27 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 8: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 Build 9: aarch64/2017/dec/09 pass: 3,830; fail: 4; error: 2 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 4; error: 1 Build 11: aarch64/2017/dec/13 pass: 3,831; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 8: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,588; fail: 10; error: 1 Build 10: aarch64/2017/dec/11 pass: 1,589; fail: 9; error: 1 Build 11: aarch64/2017/dec/13 pass: 1,589; fail: 9; error: 1 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 7: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 8: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 Build 9: aarch64/2017/dec/09 pass: 7,570; fail: 716; error: 21 Build 10: aarch64/2017/dec/11 pass: 7,584; fail: 705; error: 21 Build 11: aarch64/2017/dec/13 pass: 7,577; fail: 713; error: 20 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 8: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Build 9: aarch64/2017/dec/09 pass: 3,832; fail: 3; error: 1 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 3; error: 2 Build 11: aarch64/2017/dec/13 pass: 3,830; fail: 4; error: 1 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.85x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 67.86, Server: 109.42 Client 67.86 / Client 2014-04-01 (43.00): 1.58x Server 109.42 / Server 2014-04-01 (71.00): 1.54x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ 2017-12-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/343/results/ 2017-12-12 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/345/results/ 2017-12-14 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/347/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Thu Dec 14 09:28:52 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Dec 2017 09:28:52 +0000 Subject: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? In-Reply-To: <4116e0977178482aac468a5a0172e537@NASANEXM01E.na.qualcomm.com> References: <4116e0977178482aac468a5a0172e537@NASANEXM01E.na.qualcomm.com> Message-ID: <3fd0f300-b1fc-13c5-8c11-13fc8e12c478@redhat.com> On 13/12/17 19:35, stewartd.qdt wrote: > I would like to join the discussion and next Tuesday works fine with my schedule. Tuesday is fine for me. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitry.chuyko at bell-sw.com Thu Dec 14 11:17:38 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 14 Dec 2017 14:17:38 +0300 Subject: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? In-Reply-To: References: Message-ID: Thanks, Same time is fine for BellSoft too. -Dmitry On 12/13/2017 09:43 PM, White, Derek wrote: > Thanks Stuart, > > Next Tuesday (the 19th) at 12 EST works great for Cavium-US. But I can make time Mon-Thurs. Otherwise January it is. > > - Derek > >> -----Original Message----- >> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >> Sent: Wednesday, December 13, 2017 10:26 AM >> To: White, Derek >> Cc: aarch64-port-dev >> Subject: Re: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? >> >> Hello Derek, >> I can certainly set up a meeting. I suggest making a break with the past and >> not scheduling this on Thursdays. I suggest we either suggest something next >> week, or in January. >> >> I just need to know people's preferences. I'm in all week next week, my last >> day is Friday and return on January 2nd. >> >> >> >> >> BR, >> Stuart >> >> >> >> >> >> On 12 December 2017 at 18:24, White, Derek >> wrote: >>> Hi folks, >>> >>> I have some suggestions for topics for our next fireside chat. These are >> motived by aspects of the new 6-month release cycle: >>> 1. New features tend to drop in without a lot of warning, so we should be >> proactive in looking for these features as early as possible. >>> 2. We have a shorter window to get new aarch64 features into a release, >> so bigger features may need to be targeted to a release early, and may need >> a coordinated push to get them in. >>> 3. And finally, we have more parties working on the aarch64 port, so we >> don't want to duplicate effort accidentally. >>> As mentioned earlier, I've started tracking these issues on >>> >> https://docs.google.com/spreadsheets/d/1JT3lFsiju60JSU43DWN8NjuCjjNVh >> k >>> p7TltajdJCOr8/edit?usp=sharing >>> >>> Some topics for discussion: >>> >>> * Does anyone have further info on which new Java features (JEPs or >> Projects) need porting or testing, or know that they don't need porting? >>> * Does anyone want to investigate any of these feature? >>> * Is anyone already working on a feature? >>> * What is the status of the work? >>> * Is help needed? >>> * Do people have opinions on the priorities of this porting work? >>> * Do we want to explicitly target some of these features for JDK 11, 12, or >> 1024? >>> * In particular, I'd like to talk about the Graal related features - AOT and >> JIT. >>> * Status of Graal on aarch64. >>> * Thanks Redhat! >>> * Anyone else pitching in? >>> * Is there aarch64 work to be done in hotspot to support AOT/JIT >> (jvmci, etc)? >>> * Do we want to target a working AOT or JIT on aarch64 to a particular >> JDK release? >>> * Do we need more people to make this happen? For implementation, >> testing, etc. >>> * I have concerns about the SIMD/Vector API work going on as part of >> Project Panama, but primarily to get someone to look at the API to make sure >> it's OK for SVE, not necessarily to implement it soon. >>> Does this sound like enough for a meeting? If so, I'll leave it to Stuart to set >> things up. >>> Feel free to update the web page or email out questions or status >> beforehand. >>> Thanks, >>> >>> * Derek From ci_notify at linaro.org Sat Dec 16 10:00:30 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 16 Dec 2017 10:00:30 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1421228337.239.1513418430879.JavaMail.jenkins@c5b43cbe6e9c> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/349/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 8: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,584; fail: 10 Build 10: aarch64/2017/dec/11 pass: 1,584; fail: 10 Build 11: aarch64/2017/dec/13 pass: 1,585; fail: 9 Build 12: aarch64/2017/dec/15 pass: 1,588; fail: 10 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 7: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 8: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 Build 9: aarch64/2017/dec/09 pass: 7,558; fail: 727; error: 22 Build 10: aarch64/2017/dec/11 pass: 7,559; fail: 732; error: 19 Build 11: aarch64/2017/dec/13 pass: 7,558; fail: 725; error: 27 Build 12: aarch64/2017/dec/15 pass: 7,569; fail: 741; error: 25 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 8: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 Build 9: aarch64/2017/dec/09 pass: 3,830; fail: 4; error: 2 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 4; error: 1 Build 11: aarch64/2017/dec/13 pass: 3,831; fail: 4 Build 12: aarch64/2017/dec/15 pass: 3,835; fail: 3; error: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 8: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,588; fail: 10; error: 1 Build 10: aarch64/2017/dec/11 pass: 1,589; fail: 9; error: 1 Build 11: aarch64/2017/dec/13 pass: 1,589; fail: 9; error: 1 Build 12: aarch64/2017/dec/15 pass: 1,592; fail: 11 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 7: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 8: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 Build 9: aarch64/2017/dec/09 pass: 7,570; fail: 716; error: 21 Build 10: aarch64/2017/dec/11 pass: 7,584; fail: 705; error: 21 Build 11: aarch64/2017/dec/13 pass: 7,577; fail: 713; error: 20 Build 12: aarch64/2017/dec/15 pass: 7,600; fail: 711; error: 24 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 8: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Build 9: aarch64/2017/dec/09 pass: 3,832; fail: 3; error: 1 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 3; error: 2 Build 11: aarch64/2017/dec/13 pass: 3,830; fail: 4; error: 1 Build 12: aarch64/2017/dec/15 pass: 3,833; fail: 3; error: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.85x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.58, Server: 117.63 Client 70.58 / Client 2014-04-01 (43.00): 1.64x Server 117.63 / Server 2014-04-01 (71.00): 1.66x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ 2017-12-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/343/results/ 2017-12-12 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/345/results/ 2017-12-14 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/347/results/ 2017-12-16 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/349/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From dms at samersoff.net Mon Dec 18 08:05:43 2017 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 18 Dec 2017 11:05:43 +0300 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> Message-ID: Stuart, I can confirm that the patch works in our environment. -Dmitry On 13.12.2017 18:56, Stuart Monteith wrote: > Hello, > Here's most latest patch: > > http://cr.openjdk.java.net/~smonteith/8193266/webrev-2/ > > Things to note: > I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp > and metaspaceShared.cpp > MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is > the same value as UnscaledOopHeapMax. Perhaps that should be used > instead of UnscaledClassSpaceMax in all three places. > I'm using the constant in MacroAssembler_aarch64.hpp in the > MacroAssembler constructor instead of CompressedClassSpaceSize. > The calculation has changed - "1u" has changed to "1ul" as the > address "0x100000000" is not representable as a 32 bit value. > The test has changed from ">" to ">=" as the greatest offset for > 4GB is "0xffffffff", and so 0x100000000 and upwards are all acceptable > for XORing offsets to. > > The intention is to prevent bad code from being generated if the > compressed class addresses range changes. > > BR, > Stuart > > On 11 December 2017 at 13:54, Andrew Haley wrote: >> On 11/12/17 13:43, Stuart Monteith wrote: >>> I've copied and pasted the calculation for UnscaledClassSpaceMax in >>> use_XOR_for_compressed_class_base to match the variable of the same >>> name in MetaspaceShared::initialize_dumptime_shared_and_meta_spaces - >>> I did this for ease of reference while we decide what to do. >> >> Yes, I get that. I don't want to pessimize the "normal" use of OpenJDK >> AArch64 for the sake of this weird case. I guess that as long as no- >> one explicitly sets the base of the metaspace below 32 bits it doesn't >> matter anyway. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Dec 18 09:15:53 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Dec 2017 09:15:53 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> Message-ID: <20e812bc-d132-9863-815b-345283f9517e@redhat.com> On 13/12/17 15:56, Stuart Monteith wrote: > I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp > and metaspaceShared.cpp > MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is > the same value as UnscaledOopHeapMax. Perhaps that should be used > instead of UnscaledClassSpaceMax in all three places. > I'm using the constant in MacroAssembler_aarch64.hpp in the > MacroAssembler constructor instead of CompressedClassSpaceSize. I don't thing that really helps. We don't need a global constant which is the worst possible case for UnscaledClassSpaceMax because we already know what that is: it's 2**32. We need to know how much space is in use. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Mon Dec 18 09:25:16 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 18 Dec 2017 09:25:16 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1543865923.348.1513589116856.JavaMail.jenkins@c5b43cbe6e9c> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/351/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 8: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,584; fail: 10 Build 10: aarch64/2017/dec/11 pass: 1,584; fail: 10 Build 11: aarch64/2017/dec/13 pass: 1,585; fail: 9 Build 12: aarch64/2017/dec/15 pass: 1,588; fail: 10 Build 13: aarch64/2017/dec/17 pass: 1,597; fail: 11; error: 1 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 7: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 8: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 Build 9: aarch64/2017/dec/09 pass: 7,558; fail: 727; error: 22 Build 10: aarch64/2017/dec/11 pass: 7,559; fail: 732; error: 19 Build 11: aarch64/2017/dec/13 pass: 7,558; fail: 725; error: 27 Build 12: aarch64/2017/dec/15 pass: 7,569; fail: 741; error: 25 Build 13: aarch64/2017/dec/17 pass: 7,591; fail: 719; error: 26 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 8: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 Build 9: aarch64/2017/dec/09 pass: 3,830; fail: 4; error: 2 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 4; error: 1 Build 11: aarch64/2017/dec/13 pass: 3,831; fail: 4 Build 12: aarch64/2017/dec/15 pass: 3,835; fail: 3; error: 3 Build 13: aarch64/2017/dec/17 pass: 3,820; fail: 3; error: 3 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 8: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,588; fail: 10; error: 1 Build 10: aarch64/2017/dec/11 pass: 1,589; fail: 9; error: 1 Build 11: aarch64/2017/dec/13 pass: 1,589; fail: 9; error: 1 Build 12: aarch64/2017/dec/15 pass: 1,592; fail: 11 Build 13: aarch64/2017/dec/17 pass: 1,604; fail: 10 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 7: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 8: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 Build 9: aarch64/2017/dec/09 pass: 7,570; fail: 716; error: 21 Build 10: aarch64/2017/dec/11 pass: 7,584; fail: 705; error: 21 Build 11: aarch64/2017/dec/13 pass: 7,577; fail: 713; error: 20 Build 12: aarch64/2017/dec/15 pass: 7,600; fail: 711; error: 24 Build 13: aarch64/2017/dec/17 pass: 7,593; fail: 721; error: 22 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 8: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Build 9: aarch64/2017/dec/09 pass: 3,832; fail: 3; error: 1 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 3; error: 2 Build 11: aarch64/2017/dec/13 pass: 3,830; fail: 4; error: 1 Build 12: aarch64/2017/dec/15 pass: 3,833; fail: 3; error: 5 Build 13: aarch64/2017/dec/17 pass: 3,822; fail: 3; error: 1 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.73x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 69.53, Server: 116.65 Client 69.53 / Client 2014-04-01 (43.00): 1.62x Server 116.65 / Server 2014-04-01 (71.00): 1.64x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ 2017-12-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/343/results/ 2017-12-12 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/345/results/ 2017-12-14 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/347/results/ 2017-12-16 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/349/results/ 2017-12-18 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/351/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From stuart.monteith at linaro.org Mon Dec 18 13:41:36 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 18 Dec 2017 13:41:36 +0000 Subject: [aarch64-port-dev ] RFR: 8193266: AArch64: TestOptionsWithRanges.java SIGSEGV In-Reply-To: <20e812bc-d132-9863-815b-345283f9517e@redhat.com> References: <7dbf43d1-72b9-5720-3878-ce31f3e8f555@redhat.com> <20e812bc-d132-9863-815b-345283f9517e@redhat.com> Message-ID: Ok, the constant was just an attempt at reducing the likelihood of the backend generating bad addresses if the range changes. We have a testcase that might trip if the future changes. We'll need the 4GB limit during dumping the shared metaspace. During runtime, we'll need the maximum size of the compressed metaspace. I suppose that's the intention behind using CompressedClassSpaceSize. I've just been checking to see if that still holds. BR, Stuart On 18 December 2017 at 09:15, Andrew Haley wrote: > On 13/12/17 15:56, Stuart Monteith wrote: >> I've moved the constant "UnscaledClassSpaceMax" from metaspace.cpp >> and metaspaceShared.cpp >> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces. This is >> the same value as UnscaledOopHeapMax. Perhaps that should be used >> instead of UnscaledClassSpaceMax in all three places. >> I'm using the constant in MacroAssembler_aarch64.hpp in the >> MacroAssembler constructor instead of CompressedClassSpaceSize. > > I don't thing that really helps. We don't need a global constant > which is the worst possible case for UnscaledClassSpaceMax because > we already know what that is: it's 2**32. > > We need to know how much space is in use. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Dec 18 17:29:11 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Dec 2017 17:29:11 +0000 Subject: [aarch64-port-dev ] Vectorized support for array equals/compare/mismatch using Unsafe Message-ID: <1dc6ba44-09bc-9de8-608c-f09a89876cb4@redhat.com> https://bugs.openjdk.java.net/browse/JDK-8136924 I can't find a tracker bug for an AArch64 version of this. Is there one? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Mon Dec 18 17:54:23 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 18 Dec 2017 17:54:23 +0000 Subject: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? In-Reply-To: References: Message-ID: Hello, Apologies, this slipped my find. I've scheduled the meeting for 5pm GMT, 12pm EST on Tuesday 18th December 2017. To join the Meeting: https://bluejeans.com/880637328 To join via Room System: Video Conferencing System: bjn.vc -or-199.48.152.152 Meeting ID : 880637328 To join via phone : 1) Dial: +1.408.740.7256 (United States) +1.408.317.9253 (Alternate number) (see all numbers - http://bluejeans.com/premium-numbers) 2) Enter Conference ID : 880637328 BR, Stuart On 14 December 2017 at 11:17, Dmitry Chuyko wrote: > Thanks, > > Same time is fine for BellSoft too. > > -Dmitry > > > > On 12/13/2017 09:43 PM, White, Derek wrote: >> >> Thanks Stuart, >> >> Next Tuesday (the 19th) at 12 EST works great for Cavium-US. But I can >> make time Mon-Thurs. Otherwise January it is. >> >> - Derek >> >>> -----Original Message----- >>> From: Stuart Monteith [mailto:stuart.monteith at linaro.org] >>> Sent: Wednesday, December 13, 2017 10:26 AM >>> To: White, Derek >>> Cc: aarch64-port-dev >>> Subject: Re: [aarch64-port-dev ] Topics for next AARCH64 Fireside Chat? >>> >>> Hello Derek, >>> I can certainly set up a meeting. I suggest making a break with the >>> past and >>> not scheduling this on Thursdays. I suggest we either suggest something >>> next >>> week, or in January. >>> >>> I just need to know people's preferences. I'm in all week next week, my >>> last >>> day is Friday and return on January 2nd. >>> >>> >>> >>> >>> BR, >>> Stuart >>> >>> >>> >>> >>> >>> On 12 December 2017 at 18:24, White, Derek >>> wrote: >>>> >>>> Hi folks, >>>> >>>> I have some suggestions for topics for our next fireside chat. These are >>> >>> motived by aspects of the new 6-month release cycle: >>>> >>>> 1. New features tend to drop in without a lot of warning, so we >>>> should be >>> >>> proactive in looking for these features as early as possible. >>>> >>>> 2. We have a shorter window to get new aarch64 features into a >>>> release, >>> >>> so bigger features may need to be targeted to a release early, and may >>> need >>> a coordinated push to get them in. >>>> >>>> 3. And finally, we have more parties working on the aarch64 port, so >>>> we >>> >>> don't want to duplicate effort accidentally. >>>> >>>> As mentioned earlier, I've started tracking these issues on >>>> >>> https://docs.google.com/spreadsheets/d/1JT3lFsiju60JSU43DWN8NjuCjjNVh >>> k >>>> >>>> p7TltajdJCOr8/edit?usp=sharing >>>> >>>> Some topics for discussion: >>>> >>>> * Does anyone have further info on which new Java features (JEPs or >>> >>> Projects) need porting or testing, or know that they don't need porting? >>>> >>>> * Does anyone want to investigate any of these feature? >>>> * Is anyone already working on a feature? >>>> * What is the status of the work? >>>> * Is help needed? >>>> * Do people have opinions on the priorities of this porting work? >>>> * Do we want to explicitly target some of these features for JDK >>>> 11, 12, or >>> >>> 1024? >>>> >>>> * In particular, I'd like to talk about the Graal related features >>>> - AOT and >>> >>> JIT. >>>> >>>> * Status of Graal on aarch64. >>>> * Thanks Redhat! >>>> * Anyone else pitching in? >>>> * Is there aarch64 work to be done in hotspot to support AOT/JIT >>> >>> (jvmci, etc)? >>>> >>>> * Do we want to target a working AOT or JIT on aarch64 to a >>>> particular >>> >>> JDK release? >>>> >>>> * Do we need more people to make this happen? For >>>> implementation, >>> >>> testing, etc. >>>> >>>> * I have concerns about the SIMD/Vector API work going on as part >>>> of >>> >>> Project Panama, but primarily to get someone to look at the API to make >>> sure >>> it's OK for SVE, not necessarily to implement it soon. >>>> >>>> Does this sound like enough for a meeting? If so, I'll leave it to >>>> Stuart to set >>> >>> things up. >>>> >>>> Feel free to update the web page or email out questions or status >>> >>> beforehand. >>>> >>>> Thanks, >>>> >>>> * Derek > > From dmitrij.pochepko at bell-sw.com Tue Dec 19 13:56:32 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Tue, 19 Dec 2017 16:56:32 +0300 Subject: [aarch64-port-dev ] Vectorized support for array equals/compare/mismatch using Unsafe In-Reply-To: <1dc6ba44-09bc-9de8-608c-f09a89876cb4@redhat.com> References: <1dc6ba44-09bc-9de8-608c-f09a89876cb4@redhat.com> Message-ID: Hi, this is intended to be part of this JEP: https://bugs.openjdk.java.net/browse/JDK-8189104 which I'm working on. However, I have not yet started coding on this specific intrinsic. I've created respective subtask: https://bugs.openjdk.java.net/browse/JDK-8193806 to make this task apparent. Please let me know if you already started to work on it (or want to do this one yourself) to avoid efforts duplication. Thanks, Dmitrij On 18.12.2017 20:29, Andrew Haley wrote: > https://bugs.openjdk.java.net/browse/JDK-8136924 > > I can't find a tracker bug for an AArch64 version of this. Is there > one? > From ci_notify at linaro.org Wed Dec 20 09:24:44 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 20 Dec 2017 09:24:44 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <751594586.620.1513761885613.JavaMail.jenkins@c5b43cbe6e9c> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/353/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,445; fail: 15 Build 1: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 2: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 5: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 8: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,584; fail: 10 Build 10: aarch64/2017/dec/11 pass: 1,584; fail: 10 Build 11: aarch64/2017/dec/13 pass: 1,585; fail: 9 Build 12: aarch64/2017/dec/15 pass: 1,588; fail: 10 Build 13: aarch64/2017/dec/17 pass: 1,597; fail: 11; error: 1 Build 14: aarch64/2017/dec/19 pass: 1,599; fail: 11 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,490; fail: 739; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 2: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 3: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 4: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 5: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 6: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 7: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 8: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 Build 9: aarch64/2017/dec/09 pass: 7,558; fail: 727; error: 22 Build 10: aarch64/2017/dec/11 pass: 7,559; fail: 732; error: 19 Build 11: aarch64/2017/dec/13 pass: 7,558; fail: 725; error: 27 Build 12: aarch64/2017/dec/15 pass: 7,569; fail: 741; error: 25 Build 13: aarch64/2017/dec/17 pass: 7,591; fail: 719; error: 26 Build 14: aarch64/2017/dec/19 pass: 7,572; fail: 740; error: 24 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 2: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 3: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 4: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 5: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 8: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 Build 9: aarch64/2017/dec/09 pass: 3,830; fail: 4; error: 2 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 4; error: 1 Build 11: aarch64/2017/dec/13 pass: 3,831; fail: 4 Build 12: aarch64/2017/dec/15 pass: 3,835; fail: 3; error: 3 Build 13: aarch64/2017/dec/17 pass: 3,820; fail: 3; error: 3 Build 14: aarch64/2017/dec/19 pass: 3,819; fail: 3; error: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 1,449; fail: 16 Build 1: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 2: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 4: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 5: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 8: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 Build 9: aarch64/2017/dec/09 pass: 1,588; fail: 10; error: 1 Build 10: aarch64/2017/dec/11 pass: 1,589; fail: 9; error: 1 Build 11: aarch64/2017/dec/13 pass: 1,589; fail: 9; error: 1 Build 12: aarch64/2017/dec/15 pass: 1,592; fail: 11 Build 13: aarch64/2017/dec/17 pass: 1,604; fail: 10 Build 14: aarch64/2017/dec/19 pass: 1,605; fail: 10 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 7,508; fail: 721; error: 22 Build 1: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 2: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 3: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 4: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 5: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 6: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 7: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 8: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 Build 9: aarch64/2017/dec/09 pass: 7,570; fail: 716; error: 21 Build 10: aarch64/2017/dec/11 pass: 7,584; fail: 705; error: 21 Build 11: aarch64/2017/dec/13 pass: 7,577; fail: 713; error: 20 Build 12: aarch64/2017/dec/15 pass: 7,600; fail: 711; error: 24 Build 13: aarch64/2017/dec/17 pass: 7,593; fail: 721; error: 22 Build 14: aarch64/2017/dec/19 pass: 7,586; fail: 726; error: 24 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/21 pass: 3,812; fail: 4; error: 1 Build 1: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 2: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 3: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 5: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 6: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 8: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Build 9: aarch64/2017/dec/09 pass: 3,832; fail: 3; error: 1 Build 10: aarch64/2017/dec/11 pass: 3,830; fail: 3; error: 2 Build 11: aarch64/2017/dec/13 pass: 3,830; fail: 4; error: 1 Build 12: aarch64/2017/dec/15 pass: 3,833; fail: 3; error: 5 Build 13: aarch64/2017/dec/17 pass: 3,822; fail: 3; error: 1 Build 14: aarch64/2017/dec/19 pass: 3,817; fail: 3; error: 6 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.74x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 69.19, Server: 109.42 Client 69.19 / Client 2014-04-01 (43.00): 1.61x Server 109.42 / Server 2014-04-01 (71.00): 1.54x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-22 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/325/results/ 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ 2017-12-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/343/results/ 2017-12-12 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/345/results/ 2017-12-14 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/347/results/ 2017-12-16 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/349/results/ 2017-12-18 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/351/results/ 2017-12-20 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/353/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From zhongwei.yao at linaro.org Fri Dec 22 08:02:39 2017 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Fri, 22 Dec 2017 16:02:39 +0800 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations Message-ID: Hi, We are planning to add AArch64 LDP/STP (load/store pair of registers) support in C2 code-gen for better performance. I think the LDP/STP can be used in following cases: A). For register spill/unspill. We've observed many sequential single stack load/store patterns in SPECjbb C2 generated code. B). Besides spilling, LDP is also not generated generally for multiple LoadI/LoadL nodes. Is there any risk (e.g. implicit check?) for combing them together, apart from alignment issue? I think peephole is the best fit for above optimization (gcc/llvm also has such peephole optimization). However, current peephole rules in C2 compiler is very limited and I doubt whether it really takes effect - AArch64 has disabled peephole optimizations. x86 has enabled it, but the instruction sequences to be matched by the rules seems to be very uncommon. To address issue A), since current spill/unspill are handled by common MachSpillCopyNode, I was thinking if we could add peephole rule to match MachSpillCopyNode, but MachSpillCopyNode has no operands (e.g. mem, src, dst) like ordinary instruct defined in aarch64.ad. Even we may extract them (mem, src, dst) like in MachSpillCopyNode::implementation(), and even we can extend current peephole rule grammar, expressing such extraction in peephole's grammar is complex. So I prefer adding following manually defined method peephole() to MachSpillCopyNode: virtual MachNode *peephole(Block *block, int block_index, PhaseRegAlloc *ra_, int &deleted); This makes the patch relative simple. My prototype patch for A) (still some TODOs and hardcodes, but it works fine): http://cr.openjdk.java.net/~zyao/RFC_A/ To address issue B) is somewhat complicated, we need to extend current peephole rule syntax, as I don't think current simple syntax works for any useful peephole optimizations like ldp/stp opt. My extended syntax - at least works for ldp/stp optimizations: ------ peepmatch ( loadI loadI ); peepconstraint (0.mem$base == 1.mem$base, 0.mem$scale == 1.mem$scale, 0.mem$disp - 4 == 1.mem$disp, 0.dst != 1.dst); // new grammar is described below. peepreplace (loadPairI(1.mem 1.mem)) ------ But for loadPairI, it is hard to express in current instruct semantic. Because current instruct in aarch64.ad is defined by a match rule. The match rule is an expression tree and made of Ideal Node. However, LDP instruction doesn't have Ideal Node (say LoadPair) to match. And adding load pair node to arch-independent Ideal node seems strange. My proposed solution is: add a special arch dependent operand like iRegIpair: ------ operand iRegIpair(iRegI reg1, iRegI reg2) %{ constraint(ALLOC_IN_RC(any_reg32)); op_cost(0); format %{ "pair: reg1, reg2"%}; // hard coded format for now. interface(REG_INTER); %} ------ This needs to update ADLC to support iRegIpair operand. Because unlike current operand which has 1 register, iRegIpair has 2. Then use it as loadPairI's operand type like: ------ instruct loadPairI(indOffI mem, iRegIpair dst) %{ match(Set dst mem); //no Ideal Node in match rule. ... %} ------ Then we can use loadPairI in peephole rule's "peepreplace". Since only constraints between operands are supported in peephole rule. But to check whether the adjacent loads are loaded from adjacent memory address, we need to check operand's member, like (0.mem$disp - 4 == 1.mem$disp), My solution is: add new grammar like 0.mem$disp to extract member in operand in ADLC (peep_constraint_parse()). Another issue for peephole optimization is that it only matches adjacent instructions in the same basic block. This leads to many missing matches when loads are not scheduled to adjacent. So I propose to delay peephole phase to the place just before final code emit (the fill_buffer() function). This place is after instruction scheduling. So after instruction scheduling, we could match more adjacent loads. My draft patch to address B) is at: http://cr.openjdk.java.net/~zyao/RFC_B/ What do you think? Welcome any feedback! -- Best regards, Zhongwei From rahul.v.raghavan at oracle.com Fri Dec 22 09:35:22 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 22 Dec 2017 15:05:22 +0530 Subject: [aarch64-port-dev ] [10] RFR: 8193699: AArch64 Fails to build after 8167372 Message-ID: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> Hi, Request help to review the following fix proposal. - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ Related links - -- https://bugs.openjdk.java.net/browse/JDK-8193699 -- https://bugs.openjdk.java.net/browse/JDK-8167372 ? - 'Add code to check for getting oops while thread is in native' -- https://bugs.openjdk.java.net/browse/JDK-8191227 ? - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / print_on() and LIR_Assembler::jobject2reg()' Found root cause of 8193699 issue, as missing changes for aarch64 in 'macroAssembler_aarch64.cpp', similar to changes done for 8191227 before pushing 8167372 support. So now fixed the issue of unsafe handle resolution in 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. Stuart Monteith confirmed build failure fixed with above proposed changeset and no new issues with testing. Thanks, Rahul From dmitry.chuyko at bell-sw.com Fri Dec 22 11:45:37 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 22 Dec 2017 14:45:37 +0300 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: Message-ID: Hi Zhongwei, I'm not a reviewer. Thank you, it is a great idea to merge loads or stores that are issued sequentially. Can you share some more data on that? Is there a micro-benchmark or some sample program than shows better performance on some hardware? What are the numbers observed? You mention SPECjbb, is it 2005 or 2015? Which configuration? In SPECjbb dou you see most sequential series only related to stack work? -Dmitry On 12/22/2017 11:02 AM, Zhongwei Yao wrote: > Hi, > > We are planning to add AArch64 LDP/STP (load/store pair of registers) > support in C2 code-gen for better performance. I think the LDP/STP can > be used in following cases: > A). For register spill/unspill. We've observed many sequential single > stack load/store patterns in SPECjbb C2 generated code. > B). Besides spilling, LDP is also not generated generally for multiple > LoadI/LoadL nodes. Is there any risk (e.g. implicit check?) for > combing them together, apart from alignment issue? > > I think peephole is the best fit for above optimization (gcc/llvm also > has such peephole optimization). However, current peephole rules in C2 > compiler is very limited and I doubt whether it really takes effect - > AArch64 has disabled peephole optimizations. x86 has enabled it, but > the instruction sequences to be matched by the rules seems to be very > uncommon. > > To address issue A), since current spill/unspill are handled by common > MachSpillCopyNode, I was thinking if we could add peephole rule to > match MachSpillCopyNode, but MachSpillCopyNode has no operands (e.g. > mem, src, dst) like ordinary instruct defined in aarch64.ad. Even we > may extract them (mem, src, dst) like in > MachSpillCopyNode::implementation(), and even we can extend current > peephole rule grammar, expressing such extraction in peephole's > grammar is complex. > So I prefer adding following manually defined method peephole() to > MachSpillCopyNode: > > virtual MachNode *peephole(Block *block, int block_index, > PhaseRegAlloc *ra_, int &deleted); > > This makes the patch relative simple. My prototype patch for A) (still > some TODOs and hardcodes, but it works fine): > http://cr.openjdk.java.net/~zyao/RFC_A/ > > To address issue B) is somewhat complicated, we need to extend current > peephole rule syntax, as I don't think current simple syntax works for > any useful peephole optimizations like ldp/stp opt. > > My extended syntax - at least works for ldp/stp optimizations: > > ------ > peepmatch ( loadI loadI ); > peepconstraint (0.mem$base == 1.mem$base, 0.mem$scale == > 1.mem$scale, 0.mem$disp - 4 == 1.mem$disp, 0.dst != 1.dst); // new > grammar is described below. > peepreplace (loadPairI(1.mem 1.mem)) > ------ > > But for loadPairI, it is hard to express in current instruct semantic. > Because current instruct in aarch64.ad is defined by a match rule. The > match rule is an expression tree and made of Ideal Node. > However, LDP instruction doesn't have Ideal Node (say LoadPair) to > match. And adding load pair node to arch-independent Ideal node seems > strange. > > My proposed solution is: add a special arch dependent operand like iRegIpair: > > ------ > operand iRegIpair(iRegI reg1, iRegI reg2) > %{ > constraint(ALLOC_IN_RC(any_reg32)); > op_cost(0); > format %{ "pair: reg1, reg2"%}; // hard coded format for now. > interface(REG_INTER); > %} > ------ > > This needs to update ADLC to support iRegIpair operand. Because unlike > current operand which has 1 register, iRegIpair has 2. > > Then use it as loadPairI's operand type like: > > ------ > instruct loadPairI(indOffI mem, iRegIpair dst) > %{ > match(Set dst mem); //no Ideal Node in match rule. > ... > > %} > ------ > > Then we can use loadPairI in peephole rule's "peepreplace". > > Since only constraints between operands are supported in peephole > rule. But to check whether the adjacent loads are loaded from adjacent > memory address, we need to check operand's member, like (0.mem$disp - > 4 == 1.mem$disp), My solution is: add new grammar like 0.mem$disp to > extract member in operand in ADLC (peep_constraint_parse()). > > Another issue for peephole optimization is that it only matches > adjacent instructions in the same basic block. This leads to many > missing matches when loads are not scheduled to adjacent. > So I propose to delay peephole phase to the place just before final > code emit (the fill_buffer() function). This place is after > instruction scheduling. So after instruction scheduling, we could > match more adjacent loads. > > My draft patch to address B) is at: > http://cr.openjdk.java.net/~zyao/RFC_B/ > > What do you think? Welcome any feedback! > From stuart.monteith at linaro.org Fri Dec 22 13:41:36 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 22 Dec 2017 13:41:36 +0000 Subject: [aarch64-port-dev ] [10] RFR: 8193699: AArch64 Fails to build after 8167372 In-Reply-To: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> References: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> Message-ID: The code looks OK, AFAICT. Having done a search, your patch appears to cover all the relevant cases. Thanks, Stuart On 22 December 2017 at 09:35, Rahul Raghavan wrote: > Hi, > > Request help to review the following fix proposal. > > - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ > > Related links - > -- https://bugs.openjdk.java.net/browse/JDK-8193699 > -- https://bugs.openjdk.java.net/browse/JDK-8167372 > - 'Add code to check for getting oops while thread is in native' > -- https://bugs.openjdk.java.net/browse/JDK-8191227 > - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / > print_on() and LIR_Assembler::jobject2reg()' > > Found root cause of 8193699 issue, as missing changes for aarch64 in > 'macroAssembler_aarch64.cpp', > similar to changes done for 8191227 before pushing 8167372 support. > So now fixed the issue of unsafe handle resolution in > 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. > Stuart Monteith confirmed build failure fixed with above proposed changeset > and no new issues with testing. > > Thanks, > Rahul > From aph at redhat.com Fri Dec 22 16:02:28 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Dec 2017 16:02:28 +0000 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: Message-ID: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> Hi, On 22/12/17 08:02, Zhongwei Yao wrote: > My draft patch to address B) is at: > http://cr.openjdk.java.net/~zyao/RFC_B/ > > What do you think? Welcome any feedback! I wonder if merging ld/st pairs could be handled by the MacroAssembler. MachSpillCopyNode::peephole looks very complicated. If you handled ldp/stp conversion in MacroAssembler then it'd work everywhere, for any adjacent pair of loads or stores, not just for spills in C2. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Dec 22 16:07:40 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Dec 2017 16:07:40 +0000 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: Message-ID: On 22/12/17 11:45, Dmitry Chuyko wrote: > Is there a micro-benchmark or some sample program than shows better > performance on some hardware? > What are the numbers observed? It's hard to do that in a meaningful way with a micro-benchmark because the advantages of code size reduction don't apply except with larger programs. However, anything that reduces code size without adversely affecting anything else is worth having. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.x.ivanov at oracle.com Fri Dec 22 16:34:13 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 22 Dec 2017 19:34:13 +0300 Subject: [aarch64-port-dev ] [10] RFR: 8193699: AArch64 Fails to build after 8167372 In-Reply-To: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> References: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> Message-ID: <3baafded-6f14-2c79-8412-5192398331df@oracle.com> Looks good. Best regards, Vladimir Ivanov On 12/22/17 12:35 PM, Rahul Raghavan wrote: > Hi, > > Request help to review the following fix proposal. > > - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ > > Related links - > -- https://bugs.openjdk.java.net/browse/JDK-8193699 > -- https://bugs.openjdk.java.net/browse/JDK-8167372 > ? - 'Add code to check for getting oops while thread is in native' > -- https://bugs.openjdk.java.net/browse/JDK-8191227 > ? - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / > print_on() and LIR_Assembler::jobject2reg()' > > Found root cause of 8193699 issue, as missing changes for aarch64 in > 'macroAssembler_aarch64.cpp', > similar to changes done for 8191227 before pushing 8167372 support. > So now fixed the issue of unsafe handle resolution in > 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. > Stuart Monteith confirmed build failure fixed with above proposed > changeset and no new issues with testing. > > Thanks, > Rahul > From rahul.v.raghavan at oracle.com Fri Dec 22 17:55:22 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 22 Dec 2017 23:25:22 +0530 Subject: [aarch64-port-dev ] [10] RFR: 8193699: AArch64 Fails to build after 8167372 In-Reply-To: References: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> Message-ID: <85b644cd-efb1-6306-4316-866c07f770d9@oracle.com> Thank you Stuart. On Friday 22 December 2017 07:11 PM, Stuart Monteith wrote: > The code looks OK, AFAICT. Having done a search, your patch appears to > cover all the relevant cases. > > Thanks, > Stuart > > > On 22 December 2017 at 09:35, Rahul Raghavan > wrote: >> Hi, >> >> Request help to review the following fix proposal. >> >> - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ >> >> Related links - >> -- https://bugs.openjdk.java.net/browse/JDK-8193699 >> -- https://bugs.openjdk.java.net/browse/JDK-8167372 >> - 'Add code to check for getting oops while thread is in native' >> -- https://bugs.openjdk.java.net/browse/JDK-8191227 >> - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / >> print_on() and LIR_Assembler::jobject2reg()' >> >> Found root cause of 8193699 issue, as missing changes for aarch64 in >> 'macroAssembler_aarch64.cpp', >> similar to changes done for 8191227 before pushing 8167372 support. >> So now fixed the issue of unsafe handle resolution in >> 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. >> Stuart Monteith confirmed build failure fixed with above proposed changeset >> and no new issues with testing. >> >> Thanks, >> Rahul >> From rahul.v.raghavan at oracle.com Fri Dec 22 17:56:22 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 22 Dec 2017 23:26:22 +0530 Subject: [aarch64-port-dev ] [10] RFR: 8193699: AArch64 Fails to build after 8167372 In-Reply-To: <3baafded-6f14-2c79-8412-5192398331df@oracle.com> References: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> <3baafded-6f14-2c79-8412-5192398331df@oracle.com> Message-ID: <4565ea95-5080-5ff1-2d71-a020db476a1e@oracle.com> Thank you Vladimir. On Friday 22 December 2017 10:04 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 12/22/17 12:35 PM, Rahul Raghavan wrote: >> Hi, >> >> Request help to review the following fix proposal. >> >> - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ >> >> Related links - >> -- https://bugs.openjdk.java.net/browse/JDK-8193699 >> -- https://bugs.openjdk.java.net/browse/JDK-8167372 >> ?? - 'Add code to check for getting oops while thread is in native' >> -- https://bugs.openjdk.java.net/browse/JDK-8191227 >> ?? - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / >> print_on() and LIR_Assembler::jobject2reg()' >> >> Found root cause of 8193699 issue, as missing changes for aarch64 in >> 'macroAssembler_aarch64.cpp', >> similar to changes done for 8191227 before pushing 8167372 support. >> So now fixed the issue of unsafe handle resolution in >> 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. >> Stuart Monteith confirmed build failure fixed with above proposed >> changeset and no new issues with testing. >> >> Thanks, >> Rahul >> From ci_notify at linaro.org Sun Dec 24 09:23:26 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 24 Dec 2017 09:23:26 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <294235425.1126.1514107407532.JavaMail.jenkins@c5b43cbe6e9c> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/357/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/23 pass: 1,448; fail: 12 Build 1: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 2: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 3: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 4: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 5: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 7: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 Build 8: aarch64/2017/dec/09 pass: 1,584; fail: 10 Build 9: aarch64/2017/dec/11 pass: 1,584; fail: 10 Build 10: aarch64/2017/dec/13 pass: 1,585; fail: 9 Build 11: aarch64/2017/dec/15 pass: 1,588; fail: 10 Build 12: aarch64/2017/dec/17 pass: 1,597; fail: 11; error: 1 Build 13: aarch64/2017/dec/19 pass: 1,599; fail: 11 Build 14: aarch64/2017/dec/23 pass: 1,599; fail: 12 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/23 pass: 7,505; fail: 728; error: 22 Build 1: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 2: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 3: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 4: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 5: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 6: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 7: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 Build 8: aarch64/2017/dec/09 pass: 7,558; fail: 727; error: 22 Build 9: aarch64/2017/dec/11 pass: 7,559; fail: 732; error: 19 Build 10: aarch64/2017/dec/13 pass: 7,558; fail: 725; error: 27 Build 11: aarch64/2017/dec/15 pass: 7,569; fail: 741; error: 25 Build 12: aarch64/2017/dec/17 pass: 7,591; fail: 719; error: 26 Build 13: aarch64/2017/dec/19 pass: 7,572; fail: 740; error: 24 Build 14: aarch64/2017/dec/23 pass: 7,581; fail: 734; error: 20 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/23 pass: 3,817; fail: 5; error: 1 Build 1: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 2: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 3: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 4: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 5: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 6: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 7: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 Build 8: aarch64/2017/dec/09 pass: 3,830; fail: 4; error: 2 Build 9: aarch64/2017/dec/11 pass: 3,830; fail: 4; error: 1 Build 10: aarch64/2017/dec/13 pass: 3,831; fail: 4 Build 11: aarch64/2017/dec/15 pass: 3,835; fail: 3; error: 3 Build 12: aarch64/2017/dec/17 pass: 3,820; fail: 3; error: 3 Build 13: aarch64/2017/dec/19 pass: 3,819; fail: 3; error: 4 Build 14: aarch64/2017/dec/23 pass: 3,818; fail: 5; error: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/23 pass: 1,452; fail: 13 Build 1: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 2: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 3: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 4: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 5: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 6: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 7: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 Build 8: aarch64/2017/dec/09 pass: 1,588; fail: 10; error: 1 Build 9: aarch64/2017/dec/11 pass: 1,589; fail: 9; error: 1 Build 10: aarch64/2017/dec/13 pass: 1,589; fail: 9; error: 1 Build 11: aarch64/2017/dec/15 pass: 1,592; fail: 11 Build 12: aarch64/2017/dec/17 pass: 1,604; fail: 10 Build 13: aarch64/2017/dec/19 pass: 1,605; fail: 10 Build 14: aarch64/2017/dec/23 pass: 1,604; fail: 11; error: 1 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/23 pass: 7,502; fail: 728; error: 25 Build 1: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 2: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 3: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 4: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 5: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 6: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 7: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 Build 8: aarch64/2017/dec/09 pass: 7,570; fail: 716; error: 21 Build 9: aarch64/2017/dec/11 pass: 7,584; fail: 705; error: 21 Build 10: aarch64/2017/dec/13 pass: 7,577; fail: 713; error: 20 Build 11: aarch64/2017/dec/15 pass: 7,600; fail: 711; error: 24 Build 12: aarch64/2017/dec/17 pass: 7,593; fail: 721; error: 22 Build 13: aarch64/2017/dec/19 pass: 7,586; fail: 726; error: 24 Build 14: aarch64/2017/dec/23 pass: 7,596; fail: 717; error: 22 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/23 pass: 3,816; fail: 4; error: 3 Build 1: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 2: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 3: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 4: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 5: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 6: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 7: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Build 8: aarch64/2017/dec/09 pass: 3,832; fail: 3; error: 1 Build 9: aarch64/2017/dec/11 pass: 3,830; fail: 3; error: 2 Build 10: aarch64/2017/dec/13 pass: 3,830; fail: 4; error: 1 Build 11: aarch64/2017/dec/15 pass: 3,833; fail: 3; error: 5 Build 12: aarch64/2017/dec/17 pass: 3,822; fail: 3; error: 1 Build 13: aarch64/2017/dec/19 pass: 3,817; fail: 3; error: 6 Build 14: aarch64/2017/dec/23 pass: 3,819; fail: 5; error: 3 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.00x Relative performance: Server critical-jOPS (nc): 0.85x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 69.88, Server: 111.14 Client 69.88 / Client 2014-04-01 (43.00): 1.63x Server 111.14 / Server 2014-04-01 (71.00): 1.57x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-24 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/327/results/ 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ 2017-12-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/343/results/ 2017-12-12 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/345/results/ 2017-12-14 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/347/results/ 2017-12-16 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/349/results/ 2017-12-18 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/351/results/ 2017-12-20 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/353/results/ 2017-12-24 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/357/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From shade at redhat.com Sun Dec 24 15:33:14 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 24 Dec 2017 16:33:14 +0100 Subject: [aarch64-port-dev ] =?utf-8?q?Build_failure=3A_invalid_register_n?= =?utf-8?b?YW1lIGZvciDigJhyX2V4Y2hhbmdlX3ZhbHVl4oCZ?= In-Reply-To: <35857db7-dda5-fc07-9dfe-34534771b90c@redhat.com> References: <3e420e60-2945-7bc3-8eeb-0979d441377c@redhat.com> <35857db7-dda5-fc07-9dfe-34534771b90c@redhat.com> Message-ID: On 12/08/2017 06:54 PM, Andrew Haley wrote: > On 07/12/17 15:00, Aleksey Shipilev wrote: >> /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/hotspot/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp: >> In member function ?void AccessFlags::atomic_set_bits(jint)?: >> /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/hotspot/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp:128:18: >> error: invalid register name for ?r_exchange_value? >> register jint r_exchange_value asm("w0") = exchange_value; > > w0 is a legitimate register name. This is a bug in GCC. You can > try "x0" to see what happens. Indeed. The configure log identifies the smoking gun: while the builds is configured with aarch64 target, it still tries to use x86_64 compiler: configure: Using x86_64-linux-gnu-gcc-6 (Debian 6.3.0-18) 6.3.0 C compiler version 6.3.0 (located at /usr/bin/x86_64-linux-gnu-gcc-6) checking for aarch64-linux-gnu-/usr/bin/x86_64-linux-gnu-gcc-6... /usr/bin/x86_64-linux-gnu-gcc-6 ... A new configuration has been successfully created in /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/build/linux-aarch64-normal-server-fastdebug using configure arguments '--with-jtreg=jtreg/ --with-cacerts-file=/etc/ssl/certs/java/cacerts --with-freetype-include=/usr/include/freetype2/ --with-extra-cflags=-Wno-deprecated-declarations -Wno-maybe-uninitialized -Wno-misleading-indentation -Wno-shift-negative-value -Wno-deprecated --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu --with-freetype-lib=/usr/lib/aarch64-linux-gnu/'. Configuration summary: * Debug level: fastdebug * JDK variant: normal * JVM variants: server * OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64 Tools summary: * Boot JDK: openjdk version "1.8.0_151" OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-1~deb9u1-b12) OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode) (at /usr/lib/jvm/java-8-openjdk-amd64) * C Compiler: x86_64-linux-gnu-gcc-6 (Debian 6.3.0-18) 6.3.0 version 6.3.0 (at /usr/bin/x86_64-linux-gnu-gcc-6) * C++ Compiler: x86_64-linux-gnu-g++-6 (Debian 6.3.0-18) 6.3.0 version 6.3.0 (at /usr/bin/x86_64-linux-gnu-g++-6) This seems to only affect jdk8 builds on Debian 9 and GCC 6.3.0. Maybe there is some easy patch missing? Thanks, -Aleksey From shade at redhat.com Sun Dec 24 15:51:10 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 24 Dec 2017 16:51:10 +0100 Subject: [aarch64-port-dev ] =?utf-8?q?Build_failure=3A_invalid_register_n?= =?utf-8?b?YW1lIGZvciDigJhyX2V4Y2hhbmdlX3ZhbHVl4oCZ?= In-Reply-To: References: <3e420e60-2945-7bc3-8eeb-0979d441377c@redhat.com> <35857db7-dda5-fc07-9dfe-34534771b90c@redhat.com> Message-ID: <918a66b0-ace9-84fb-ac20-d73e2156887f@redhat.com> On 12/24/2017 04:33 PM, Aleksey Shipilev wrote: > On 12/08/2017 06:54 PM, Andrew Haley wrote: >> On 07/12/17 15:00, Aleksey Shipilev wrote: >>> /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/hotspot/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp: >>> In member function ?void AccessFlags::atomic_set_bits(jint)?: >>> /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/hotspot/src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp:128:18: >>> error: invalid register name for ?r_exchange_value? >>> register jint r_exchange_value asm("w0") = exchange_value; >> >> w0 is a legitimate register name. This is a bug in GCC. You can >> try "x0" to see what happens. > > Indeed. The configure log identifies the smoking gun: while the builds is configured with aarch64 > target, it still tries to use x86_64 compiler: > > configure: Using x86_64-linux-gnu-gcc-6 (Debian 6.3.0-18) 6.3.0 C compiler version 6.3.0 (located at > /usr/bin/x86_64-linux-gnu-gcc-6) > checking for aarch64-linux-gnu-/usr/bin/x86_64-linux-gnu-gcc-6... /usr/bin/x86_64-linux-gnu-gcc-6 > > ... > > A new configuration has been successfully created in > /pool/buildbot/slaves/sobornost/jdk8u-rh-int/build/build/linux-aarch64-normal-server-fastdebug > using configure arguments '--with-jtreg=jtreg/ --with-cacerts-file=/etc/ssl/certs/java/cacerts > --with-freetype-include=/usr/include/freetype2/ --with-extra-cflags=-Wno-deprecated-declarations > -Wno-maybe-uninitialized -Wno-misleading-indentation -Wno-shift-negative-value -Wno-deprecated > --with-debug-level=fastdebug --openjdk-target=aarch64-linux-gnu > --with-freetype-lib=/usr/lib/aarch64-linux-gnu/'. > > Configuration summary: > * Debug level: fastdebug > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: linux, CPU architecture: aarch64, address length: 64 > > Tools summary: > * Boot JDK: openjdk version "1.8.0_151" OpenJDK Runtime Environment (build > 1.8.0_151-8u151-b12-1~deb9u1-b12) OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode) (at > /usr/lib/jvm/java-8-openjdk-amd64) > * C Compiler: x86_64-linux-gnu-gcc-6 (Debian 6.3.0-18) 6.3.0 version 6.3.0 (at > /usr/bin/x86_64-linux-gnu-gcc-6) > * C++ Compiler: x86_64-linux-gnu-g++-6 (Debian 6.3.0-18) 6.3.0 version 6.3.0 (at > /usr/bin/x86_64-linux-gnu-g++-6) > > This seems to only affect jdk8 builds on Debian 9 and GCC 6.3.0. Maybe there is some easy patch missing? Prepending the explicit CC/CXX to configure seems to work: CC=aarch64-linux-gnu-gcc CXX=aarch64-linux-gnu-g++ sh ./configure ... -Aleksey From zhongwei.yao at linaro.org Tue Dec 26 04:23:33 2017 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Tue, 26 Dec 2017 12:23:33 +0800 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: Message-ID: Hi, Dmitry, Thanks for your feedback! For the performance, I have not noticed any changes in specjbb2015 with my patches. But as Andrew said, it is worth having because of better code size at least. On 22 December 2017 at 19:45, Dmitry Chuyko wrote: > Hi Zhongwei, > > I'm not a reviewer. Thank you, it is a great idea to merge loads or stores > that are issued sequentially. Can you share some more data on that? > > Is there a micro-benchmark or some sample program than shows better > performance on some hardware? > What are the numbers observed? > You mention SPECjbb, is it 2005 or 2015? Which configuration? > In SPECjbb dou you see most sequential series only related to stack work? > > -Dmitry > > > On 12/22/2017 11:02 AM, Zhongwei Yao wrote: >> >> Hi, >> >> We are planning to add AArch64 LDP/STP (load/store pair of registers) >> support in C2 code-gen for better performance. I think the LDP/STP can >> be used in following cases: >> A). For register spill/unspill. We've observed many sequential single >> stack load/store patterns in SPECjbb C2 generated code. >> B). Besides spilling, LDP is also not generated generally for multiple >> LoadI/LoadL nodes. Is there any risk (e.g. implicit check?) for >> combing them together, apart from alignment issue? >> >> I think peephole is the best fit for above optimization (gcc/llvm also >> has such peephole optimization). However, current peephole rules in C2 >> compiler is very limited and I doubt whether it really takes effect - >> AArch64 has disabled peephole optimizations. x86 has enabled it, but >> the instruction sequences to be matched by the rules seems to be very >> uncommon. >> >> To address issue A), since current spill/unspill are handled by common >> MachSpillCopyNode, I was thinking if we could add peephole rule to >> match MachSpillCopyNode, but MachSpillCopyNode has no operands (e.g. >> mem, src, dst) like ordinary instruct defined in aarch64.ad. Even we >> may extract them (mem, src, dst) like in >> MachSpillCopyNode::implementation(), and even we can extend current >> peephole rule grammar, expressing such extraction in peephole's >> grammar is complex. >> So I prefer adding following manually defined method peephole() to >> MachSpillCopyNode: >> >> virtual MachNode *peephole(Block *block, int block_index, >> PhaseRegAlloc *ra_, int &deleted); >> >> This makes the patch relative simple. My prototype patch for A) (still >> some TODOs and hardcodes, but it works fine): >> http://cr.openjdk.java.net/~zyao/RFC_A/ >> >> To address issue B) is somewhat complicated, we need to extend current >> peephole rule syntax, as I don't think current simple syntax works for >> any useful peephole optimizations like ldp/stp opt. >> >> My extended syntax - at least works for ldp/stp optimizations: >> >> ------ >> peepmatch ( loadI loadI ); >> peepconstraint (0.mem$base == 1.mem$base, 0.mem$scale == >> 1.mem$scale, 0.mem$disp - 4 == 1.mem$disp, 0.dst != 1.dst); // new >> grammar is described below. >> peepreplace (loadPairI(1.mem 1.mem)) >> ------ >> >> But for loadPairI, it is hard to express in current instruct semantic. >> Because current instruct in aarch64.ad is defined by a match rule. The >> match rule is an expression tree and made of Ideal Node. >> However, LDP instruction doesn't have Ideal Node (say LoadPair) to >> match. And adding load pair node to arch-independent Ideal node seems >> strange. >> >> My proposed solution is: add a special arch dependent operand like >> iRegIpair: >> >> ------ >> operand iRegIpair(iRegI reg1, iRegI reg2) >> %{ >> constraint(ALLOC_IN_RC(any_reg32)); >> op_cost(0); >> format %{ "pair: reg1, reg2"%}; // hard coded format for now. >> interface(REG_INTER); >> %} >> ------ >> >> This needs to update ADLC to support iRegIpair operand. Because unlike >> current operand which has 1 register, iRegIpair has 2. >> >> Then use it as loadPairI's operand type like: >> >> ------ >> instruct loadPairI(indOffI mem, iRegIpair dst) >> %{ >> match(Set dst mem); //no Ideal Node in match rule. >> ... >> >> %} >> ------ >> >> Then we can use loadPairI in peephole rule's "peepreplace". >> >> Since only constraints between operands are supported in peephole >> rule. But to check whether the adjacent loads are loaded from adjacent >> memory address, we need to check operand's member, like (0.mem$disp - >> 4 == 1.mem$disp), My solution is: add new grammar like 0.mem$disp to >> extract member in operand in ADLC (peep_constraint_parse()). >> >> Another issue for peephole optimization is that it only matches >> adjacent instructions in the same basic block. This leads to many >> missing matches when loads are not scheduled to adjacent. >> So I propose to delay peephole phase to the place just before final >> code emit (the fill_buffer() function). This place is after >> instruction scheduling. So after instruction scheduling, we could >> match more adjacent loads. >> >> My draft patch to address B) is at: >> http://cr.openjdk.java.net/~zyao/RFC_B/ >> >> What do you think? Welcome any feedback! >> > -- Best regards, Zhongwei From zhongwei.yao at linaro.org Tue Dec 26 04:24:42 2017 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Tue, 26 Dec 2017 12:24:42 +0800 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> References: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> Message-ID: Hi, Andrew, Thanks for your review! On 23 December 2017 at 00:02, Andrew Haley wrote: > Hi, > > On 22/12/17 08:02, Zhongwei Yao wrote: > >> My draft patch to address B) is at: >> http://cr.openjdk.java.net/~zyao/RFC_B/ >> >> What do you think? Welcome any feedback! > > I wonder if merging ld/st pairs could be handled by the > MacroAssembler. I was also thinking about merging it in assembler. My concern was that assembler usually does not do optimisation. However, I've taken a quick check and I think it should be doable in assembler. For example, we can merge ldr in assembler's ldr instruct definition by checking if the previous instruct meets the constraints. For the previous instruction, we can record it in Instruction_aarch64 class's destructor (if it is ld/st instruction, record it. if not, clear it.). What do you think? If it is OK, I'll work out a prototype for merging ldr in assembler. >MachSpillCopyNode::peephole looks very complicated. > If you handled ldp/stp conversion in MacroAssembler then it'd work > everywhere, for any adjacent pair of loads or stores, not just for > spills in C2. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- Best regards, Zhongwei From aph at redhat.com Tue Dec 26 10:13:48 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Dec 2017 10:13:48 +0000 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> Message-ID: On 26/12/17 04:24, Zhongwei Yao wrote: > I was also thinking about merging it in assembler. My concern was that > assembler usually does not do optimisation. > > However, I've taken a quick check and I think it should be doable in > assembler. For example, we can merge ldr in assembler's ldr instruct > definition by checking if the previous instruct meets the constraints. > For the previous instruction, we can record it in Instruction_aarch64 > class's destructor (if it is ld/st instruction, record it. if not, > clear it.). > > What do you think? If it is OK, I'll work out a prototype for merging > ldr in assembler. Try doing it in MacroAssembler. MacroAssembler::membar is an example of where we already merge instructions. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zhongwei.yao at linaro.org Wed Dec 27 04:05:29 2017 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Wed, 27 Dec 2017 12:05:29 +0800 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> Message-ID: OK, I'll give a try doing it in MacroAssembler. On 26 December 2017 at 18:13, Andrew Haley wrote: > On 26/12/17 04:24, Zhongwei Yao wrote: >> I was also thinking about merging it in assembler. My concern was that >> assembler usually does not do optimisation. >> >> However, I've taken a quick check and I think it should be doable in >> assembler. For example, we can merge ldr in assembler's ldr instruct >> definition by checking if the previous instruct meets the constraints. >> For the previous instruction, we can record it in Instruction_aarch64 >> class's destructor (if it is ld/st instruction, record it. if not, >> clear it.). >> >> What do you think? If it is OK, I'll work out a prototype for merging >> ldr in assembler. > > Try doing it in MacroAssembler. MacroAssembler::membar is an example of > where we already merge instructions. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- Best regards, Zhongwei From ci_notify at linaro.org Thu Dec 28 09:33:38 2017 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 28 Dec 2017 09:33:38 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1610204423.1436.1514453619143.JavaMail.jenkins@c5b43cbe6e9c> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2017/361/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/25 pass: 1,456; fail: 12; error: 1 Build 1: aarch64/2017/nov/27 pass: 1,457; fail: 11; error: 1 Build 2: aarch64/2017/nov/29 pass: 1,546; fail: 14 Build 3: aarch64/2017/dec/01 pass: 1,575; fail: 11 Build 4: aarch64/2017/dec/03 pass: 1,580; fail: 11 Build 5: aarch64/2017/dec/05 pass: 1,580; fail: 11 Build 6: aarch64/2017/dec/07 pass: 1,578; fail: 12; error: 1 Build 7: aarch64/2017/dec/09 pass: 1,584; fail: 10 Build 8: aarch64/2017/dec/11 pass: 1,584; fail: 10 Build 9: aarch64/2017/dec/13 pass: 1,585; fail: 9 Build 10: aarch64/2017/dec/15 pass: 1,588; fail: 10 Build 11: aarch64/2017/dec/17 pass: 1,597; fail: 11; error: 1 Build 12: aarch64/2017/dec/19 pass: 1,599; fail: 11 Build 13: aarch64/2017/dec/23 pass: 1,599; fail: 12 Build 14: aarch64/2017/dec/27 pass: 1,598; fail: 13 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/25 pass: 7,531; fail: 697; error: 27 Build 1: aarch64/2017/nov/27 pass: 7,507; fail: 730; error: 18 Build 2: aarch64/2017/nov/29 pass: 7,501; fail: 737; error: 18 Build 3: aarch64/2017/dec/01 pass: 7,501; fail: 735; error: 20 Build 4: aarch64/2017/dec/03 pass: 7,532; fail: 710; error: 23 Build 5: aarch64/2017/dec/05 pass: 7,510; fail: 732; error: 23 Build 6: aarch64/2017/dec/07 pass: 7,527; fail: 715; error: 23 Build 7: aarch64/2017/dec/09 pass: 7,558; fail: 727; error: 22 Build 8: aarch64/2017/dec/11 pass: 7,559; fail: 732; error: 19 Build 9: aarch64/2017/dec/13 pass: 7,558; fail: 725; error: 27 Build 10: aarch64/2017/dec/15 pass: 7,569; fail: 741; error: 25 Build 11: aarch64/2017/dec/17 pass: 7,591; fail: 719; error: 26 Build 12: aarch64/2017/dec/19 pass: 7,572; fail: 740; error: 24 Build 13: aarch64/2017/dec/23 pass: 7,581; fail: 734; error: 20 Build 14: aarch64/2017/dec/27 pass: 7,575; fail: 736; error: 24 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/25 pass: 3,818; fail: 4; error: 1 Build 1: aarch64/2017/nov/27 pass: 3,814; fail: 5; error: 4 Build 2: aarch64/2017/nov/29 pass: 3,820; fail: 3 Build 3: aarch64/2017/dec/01 pass: 3,818; fail: 3; error: 2 Build 4: aarch64/2017/dec/03 pass: 3,829; fail: 4; error: 1 Build 5: aarch64/2017/dec/05 pass: 3,828; fail: 4; error: 2 Build 6: aarch64/2017/dec/07 pass: 3,828; fail: 3; error: 3 Build 7: aarch64/2017/dec/09 pass: 3,830; fail: 4; error: 2 Build 8: aarch64/2017/dec/11 pass: 3,830; fail: 4; error: 1 Build 9: aarch64/2017/dec/13 pass: 3,831; fail: 4 Build 10: aarch64/2017/dec/15 pass: 3,835; fail: 3; error: 3 Build 11: aarch64/2017/dec/17 pass: 3,820; fail: 3; error: 3 Build 12: aarch64/2017/dec/19 pass: 3,819; fail: 3; error: 4 Build 13: aarch64/2017/dec/23 pass: 3,818; fail: 5; error: 4 Build 14: aarch64/2017/dec/27 pass: 3,821; fail: 5; error: 1 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/25 pass: 1,460; fail: 13; error: 1 Build 1: aarch64/2017/nov/27 pass: 1,460; fail: 13; error: 1 Build 2: aarch64/2017/nov/29 pass: 1,550; fail: 15 Build 3: aarch64/2017/dec/01 pass: 1,580; fail: 11 Build 4: aarch64/2017/dec/03 pass: 1,584; fail: 11; error: 1 Build 5: aarch64/2017/dec/05 pass: 1,585; fail: 10; error: 1 Build 6: aarch64/2017/dec/07 pass: 1,584; fail: 11; error: 1 Build 7: aarch64/2017/dec/09 pass: 1,588; fail: 10; error: 1 Build 8: aarch64/2017/dec/11 pass: 1,589; fail: 9; error: 1 Build 9: aarch64/2017/dec/13 pass: 1,589; fail: 9; error: 1 Build 10: aarch64/2017/dec/15 pass: 1,592; fail: 11 Build 11: aarch64/2017/dec/17 pass: 1,604; fail: 10 Build 12: aarch64/2017/dec/19 pass: 1,605; fail: 10 Build 13: aarch64/2017/dec/23 pass: 1,604; fail: 11; error: 1 Build 14: aarch64/2017/dec/27 pass: 1,603; fail: 12; error: 1 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/25 pass: 7,511; fail: 715; error: 29 Build 1: aarch64/2017/nov/27 pass: 7,528; fail: 705; error: 22 Build 2: aarch64/2017/nov/29 pass: 7,512; fail: 719; error: 25 Build 3: aarch64/2017/dec/01 pass: 7,526; fail: 708; error: 22 Build 4: aarch64/2017/dec/03 pass: 7,530; fail: 710; error: 25 Build 5: aarch64/2017/dec/05 pass: 7,529; fail: 716; error: 20 Build 6: aarch64/2017/dec/07 pass: 7,543; fail: 690; error: 32 Build 7: aarch64/2017/dec/09 pass: 7,570; fail: 716; error: 21 Build 8: aarch64/2017/dec/11 pass: 7,584; fail: 705; error: 21 Build 9: aarch64/2017/dec/13 pass: 7,577; fail: 713; error: 20 Build 10: aarch64/2017/dec/15 pass: 7,600; fail: 711; error: 24 Build 11: aarch64/2017/dec/17 pass: 7,593; fail: 721; error: 22 Build 12: aarch64/2017/dec/19 pass: 7,586; fail: 726; error: 24 Build 13: aarch64/2017/dec/23 pass: 7,596; fail: 717; error: 22 Build 14: aarch64/2017/dec/27 pass: 7,589; fail: 721; error: 25 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/nov/25 pass: 3,819; fail: 4 Build 1: aarch64/2017/nov/27 pass: 3,819; fail: 3; error: 1 Build 2: aarch64/2017/nov/29 pass: 3,819; fail: 3; error: 1 Build 3: aarch64/2017/dec/01 pass: 3,819; fail: 4 Build 4: aarch64/2017/dec/03 pass: 3,829; fail: 3; error: 2 Build 5: aarch64/2017/dec/05 pass: 3,829; fail: 4; error: 1 Build 6: aarch64/2017/dec/07 pass: 3,829; fail: 3; error: 2 Build 7: aarch64/2017/dec/09 pass: 3,832; fail: 3; error: 1 Build 8: aarch64/2017/dec/11 pass: 3,830; fail: 3; error: 2 Build 9: aarch64/2017/dec/13 pass: 3,830; fail: 4; error: 1 Build 10: aarch64/2017/dec/15 pass: 3,833; fail: 3; error: 5 Build 11: aarch64/2017/dec/17 pass: 3,822; fail: 3; error: 1 Build 12: aarch64/2017/dec/19 pass: 3,817; fail: 3; error: 6 Build 13: aarch64/2017/dec/23 pass: 3,819; fail: 5; error: 3 Build 14: aarch64/2017/dec/27 pass: 3,820; fail: 5; error: 2 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.86x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.93, Server: 114.76 Client 70.93 / Client 2014-04-01 (43.00): 1.65x Server 114.76 / Server 2014-04-01 (71.00): 1.62x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-11-26 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/329/results/ 2017-11-28 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/331/results/ 2017-11-30 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/333/results/ 2017-12-02 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/335/results/ 2017-12-04 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/337/results/ 2017-12-06 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/339/results/ 2017-12-08 pass rate: 11556/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/341/results/ 2017-12-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/343/results/ 2017-12-12 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/345/results/ 2017-12-14 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/347/results/ 2017-12-16 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/349/results/ 2017-12-18 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/351/results/ 2017-12-20 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/353/results/ 2017-12-24 pass rate: 11557/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/357/results/ 2017-12-28 pass rate: 11558/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2017/361/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From dmitrij.pochepko at bell-sw.com Thu Dec 28 14:03:35 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 28 Dec 2017 17:03:35 +0300 Subject: [aarch64-port-dev ] RFR(S): 8194256 - AARCH64: SIMD shift instructions are incorrectly encoded Message-ID: Hi all, please review small patch for 8194256 - AARCH64: SIMD shift instructions are incorrectly encoded I've noticed SIMD shift instructions wrong encoding when trying to use it. An intrinsic I was working on, generated incorrect assembly code with wrong shift value. Existing code just copy "shift" bits into instruction bits(immh:immb), however, according to spec, it should be encoded as follows: SIMD type : 8B when immh = 0001 , Q = 0 16B when immh = 0001 , Q = 1 4H when immh = 001x , Q = 0 8H when immh = 001x , Q = 1 2S when immh = 01xx , Q = 0 4S when immh = 01xx , Q = 1 2D when immh = 1xxx , Q = 1 is encoded as follows: for ushr and sshr: (16-UInt(immh:immb)) when immh = 0001 (32-UInt(immh:immb)) when immh = 001x (64-UInt(immh:immb)) when immh = 01xx (128-UInt(immh:immb)) when immh = 1xxx for shl: (UInt(immh:immb)-8) when immh = 0001 (UInt(immh:immb)-16) when immh = 001x (UInt(immh:immb)-32) when immh = 01xx (UInt(immh:immb)-64) when immh = 1xxx So, I've modified respective instruction generation code. webrev: http://cr.openjdk.java.net/~dpochepk/8194256/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8194256 I've checked this patch by generating intrinsic which use these instructions and verified assembly code. Thanks, Dmitrij From aph at redhat.com Fri Dec 29 10:27:20 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 Dec 2017 10:27:20 +0000 Subject: [aarch64-port-dev ] RFR(S): 8194256 - AARCH64: SIMD shift instructions are incorrectly encoded In-Reply-To: References: Message-ID: <42e77930-3021-e274-240c-7819eb3cfc1f@redhat.com> On 28/12/17 14:03, Dmitrij Pochepko wrote: > > webrev: http://cr.openjdk.java.net/~dpochepk/8194256/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8194256 > > > I've checked this patch by generating intrinsic which use these > instructions and verified assembly code. Great catch. (I'll note that this mistake would not have been possible with the integer instructions, which are tested against the GNU assembler's encodings whenever we run a debug build.) The resulting logic is complex and very difficult to understand, but I can see that's not your fault. Hopefully no-one will ever have to look at this code again. OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671