From ci_notify at linaro.org Fri Nov 2 01:43:21 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 2 Nov 2018 01:43:21 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <509977210.365.1541123001865.JavaMail.jenkins@eb8f9c77b024> 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/2018/305/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.63x Relative performance: Server critical-jOPS (nc): 8.31x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/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 Nov 3 02:56:08 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 3 Nov 2018 02:56:08 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1679970404.605.1541213769288.JavaMail.jenkins@eb8f9c77b024> 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/2018/306/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 7 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.71x Relative performance: Server critical-jOPS (nc): 8.36x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From adinn at redhat.com Mon Nov 5 08:38:05 2018 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 5 Nov 2018 08:38:05 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> Message-ID: <95b53b38-4d8d-8bb3-c7d1-b0874d3ba281@redhat.com> Hi Pengfei, On 24/10/18 14:54, Pengfei Li (Arm Technology China) wrote: . . . > Thanks again for your careful review. Please let me know if you have > some other suggestions. I am also ok with this patch as it stands (so it now has two reviews). As Andrew Haley said it doesn't look like it will offer any great performance benefit on its own but it should be easy to vectorize it as a follow-up step. I am happy to commit this patch on your behalf. However, it affects shared code, so it will need to be pushed to the submit repo and successfully built before it can be committed. I will do that now and let you know if there are any problems. 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 Mon Nov 5 09:23:50 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Nov 2018 09:23:50 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: <95b53b38-4d8d-8bb3-c7d1-b0874d3ba281@redhat.com> References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> <95b53b38-4d8d-8bb3-c7d1-b0874d3ba281@redhat.com> Message-ID: <73eb0738-b96f-cc66-8dbc-cb415f0f377a@redhat.com> On 11/05/2018 08:38 AM, Andrew Dinn wrote: > I am also ok with this patch as it stands (so it now has two reviews). > As Andrew Haley said it doesn't look like it will offer any great > performance benefit on its own but it should be easy to vectorize it as > a follow-up step. Let us do the vectorization now, while we've got the lid open. It should be pretty easy, given that {min,max} is associative, commutative, and in general behaves in the same way as addition. -- 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 Nov 6 02:31:20 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 6 Nov 2018 02:31:20 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <108577806.826.1541471481482.JavaMail.jenkins@eb8f9c77b024> 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/2018/309/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.66x Relative performance: Server critical-jOPS (nc): 8.31x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From mikael.vidstedt at oracle.com Tue Nov 6 21:00:51 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 6 Nov 2018 13:00:51 -0800 Subject: [aarch64-port-dev ] RFR(S): 8213436: Obsolete UseMembar Message-ID: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> Please review this change which obsoletes the UseMembar flag and removes the code that then becomes unreachable/dead. bug: https://bugs.openjdk.java.net/browse/JDK-8213436 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8213436/webrev.00/open/webrev/ * Background (from jbs) The UseMembar flag was deprecated in JDK 10, and is default true/enabled on all platforms since that same release. It should be obsoleted and the then dead serialization page functionality it controls should be removed. * Testing tier1. If anybody wants to take it for a spin on aarch64/ppc/s390/x86_32 that wouldn?t hurt. (Unrelated to this change: It would be really nice to clean up some of the (mostly) duplicated code in the os/signal handling area...) Cheers, Mikael From vladimir.kozlov at oracle.com Tue Nov 6 21:35:16 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 6 Nov 2018 13:35:16 -0800 Subject: [aarch64-port-dev ] RFR(S): 8213436: Obsolete UseMembar In-Reply-To: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> References: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> Message-ID: <2cf6a341-128f-f03e-c006-3a1717645d42@oracle.com> Nice cleanup. Thanks, Vladimir On 11/6/18 1:00 PM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the UseMembar flag and removes the code that then becomes unreachable/dead. > > bug: https://bugs.openjdk.java.net/browse/JDK-8213436 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8213436/webrev.00/open/webrev/ > > * Background (from jbs) > > The UseMembar flag was deprecated in JDK 10, and is default true/enabled on all platforms since that same release. It should be obsoleted and the then dead serialization page functionality it controls should be removed. > > > * Testing > > tier1. If anybody wants to take it for a spin on aarch64/ppc/s390/x86_32 that wouldn?t hurt. > > > (Unrelated to this change: It would be really nice to clean up some of the (mostly) duplicated code in the os/signal handling area...) > > Cheers, > Mikael > From david.holmes at oracle.com Tue Nov 6 22:20:49 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Nov 2018 08:20:49 +1000 Subject: [aarch64-port-dev ] RFR(S): 8213436: Obsolete UseMembar In-Reply-To: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> References: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> Message-ID: Hi Mikael, It is good to see a lot of complex code removed. Reviewed. Thanks, David On 7/11/2018 7:00 AM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the UseMembar flag and removes the code that then becomes unreachable/dead. > > bug: https://bugs.openjdk.java.net/browse/JDK-8213436 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8213436/webrev.00/open/webrev/ > > * Background (from jbs) > > The UseMembar flag was deprecated in JDK 10, and is default true/enabled on all platforms since that same release. It should be obsoleted and the then dead serialization page functionality it controls should be removed. > > > * Testing > > tier1. If anybody wants to take it for a spin on aarch64/ppc/s390/x86_32 that wouldn?t hurt. > > > (Unrelated to this change: It would be really nice to clean up some of the (mostly) duplicated code in the os/signal handling area...) > > Cheers, > Mikael > From Yang.Zhang at arm.com Wed Nov 7 07:07:23 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Wed, 7 Nov 2018 07:07:23 +0000 Subject: [aarch64-port-dev ] RFR(M): 8213134: AArch64: vector shift failed with MaxVectorSize=8 In-Reply-To: References: Message-ID: Hi, When I implemented AArch64 NEON for Vector API (http://openjdk.java.net/jeps/338), I found an issue about vector shift. I have a patch which could fix this issue. Could anyone help to review this patch? Webrev: http://cr.openjdk.java.net/~yzhang/8213134/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8213134 This patch is verified both in jdk/jdk master and panama/vectorIntrinsics, and tests are passed. The only concern is that extra instructions are needed for some test cases. For example: public static void aShiftRImm(int[] a, int b, int[] c) { for (int i = 0; i < a.length; i++) { c[i] = (int)(a[i] >> b); } } Without this patch, this method can be optimized by C2: 0x0000ffff84e75864: dup v16.16b, w10 0x0000ffff84e75868: neg v16.16b, v16.16b ------------------------------ only 1 neg instruction 0x0000ffff84e75878: ldr q17, [x12, #16] 0x0000ffff84e7587c: sshl v17.4s, v17.4s, v16.4s 0x0000ffff84e75884: str q17, [x10, #16] 0x0000ffff84e75888: ldr q17, [x12, #32] 0x0000ffff84e7588c: sshl v17.4s, v17.4s, v16.4s 0x0000ffff84e75890: str q17, [x10, #32] 0x0000ffff84e75894: ldr q17, [x12, #48] 0x0000ffff84e75898: sshl v17.4s, v17.4s, v16.4s 0x0000ffff84e7589c: str q17, [x10, #48] 0x0000ffff84e758a0: ldr q17, [x12, #64] 0x0000ffff84e758a4: sshl v17.4s, v17.4s, v16.4s 0x0000ffff84e758ac: str q17, [x10, #64] With this patch, this method can be optimized by C2: 0x0000ffff78e708e4: dup v16.16b, w10 0x0000ffff78e708f8: ldr q17, [x12, #16] 0x0000ffff78e708fc: neg v18.16b, v16.16b ------------------------------- 4 neg instructions 0x0000ffff78e70900: sshl v17.4s, v17.4s, v18.4s 0x0000ffff78e70908: str q17, [x10, #16] 0x0000ffff78e7090c: ldr q17, [x12, #32] 0x0000ffff78e70910: neg v18.16b, v16.16b 0x0000ffff78e70914: sshl v17.4s, v17.4s, v18.4s 0x0000ffff78e70918: str q17, [x10, #32] 0x0000ffff78e7091c: ldr q17, [x12, #48] 0x0000ffff78e70920: neg v18.16b, v16.16b 0x0000ffff78e70924: sshl v17.4s, v17.4s, v18.4s 0x0000ffff78e70928: str q17, [x10, #48] 0x0000ffff78e7092c: ldr q17, [x12, #64] 0x0000ffff78e70930: neg v18.16b, v16.16b 0x0000ffff78e70934: sshl v17.4s, v17.4s, v18.4s 0x0000ffff78e7093c: str q17, [x10, #64] Regards Yang From martin.doerr at sap.com Wed Nov 7 07:37:47 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Nov 2018 07:37:47 +0000 Subject: [aarch64-port-dev ] RFR(S): 8213436: Obsolete UseMembar In-Reply-To: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> References: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> Message-ID: <659d29c714cd498f89c94e0c3f5eb366@sap.com> Hi Mikael, looks good and builds on PPC64 and s390. Thanks, Martin -----Original Message----- From: s390x-port-dev On Behalf Of Mikael Vidstedt Sent: Dienstag, 6. November 2018 22:01 To: Hotspot dev runtime Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RFR(S): 8213436: Obsolete UseMembar Please review this change which obsoletes the UseMembar flag and removes the code that then becomes unreachable/dead. bug: https://bugs.openjdk.java.net/browse/JDK-8213436 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8213436/webrev.00/open/webrev/ * Background (from jbs) The UseMembar flag was deprecated in JDK 10, and is default true/enabled on all platforms since that same release. It should be obsoleted and the then dead serialization page functionality it controls should be removed. * Testing tier1. If anybody wants to take it for a spin on aarch64/ppc/s390/x86_32 that wouldn?t hurt. (Unrelated to this change: It would be really nice to clean up some of the (mostly) duplicated code in the os/signal handling area...) Cheers, Mikael From martin.doerr at sap.com Wed Nov 7 07:52:25 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 7 Nov 2018 07:52:25 +0000 Subject: [aarch64-port-dev ] RFR(S): 8213436: Obsolete UseMembar In-Reply-To: <659d29c714cd498f89c94e0c3f5eb366@sap.com> References: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> <659d29c714cd498f89c94e0c3f5eb366@sap.com> Message-ID: Hi again, I had started the wrong build on s390. Please fix os_linux_s390.cpp: You removed one "}" too much. (No need for a new webrev.) Best regards, Martin -----Original Message----- From: Doerr, Martin Sent: Mittwoch, 7. November 2018 08:38 To: 'Mikael Vidstedt' ; Hotspot dev runtime Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: RFR(S): 8213436: Obsolete UseMembar Hi Mikael, looks good and builds on PPC64 and s390. Thanks, Martin -----Original Message----- From: s390x-port-dev On Behalf Of Mikael Vidstedt Sent: Dienstag, 6. November 2018 22:01 To: Hotspot dev runtime Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RFR(S): 8213436: Obsolete UseMembar Please review this change which obsoletes the UseMembar flag and removes the code that then becomes unreachable/dead. bug: https://bugs.openjdk.java.net/browse/JDK-8213436 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8213436/webrev.00/open/webrev/ * Background (from jbs) The UseMembar flag was deprecated in JDK 10, and is default true/enabled on all platforms since that same release. It should be obsoleted and the then dead serialization page functionality it controls should be removed. * Testing tier1. If anybody wants to take it for a spin on aarch64/ppc/s390/x86_32 that wouldn?t hurt. (Unrelated to this change: It would be really nice to clean up some of the (mostly) duplicated code in the os/signal handling area...) Cheers, Mikael From adinn at redhat.com Wed Nov 7 11:38:44 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 7 Nov 2018 11:38:44 +0000 Subject: [aarch64-port-dev ] RFR(S): 8213436: Obsolete UseMembar In-Reply-To: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> References: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> Message-ID: Hi Mikael, On 06/11/18 21:00, Mikael Vidstedt wrote: > Please review this change which obsoletes the UseMembar flag and > removes the code that then becomes unreachable/dead. Yes, all looks good. > * Testing > > tier1. If anybody wants to take it for a spin on > aarch64/ppc/s390/x86_32 that wouldn?t hurt. I have built successfully on aarch64 and tier1 testing is in progress. I will let you know the results when it completes. regards, Andrew Dinn ----------- From ci_notify at linaro.org Thu Nov 8 02:20:18 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 8 Nov 2018 02:20:18 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1249705683.411.1541643618792.JavaMail.jenkins@eb8f9c77b024> 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/2018/311/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 Build 5: aarch64/2018/nov/07 pass: 5,470; fail: 20; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 Build 5: aarch64/2018/nov/07 pass: 8,526; fail: 664; error: 31 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 Build 5: aarch64/2018/nov/07 pass: 3,974; fail: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.71x Relative performance: Server critical-jOPS (nc): 8.31x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 198.8 Server 198.8 / Server 2014-04-01 (71.00): 2.80x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ 2018-11-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/311/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From Pengfei.Li at arm.com Thu Nov 8 02:49:57 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 8 Nov 2018 02:49:57 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: <95b53b38-4d8d-8bb3-c7d1-b0874d3ba281@redhat.com> References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> <95b53b38-4d8d-8bb3-c7d1-b0874d3ba281@redhat.com> Message-ID: Hi Andrew Dinn, > I am happy to commit this patch on your behalf. However, it affects shared > code, so it will need to be pushed to the submit repo and successfully built > before it can be committed. I will do that now and let you know if there are > any problems. Thanks for your help and sorry for my late reply. How is the build test from submit repo? Should I do a rebase now as this patch is on a codebase of several days ago? -- Thanks, Pengfei From adinn at redhat.com Thu Nov 8 09:20:54 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 8 Nov 2018 09:20:54 +0000 Subject: [aarch64-port-dev ] RFR(S): 8213436: Obsolete UseMembar In-Reply-To: References: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> Message-ID: <033c5351-5ccf-6743-2f4e-9393ca11f4c3@redhat.com> Hi Mikael, On 07/11/18 11:38, Andrew Dinn wrote: > On 06/11/18 21:00, Mikael Vidstedt wrote: >> Please review this change which obsoletes the UseMembar flag and >> removes the code that then becomes unreachable/dead. > > Yes, all looks good. > >> * Testing >> >> tier1. If anybody wants to take it for a spin on >> aarch64/ppc/s390/x86_32 that wouldn?t hurt. > > I have built successfully on aarch64 and tier1 testing is in progress. I > will let you know the results when it completes. tier1 tests showed no problems on AArch64. Reviewed! 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 mikael.vidstedt at oracle.com Thu Nov 8 19:48:22 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 8 Nov 2018 11:48:22 -0800 Subject: [aarch64-port-dev ] RFR(S): 8213436: Obsolete UseMembar In-Reply-To: <033c5351-5ccf-6743-2f4e-9393ca11f4c3@redhat.com> References: <0747F464-31EC-4C84-B1EE-B045315A4611@oracle.com> <033c5351-5ccf-6743-2f4e-9393ca11f4c3@redhat.com> Message-ID: <6C74FCB1-9EBC-45B0-B489-077921305667@oracle.com> I fixed (added back) the missing bracket in os_linux_s390.cpp and pushed. Thanks for the help reviewing and testing! Cheers, Mikael > On Nov 8, 2018, at 1:20 AM, Andrew Dinn wrote: > > Hi Mikael, > > On 07/11/18 11:38, Andrew Dinn wrote: >> On 06/11/18 21:00, Mikael Vidstedt wrote: >>> Please review this change which obsoletes the UseMembar flag and >>> removes the code that then becomes unreachable/dead. >> >> Yes, all looks good. >> >>> * Testing >>> >>> tier1. If anybody wants to take it for a spin on >>> aarch64/ppc/s390/x86_32 that wouldn?t hurt. >> >> I have built successfully on aarch64 and tier1 testing is in progress. I >> will let you know the results when it completes. > tier1 tests showed no problems on AArch64. > > Reviewed! > > 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 Fri Nov 9 01:53:38 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 9 Nov 2018 01:53:38 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <765530011.573.1541728419470.JavaMail.jenkins@eb8f9c77b024> 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/2018/312/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 Build 5: aarch64/2018/nov/07 pass: 5,470; fail: 20; not run: 90 Build 6: aarch64/2018/nov/08 pass: 5,469; fail: 22; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 Build 5: aarch64/2018/nov/07 pass: 8,526; fail: 664; error: 31 Build 6: aarch64/2018/nov/08 pass: 8,512; fail: 678; error: 31 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 Build 5: aarch64/2018/nov/07 pass: 3,974; fail: 5 Build 6: aarch64/2018/nov/08 pass: 3,974; fail: 5 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.66x Relative performance: Server critical-jOPS (nc): 8.27x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ 2018-11-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/311/results/ 2018-11-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/312/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 Nov 10 01:59:36 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 10 Nov 2018 01:59:36 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <488321675.843.1541815176955.JavaMail.jenkins@eb8f9c77b024> 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/2018/313/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 Build 5: aarch64/2018/nov/07 pass: 5,470; fail: 20; not run: 90 Build 6: aarch64/2018/nov/08 pass: 5,469; fail: 22; not run: 90 Build 7: aarch64/2018/nov/09 pass: 5,472; fail: 22; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 Build 5: aarch64/2018/nov/07 pass: 8,526; fail: 664; error: 31 Build 6: aarch64/2018/nov/08 pass: 8,512; fail: 678; error: 31 Build 7: aarch64/2018/nov/09 pass: 8,516; fail: 681; error: 27 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 Build 5: aarch64/2018/nov/07 pass: 3,974; fail: 5 Build 6: aarch64/2018/nov/08 pass: 3,974; fail: 5 Build 7: aarch64/2018/nov/09 pass: 3,977; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.71x Relative performance: Server critical-jOPS (nc): 8.52x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ 2018-11-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/311/results/ 2018-11-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/312/results/ 2018-11-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/313/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 Nov 10 19:07:14 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 10 Nov 2018 19:07:14 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 222 Failure Message-ID: <511055121.929.1541876835523.JavaMail.jenkins@eb8f9c77b024> OpenJDK AArch64 jdk/jdk build status is Failure Build details - https://ci.linaro.org/job/jdkX-ci-build/222/ Changes - shade: 18bd95c0e463dc755bf14a2acfabda734e04aa04 - src/hotspot/cpu/zero/assembler_zero.hpp --"8213711: Zero build broken after JDK-8213199 (GC abstraction for Assembler::needs_explicit_null_check()) Reviewed-by: rkennke, stuefe " Build output - Creating images/jmods/jdk.internal.le.jmod Creating images/jmods/jdk.internal.opt.jmod Creating images/jmods/jdk.internal.vm.ci.jmod Creating images/jmods/jdk.internal.vm.compiler.jmod Creating images/jmods/jdk.internal.vm.compiler.management.jmod Creating images/jmods/jdk.jartool.jmod Creating images/jmods/jdk.javadoc.jmod Creating images/jmods/jdk.jcmd.jmod Creating images/jmods/jdk.jconsole.jmod Creating images/jmods/jdk.jdeps.jmod Creating images/jmods/jdk.jdi.jmod Creating images/jmods/jdk.jdwp.agent.jmod Creating images/jmods/jdk.jfr.jmod Creating images/jmods/jdk.jshell.jmod Creating images/jmods/jdk.jsobject.jmod Creating images/jmods/jdk.jstatd.jmod Creating images/jmods/jdk.localedata.jmod Creating images/jmods/jdk.management.jmod Creating images/jmods/jdk.management.agent.jmod Creating images/jmods/jdk.management.jfr.jmod Creating images/jmods/jdk.naming.dns.jmod Creating images/jmods/jdk.naming.rmi.jmod Creating images/jmods/jdk.pack.jmod Creating images/jmods/jdk.net.jmod Creating images/jmods/jdk.rmic.jmod Creating images/jmods/jdk.scripting.nashorn.jmod Creating images/jmods/jdk.scripting.nashorn.shell.jmod Creating images/jmods/jdk.security.auth.jmod Creating images/jmods/jdk.sctp.jmod Creating images/jmods/jdk.security.jgss.jmod Creating images/jmods/jdk.unsupported.jmod Creating images/jmods/jdk.unsupported.desktop.jmod Creating images/jmods/jdk.xml.dom.jmod Creating images/jmods/jdk.zipfs.jmod Creating interim jimage Compiling 3 files for BUILD_DEMO_CodePointIM Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Compiling 30 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 4 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Compiling 8 files for BUILD_DEMO_TableExample Updating support/demos/image/jfc/TableExample/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar Creating support/demos/image/jfc/Metalworks/Metalworks.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Notepad/Notepad.jar Compiling 1 files for CLASSLIST_JAR Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Stylepad/Stylepad.jar Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating support/classlist.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar Creating images/jmods/jdk.jlink.jmod Creating images/jmods/java.base.jmod Creating jdk image Creating CDS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From aph at redhat.com Mon Nov 12 09:33:42 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Nov 2018 09:33:42 +0000 Subject: [aarch64-port-dev ] RFR(M): 8213134: AArch64: vector shift failed with MaxVectorSize=8 In-Reply-To: References: Message-ID: <14aefdac-23c2-32b6-b365-9a9bad121c7e@redhat.com> On 11/07/2018 07:07 AM, Yang Zhang (Arm Technology China) wrote: > When I implemented AArch64 NEON for Vector API (http://openjdk.java.net/jeps/338), I found an issue about vector shift. I have a patch which could fix this issue. Could anyone help to review this patch? What is our test coverage? Are all of the patterns tested? Thanks. -- 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 Nov 12 10:30:18 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 12 Nov 2018 10:30:18 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 226 Fixed Message-ID: <1545092373.1092.1542018619013.JavaMail.jenkins@eb8f9c77b024> OpenJDK AArch64 jdk/jdk build status is Fixed Build details - https://ci.linaro.org/job/jdkX-ci-build/226/ Changes - jlahoda: 1a6aeca4a8c976d79e9eb560e77b99a4de84a260 - test/langtools/tools/javac/processing/model/completionfailure/SymbolsDontCumulate.java - src/jdk.compiler/share/classes/com/sun/tools/javac/code/ClassFinder.java - src/jdk.compiler/share/classes/com/sun/tools/javac/code/DeferredCompletionFailureHandler.java --"8209055: c.s.t.javac.code.DeferredCompletionFailureHandler seems to use WeakHashMap incorrectly Summary: Do not keep speculative Symbols in DeferredCompletionFailureHandler. Reviewed-by: jjg, vromero " rraghavan: 43081c586d7704aac886e97f10577de4514b4199 - src/hotspot/share/code/codeBlob.hpp --"8210803: Compilation failure in codeBlob.cpp for Windows 32-bit Summary: Added ordinary operator delete declaration within class Reviewed-by: kvn, rlichten, thartmann " Build output - Creating images/jmods/jdk.internal.le.jmod Creating images/jmods/jdk.internal.opt.jmod Creating images/jmods/jdk.internal.vm.ci.jmod Creating images/jmods/jdk.internal.vm.compiler.jmod Creating images/jmods/jdk.internal.vm.compiler.management.jmod Creating images/jmods/jdk.jartool.jmod Creating images/jmods/jdk.javadoc.jmod Creating images/jmods/jdk.jcmd.jmod Creating images/jmods/jdk.jconsole.jmod Creating images/jmods/jdk.jdeps.jmod Creating images/jmods/jdk.jdi.jmod Creating images/jmods/jdk.jdwp.agent.jmod Creating images/jmods/jdk.jfr.jmod Creating images/jmods/jdk.jshell.jmod Creating images/jmods/jdk.jsobject.jmod Creating images/jmods/jdk.jstatd.jmod Creating images/jmods/jdk.localedata.jmod Creating images/jmods/jdk.management.jmod Creating images/jmods/jdk.management.agent.jmod Creating images/jmods/jdk.management.jfr.jmod Creating images/jmods/jdk.naming.dns.jmod Creating images/jmods/jdk.naming.rmi.jmod Creating images/jmods/jdk.net.jmod Creating images/jmods/jdk.pack.jmod Creating images/jmods/jdk.rmic.jmod Creating images/jmods/jdk.scripting.nashorn.jmod Creating images/jmods/jdk.scripting.nashorn.shell.jmod Creating images/jmods/jdk.sctp.jmod Creating images/jmods/jdk.security.auth.jmod Creating images/jmods/jdk.security.jgss.jmod Creating images/jmods/jdk.unsupported.jmod Creating images/jmods/jdk.unsupported.desktop.jmod Creating images/jmods/jdk.xml.dom.jmod Creating images/jmods/jdk.zipfs.jmod Creating interim jimage Compiling 3 files for BUILD_DEMO_CodePointIM Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Compiling 30 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 4 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 8 files for BUILD_DEMO_TableExample Updating support/demos/image/jfc/TableExample/src.zip Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 1 files for CLASSLIST_JAR Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar Creating support/demos/image/jfc/Metalworks/Metalworks.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Notepad/Notepad.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/classlist.jar Creating support/demos/image/jfc/Stylepad/Stylepad.jar Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar Creating images/jmods/jdk.jlink.jmod Creating images/jmods/java.base.jmod Creating jdk image Creating CDS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From Yang.Zhang at arm.com Tue Nov 13 01:27:20 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Tue, 13 Nov 2018 01:27:20 +0000 Subject: [aarch64-port-dev ] RFR(M): 8213134: AArch64: vector shift failed with MaxVectorSize=8 In-Reply-To: <14aefdac-23c2-32b6-b365-9a9bad121c7e@redhat.com> References: , <14aefdac-23c2-32b6-b365-9a9bad121c7e@redhat.com> Message-ID: <604ED3D6-94C6-4CC7-8DD5-08C3A616DBD7@arm.com> Hi Andrew Our test covers vector shift with imm, vector shift with vector(dump from scaler), vector shift with vector(from loading, this format isn?t supported by middle end). But we don?t test option MaxVectorSize=8. ???? iPhone > ? 2018?11?12??17:33?Andrew Haley ??? > >> On 11/07/2018 07:07 AM, Yang Zhang (Arm Technology China) wrote: >> When I implemented AArch64 NEON for Vector API (http://openjdk.java.net/jeps/338), I found an issue about vector shift. I have a patch which could fix this issue. Could anyone help to review this patch? > > What is our test coverage? Are all of the patterns tested? > > Thanks. > > -- > 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 Tue Nov 13 09:11:10 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Nov 2018 09:11:10 +0000 Subject: [aarch64-port-dev ] RFR(M): 8213134: AArch64: vector shift failed with MaxVectorSize=8 In-Reply-To: <604ED3D6-94C6-4CC7-8DD5-08C3A616DBD7@arm.com> References: <14aefdac-23c2-32b6-b365-9a9bad121c7e@redhat.com> <604ED3D6-94C6-4CC7-8DD5-08C3A616DBD7@arm.com> Message-ID: <8798cf81-b656-b88d-dc97-d805400bb462@redhat.com> On 11/13/2018 01:27 AM, Yang Zhang (Arm Technology China) wrote: > Our test covers vector shift with imm, vector shift with vector(dump from scaler), vector shift with vector(from loading, this format isn?t supported by middle end). But we don?t test option MaxVectorSize=8. Sorry, I didn't see the test. Where did you put it? -- 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 Tue Nov 13 16:40:00 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Nov 2018 16:40:00 +0000 Subject: [aarch64-port-dev ] RFR: AArch64: 8209415: Fix JVMTI test failure HS202 Message-ID: <5f2fd3f3-de58-a352-14f7-0d33f92371f5@redhat.com> In a moment of madness one of us (no names, no pack drill!) managed to translate from x86 __ cmpb(Address(rbcp, 0), Bytecodes::_invokestatic); __ jcc(Assembler::notEqual, L_done); to __ ldrb(rscratch1, Address(rbcp, 0)); __ cmpw(r1, Bytecodes::_invokestatic); __ br(Assembler::EQ, L_done); Two bugs in thee lines... fixed thusly. http://cr.openjdk.java.net/~aph/8209415/ OK for trunk and jdk8u ? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jcbeyler at google.com Tue Nov 13 16:54:51 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 13 Nov 2018 08:54:51 -0800 Subject: [aarch64-port-dev ] RFR: AArch64: 8209415: Fix JVMTI test failure HS202 In-Reply-To: <5f2fd3f3-de58-a352-14f7-0d33f92371f5@redhat.com> References: <5f2fd3f3-de58-a352-14f7-0d33f92371f5@redhat.com> Message-ID: Hi Andrew, Not a reviewer but had fun finding the two bugs before looking at the webrev :). Looks good to me! Jc On Tue, Nov 13, 2018 at 8:41 AM Andrew Haley wrote: > In a moment of madness one of us (no names, no pack drill!) managed > to translate from x86 > > __ cmpb(Address(rbcp, 0), Bytecodes::_invokestatic); > __ jcc(Assembler::notEqual, L_done); > > to > > __ ldrb(rscratch1, Address(rbcp, 0)); > __ cmpw(r1, Bytecodes::_invokestatic); > __ br(Assembler::EQ, L_done); > > Two bugs in thee lines... fixed thusly. > > http://cr.openjdk.java.net/~aph/8209415/ > > OK for trunk and jdk8u ? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -- Thanks, Jc From adinn at redhat.com Tue Nov 13 17:21:30 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 13 Nov 2018 17:21:30 +0000 Subject: [aarch64-port-dev ] RFR: AArch64: 8209415: Fix JVMTI test failure HS202 In-Reply-To: <5f2fd3f3-de58-a352-14f7-0d33f92371f5@redhat.com> References: <5f2fd3f3-de58-a352-14f7-0d33f92371f5@redhat.com> Message-ID: On 13/11/2018 16:40, Andrew Haley wrote: > In a moment of madness one of us (no names, no pack drill!) managed > to translate from x86 > > __ cmpb(Address(rbcp, 0), Bytecodes::_invokestatic); > __ jcc(Assembler::notEqual, L_done); > > to > > __ ldrb(rscratch1, Address(rbcp, 0)); > __ cmpw(r1, Bytecodes::_invokestatic); > __ br(Assembler::EQ, L_done); > > Two bugs in thee lines... fixed thusly. > > http://cr.openjdk.java.net/~aph/8209415/ > > OK for trunk and jdk8u ? Oh my goodness, that's a doozy. Amazing that it lay there for so long (the author seems to have checked it in in 2015 :-P ) Patch is good! 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 Tue Nov 13 18:12:12 2018 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Nov 2018 18:12:12 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8209415: Fix JVMTI test failure HS202 Message-ID: <201811131812.wADICC2M023345@aojmv0008.oracle.com> Changeset: e333239d5e9c Author: aph Date: 2018-11-13 11:21 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e333239d5e9c 8209415: Fix JVMTI test failure HS202 Summary: Fix test for static method in exception throw handler Reviewed-by: adinn ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp From aph at redhat.com Tue Nov 13 18:27:22 2018 From: aph at redhat.com (aph at redhat.com) Date: Tue, 13 Nov 2018 18:27:22 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 8209415: Fix JVMTI test failure HS202 Message-ID: <201811131827.wADIRM2V000950@aojmv0008.oracle.com> Changeset: c747935d0dc6 Author: aph Date: 2018-11-13 11:21 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/c747935d0dc6 8209415: Fix JVMTI test failure HS202 Summary: Fix test for static method in exception throw handler Reviewed-by: adinn ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp From ci_notify at linaro.org Wed Nov 14 00:06:31 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 14 Nov 2018 00:06:31 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 239 Failure Message-ID: <498029637.1193.1542153992303.JavaMail.jenkins@eb8f9c77b024> OpenJDK AArch64 jdk/jdk build status is Failure Build details - https://ci.linaro.org/job/jdkX-ci-build/239/ Changes - mikael: b091b768fea4f97e7abb2d1a03d8576c75f67457 - make/autoconf/version-numbers - make/conf/jib-profiles.js --"8213569: Bump minimum boot jdk to JDK 11 Reviewed-by: dholmes, tbell, erikj " Build output - Creating images/jmods/jdk.internal.le.jmod Creating images/jmods/jdk.internal.vm.ci.jmod Creating images/jmods/jdk.internal.opt.jmod Creating images/jmods/jdk.internal.vm.compiler.jmod Creating images/jmods/jdk.internal.vm.compiler.management.jmod Creating images/jmods/jdk.jartool.jmod Creating images/jmods/jdk.javadoc.jmod Creating images/jmods/jdk.jcmd.jmod Creating images/jmods/jdk.jconsole.jmod Creating images/jmods/jdk.jdeps.jmod Creating images/jmods/jdk.jdi.jmod Creating images/jmods/jdk.jdwp.agent.jmod Creating images/jmods/jdk.jfr.jmod Creating images/jmods/jdk.jshell.jmod Creating images/jmods/jdk.jsobject.jmod Creating images/jmods/jdk.jstatd.jmod Creating images/jmods/jdk.localedata.jmod Creating images/jmods/jdk.management.jmod Creating images/jmods/jdk.management.agent.jmod Creating images/jmods/jdk.management.jfr.jmod Creating images/jmods/jdk.naming.dns.jmod Creating images/jmods/jdk.naming.rmi.jmod Creating images/jmods/jdk.net.jmod Creating images/jmods/jdk.pack.jmod Creating images/jmods/jdk.rmic.jmod Creating images/jmods/jdk.scripting.nashorn.jmod Creating images/jmods/jdk.scripting.nashorn.shell.jmod Creating images/jmods/jdk.sctp.jmod Creating images/jmods/jdk.security.auth.jmod Creating images/jmods/jdk.security.jgss.jmod Creating images/jmods/jdk.unsupported.jmod Creating images/jmods/jdk.unsupported.desktop.jmod Creating images/jmods/jdk.zipfs.jmod Creating images/jmods/jdk.xml.dom.jmod Compiling 3 files for BUILD_DEMO_CodePointIM Creating interim jimage Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Compiling 30 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 4 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 8 files for BUILD_DEMO_TableExample Updating support/demos/image/jfc/TableExample/src.zip Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar Creating support/demos/image/jfc/Metalworks/Metalworks.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Notepad/Notepad.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Stylepad/Stylepad.jar Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Compiling 1 files for CLASSLIST_JAR Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar Creating support/classlist.jar Creating images/jmods/jdk.jlink.jmod Creating images/jmods/java.base.jmod Creating jdk image Creating CDS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From Yang.Zhang at arm.com Thu Nov 15 04:14:34 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Thu, 15 Nov 2018 04:14:34 +0000 Subject: [aarch64-port-dev ] RFR(M): 8213134: AArch64: vector shift failed with MaxVectorSize=8 In-Reply-To: <8798cf81-b656-b88d-dc97-d805400bb462@redhat.com> References: <14aefdac-23c2-32b6-b365-9a9bad121c7e@redhat.com> <604ED3D6-94C6-4CC7-8DD5-08C3A616DBD7@arm.com> <8798cf81-b656-b88d-dc97-d805400bb462@redhat.com> Message-ID: -----Original Message----- From: Andrew Haley Sent: Tuesday, November 13, 2018 5:11 PM To: Yang Zhang (Arm Technology China) Cc: aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR(M): 8213134: AArch64: vector shift failed with MaxVectorSize=8 On 11/13/2018 01:27 AM, Yang Zhang (Arm Technology China) wrote: >> Our test covers vector shift with imm, vector shift with vector(dump from scaler), vector shift with vector(from loading, this format isn?t supported by middle end). But we don?t test option MaxVectorSize=8. >Sorry, I didn't see the test. Where did you put it? It's my fault. I didn't explain it clearly. Hotspt jtreg contains the following test cases that can cover all the patterns of vector shift. But option "-XX:MaxVectorSize=8"(vecD 64-bit) isn't tested, so that only "-XX:MaxVectorSize=16"(vecX 128-bit, default) is tested. compiler/c2/cr6340864/TestByteVect.java compiler/c2/cr6340864/TestIntVect.java compiler/c2/cr6340864/TestShortVect.java compiler/codegen/TestCharVect2.java Do I need to add test option "-XX:MaxVectorSize=8" to jtreg test cases in my patch? Regards Yang -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Thu Nov 15 07:10:19 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 15 Nov 2018 07:10:19 +0000 Subject: [aarch64-port-dev ] [PING] RE: RFR(M): 8212043: Add floating-point Math.min/max intrinsics Message-ID: [PING] How is the commit process going? I didn't find this change in latest jdk master. > > I am happy to commit this patch on your behalf. However, it affects > > shared code, so it will need to be pushed to the submit repo and > > successfully built before it can be committed. I will do that now and > > let you know if there are any problems. > > Thanks for your help and sorry for my late reply. > How is the build test from submit repo? Should I do a rebase now as this > patch is on a codebase of several days ago? > -- Thanks, Pengfei From aph at redhat.com Thu Nov 15 08:44:01 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Nov 2018 08:44:01 +0000 Subject: [aarch64-port-dev ] RFR(M): 8213134: AArch64: vector shift failed with MaxVectorSize=8 In-Reply-To: References: <14aefdac-23c2-32b6-b365-9a9bad121c7e@redhat.com> <604ED3D6-94C6-4CC7-8DD5-08C3A616DBD7@arm.com> <8798cf81-b656-b88d-dc97-d805400bb462@redhat.com> Message-ID: <21e76ad2-c264-752c-c991-16e0c39e7be7@redhat.com> On 11/15/18 4:14 AM, Yang Zhang (Arm Technology China) wrote: > It's my fault. I didn't explain it clearly. > Hotspt jtreg contains the following test cases that can cover all the patterns of vector shift. But option "-XX:MaxVectorSize=8"(vecD 64-bit) isn't tested, so that only "-XX:MaxVectorSize=16"(vecX 128-bit, default) is tested. > compiler/c2/cr6340864/TestByteVect.java > compiler/c2/cr6340864/TestIntVect.java > compiler/c2/cr6340864/TestShortVect.java > compiler/codegen/TestCharVect2.java > > Do I need to add test option "-XX:MaxVectorSize=8" to jtreg test cases in my patch? I think you do, yes. Thanks. And please send it to hotspot-dev. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Yang.Zhang at arm.com Fri Nov 16 02:05:26 2018 From: Yang.Zhang at arm.com (Yang Zhang (Arm Technology China)) Date: Fri, 16 Nov 2018 02:05:26 +0000 Subject: [aarch64-port-dev ] RFR(M): 8213134: AArch64: vector shift failed with MaxVectorSize=8 In-Reply-To: <21e76ad2-c264-752c-c991-16e0c39e7be7@redhat.com> References: <14aefdac-23c2-32b6-b365-9a9bad121c7e@redhat.com> <604ED3D6-94C6-4CC7-8DD5-08C3A616DBD7@arm.com> <8798cf81-b656-b88d-dc97-d805400bb462@redhat.com> <21e76ad2-c264-752c-c991-16e0c39e7be7@redhat.com> Message-ID: >> >> Do I need to add test option "-XX:MaxVectorSize=8" to jtreg test cases in my patch? > I think you do, yes. Thanks. And please send it to hotspot-dev. Thanks. I will update the patch and send it to hotspot-dev. -- 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 Nov 19 17:28:16 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 19 Nov 2018 17:28:16 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 289 Fixed Message-ID: <1003308498.297.1542648497080.JavaMail.jenkins@797da5e41941> OpenJDK AArch64 jdk/jdk build status is Fixed Build details - https://ci.linaro.org/job/jdkX-ci-build/289/ Changes - erikj: 7ac273f045e3bfb150d7a9d1be8a9382c3796d83 - doc/building.html - doc/building.md --"8214062: JDK-8167368 Leftover: get_source.sh in build documentation Reviewed-by: dholmes, erikj Contributed-by: merkel05 at gmail.com " Build output - Creating images/jmods/jdk.internal.le.jmod Creating images/jmods/jdk.internal.opt.jmod Creating images/jmods/jdk.internal.vm.ci.jmod Creating images/jmods/jdk.internal.vm.compiler.jmod Creating images/jmods/jdk.internal.vm.compiler.management.jmod Creating images/jmods/jdk.jartool.jmod Creating images/jmods/jdk.javadoc.jmod Creating images/jmods/jdk.jcmd.jmod Creating images/jmods/jdk.jconsole.jmod Creating images/jmods/jdk.jdeps.jmod Creating images/jmods/jdk.jdi.jmod Creating images/jmods/jdk.jdwp.agent.jmod Creating images/jmods/jdk.jfr.jmod Creating images/jmods/jdk.jshell.jmod Creating images/jmods/jdk.jsobject.jmod Creating images/jmods/jdk.jstatd.jmod Creating images/jmods/jdk.localedata.jmod Creating images/jmods/jdk.management.jmod Creating images/jmods/jdk.management.agent.jmod Creating images/jmods/jdk.management.jfr.jmod Creating images/jmods/jdk.naming.dns.jmod Creating images/jmods/jdk.naming.rmi.jmod Creating images/jmods/jdk.net.jmod Creating images/jmods/jdk.pack.jmod Creating images/jmods/jdk.rmic.jmod Creating images/jmods/jdk.scripting.nashorn.shell.jmod Creating images/jmods/jdk.scripting.nashorn.jmod Creating images/jmods/jdk.sctp.jmod Creating images/jmods/jdk.security.auth.jmod Creating images/jmods/jdk.security.jgss.jmod Creating images/jmods/jdk.unsupported.jmod Creating images/jmods/jdk.unsupported.desktop.jmod Creating images/jmods/jdk.xml.dom.jmod Creating images/jmods/jdk.zipfs.jmod Creating interim jimage Compiling 3 files for BUILD_DEMO_CodePointIM Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Compiling 30 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 4 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Compiling 8 files for BUILD_DEMO_TableExample Updating support/demos/image/jfc/TableExample/src.zip Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Compiling 1 files for CLASSLIST_JAR Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Creating support/demos/image/jfc/Metalworks/Metalworks.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Notepad/Notepad.jar Creating support/classlist.jar Creating support/demos/image/jfc/Stylepad/Stylepad.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar Creating images/jmods/jdk.jlink.jmod Creating images/jmods/java.base.jmod Creating jdk image Creating CDS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From ci_notify at linaro.org Tue Nov 20 02:37:37 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 20 Nov 2018 02:37:37 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <923754212.396.1542681457729.JavaMail.jenkins@797da5e41941> 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/2018/323/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 Build 5: aarch64/2018/nov/07 pass: 5,470; fail: 20; not run: 90 Build 6: aarch64/2018/nov/08 pass: 5,469; fail: 22; not run: 90 Build 7: aarch64/2018/nov/09 pass: 5,472; fail: 22; not run: 90 Build 8: aarch64/2018/nov/12 pass: 5,474; fail: 20; not run: 90 Build 9: aarch64/2018/nov/19 pass: 5,426; fail: 65; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 Build 5: aarch64/2018/nov/07 pass: 8,526; fail: 664; error: 31 Build 6: aarch64/2018/nov/08 pass: 8,512; fail: 678; error: 31 Build 7: aarch64/2018/nov/09 pass: 8,516; fail: 681; error: 27 Build 8: aarch64/2018/nov/12 pass: 8,507; fail: 685; error: 34 Build 9: aarch64/2018/nov/19 pass: 8,520; fail: 682; error: 26 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 Build 5: aarch64/2018/nov/07 pass: 3,974; fail: 5 Build 6: aarch64/2018/nov/08 pass: 3,974; fail: 5 Build 7: aarch64/2018/nov/09 pass: 3,977; fail: 4 Build 8: aarch64/2018/nov/12 pass: 3,979; fail: 5 Build 9: aarch64/2018/nov/19 pass: 3,980; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.83x Relative performance: Server critical-jOPS (nc): 8.41x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ 2018-11-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/311/results/ 2018-11-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/312/results/ 2018-11-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/313/results/ 2018-11-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/316/results/ 2018-11-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/323/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From Derek.White at cavium.com Tue Nov 20 22:12:34 2018 From: Derek.White at cavium.com (White, Derek) Date: Tue, 20 Nov 2018 22:12:34 +0000 Subject: [aarch64-port-dev ] JEP: 342: Limit Speculative Execution - on aarch64? Message-ID: Hi porters, Re - JEP 342: Limit Speculative Execution https://bugs.openjdk.java.net/browse/JDK-8207206 JEP 342 proposes that we simply build an alternative "non-speculative" JVM by compiling with gcc options: -mindirect-branch=thunk -mfunction-return=thunk -mindirect-branch-register These options are x86 only. I've asked Jesper to update the JEP to mention this. I don't have a firm mapping in my mind between each Spectre variant and each mitigation, and the equivalency (or not) between the x86 and aarch64 mitigations, and what needs to be handled at user-level vs. in the kernel. But it seems that JEP 342 is trying to mitigate Spectre variant 2, but aarch64 handles Spectre Variant 2 purely in kernel/firmware(?). Are we safe then? Or do want to do anything special for building a non-speculative JVM for aarch64? Is the "-mtrack-speculation" option appropriate? Sufficient? Thanks, - Derek BTW - The JEP also mentions that the JIT compilers will need to be updated similarly, but no details are given. This will also be cpu-specific (and potentially more work). -----Original Message----- From: White, Derek Sent: Tuesday, November 20, 2018 4:43 PM To: jdk-dev at openjdk.java.net; jesper.wilhelmsson at oracle.com Subject: RE: JEP: 342: Limit Speculative Execution Hi Jesper, [Sorry for the "timely" response.] Although the mechanisms for managing and identifying an alternative JVM are not platform-specific, the mitigation strategy proposed (e.g. the specific gcc options) are x86-specific. I suggest adding a note in the JEP that the specific mitigations proposed are x86 specific, and that other ports will need to identify what mitigations are appropriate (if any). I'll start up a discussion in the aarch64 list on what we should do about limiting speculative execution, and we may link aarch64-specific enhancements to this JEP. This needs to be looked at for both C++ options and JIT implementation on aarch64. Thanks, - Derek > -----Original Message----- > From: jdk-dev On Behalf Of > mark.reinhold at oracle.com > Sent: Friday, September 07, 2018 1:53 PM > To: jesper.wilhelmsson at oracle.com > Cc: jdk-dev at openjdk.java.net > Subject: New candidate JEP: 342: Limit Speculative Execution > > External Email > > http://openjdk.java.net/jeps/342 > > - Mark From adinn at redhat.com Wed Nov 21 11:21:30 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 21 Nov 2018 11:21:30 +0000 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <99bf9bdc-b758-6516-dee5-8914739ec925@redhat.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> <1b770596-8da2-74be-bad2-832bf4a6622a@redhat.com> <978ebf83-1c79-6310-c2ae-abc283552ce6@bell-sw.com> <99bf9bdc-b758-6516-dee5-8914739ec925@redhat.com> Message-ID: <928feede-1f2a-3ec6-7b90-f9761bb2959d@redhat.com> Hello Dmitrij, On 29/10/2018 09:00, Andrew Dinn wrote: > Ok. I'll try to work through this as quick as possible but it may take a > day or two. Apologies for the delay in reviewing this patch. The new code looks to be ok. However, I have a found a number of places where the new algorithm needs to be corrected to match the code or, at least, explain it more clearly. I also spotted a couple of errors in the comments I added to the original C code (mea culpa). Unfortunately, I am still only about 2/3rds of the way through reviewing the algorithm. I am afraid have been sidetracked by lots of other tasks that are more urgent, some of them still in progress. I'll come back to this as soon as I can but it may take a week or two. Sorry for keeping this patch pending. 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 Thu Nov 22 01:34:06 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 22 Nov 2018 01:34:06 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1609111258.171.1542850447324.JavaMail.jenkins@797da5e41941> 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/2018/325/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 Build 5: aarch64/2018/nov/07 pass: 5,470; fail: 20; not run: 90 Build 6: aarch64/2018/nov/08 pass: 5,469; fail: 22; not run: 90 Build 7: aarch64/2018/nov/09 pass: 5,472; fail: 22; not run: 90 Build 8: aarch64/2018/nov/12 pass: 5,474; fail: 20; not run: 90 Build 9: aarch64/2018/nov/19 pass: 5,426; fail: 65; not run: 90 Build 10: aarch64/2018/nov/21 pass: 5,426; fail: 66; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 Build 5: aarch64/2018/nov/07 pass: 8,526; fail: 664; error: 31 Build 6: aarch64/2018/nov/08 pass: 8,512; fail: 678; error: 31 Build 7: aarch64/2018/nov/09 pass: 8,516; fail: 681; error: 27 Build 8: aarch64/2018/nov/12 pass: 8,507; fail: 685; error: 34 Build 9: aarch64/2018/nov/19 pass: 8,520; fail: 682; error: 26 Build 10: aarch64/2018/nov/21 pass: 8,516; fail: 689; error: 31 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 Build 5: aarch64/2018/nov/07 pass: 3,974; fail: 5 Build 6: aarch64/2018/nov/08 pass: 3,974; fail: 5 Build 7: aarch64/2018/nov/09 pass: 3,977; fail: 4 Build 8: aarch64/2018/nov/12 pass: 3,979; fail: 5 Build 9: aarch64/2018/nov/19 pass: 3,980; fail: 4 Build 10: aarch64/2018/nov/21 pass: 3,982; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.77x Relative performance: Server critical-jOPS (nc): 8.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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 201.64 Server 201.64 / Server 2014-04-01 (71.00): 2.84x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ 2018-11-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/311/results/ 2018-11-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/312/results/ 2018-11-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/313/results/ 2018-11-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/316/results/ 2018-11-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/323/results/ 2018-11-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/325/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 Fri Nov 23 11:46:33 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 23 Nov 2018 11:46:33 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far Message-ID: Hello, I thought I'd update where I am with ZGC. The C1 code seems to be mostly working. I had an issue where ZMarkStack was stripping off the top two bits of the 64-bit addresses, which is where I've put the thread colours to avoid tags in MTE. I've added some support for C2 to the ZGC code. There are some issues, however, with the graph. As before the 64-bit Literal oops support patch is needed: http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ The patchset is here: http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ To run with ZGC enabled, you'll need to pass: -XX:+UnlockExperimentalVMOptions -XX:+UseZGC I've included a test case here: http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ Which can be executed with or without "-XX:+UseBarriersForVolatile" to reproduce two different errors. With that option I see: # Internal Error (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, tid=17048 # assert(C->node_arena()->contains(s->_leaf) || !has_new_node(s->_leaf)) failed: duplicating node that's already been matched and without I see: # Internal Error (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, tid=3503 # assert(ldst->trailing_membar() != __null) failed: expected trailing membar This is due to a combination of the graph generated in ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier handling in aarch64.ad that Roland recently changed in "8209420: Track membars for volatile accesses so they can be properly optimized". This is easily triggered in the C2Example.java file I've linked to above, where calls to Unsafe.compareAndSwapObject provoke the issue. I'm trying to unpick the problems with the graph - I've uploaded the replay, hs_err and ideal graph xml files of runs with and without +UseBarriersForVolatile, in case someone could provide some insight. BR, Stuart From aph at redhat.com Fri Nov 23 13:00:27 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Nov 2018 13:00:27 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: On 11/23/18 11:46 AM, Stuart Monteith wrote: > This is due to a combination of the graph generated in > ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier > handling in aarch64.ad that Roland recently changed in "8209420: Track > membars for volatile accesses so they can be properly optimized". This > is easily triggered in the C2Example.java file I've linked to above, > where calls to Unsafe.compareAndSwapObject provoke the issue. Does it work with UseBarriersForVolatile? -- 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 Nov 23 13:48:24 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 23 Nov 2018 13:48:24 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: Hi, I get different errors - with UseBarriersForVolatile I get: # assert(C->node_arena()->contains(s->_leaf) || !has_new_node(s->_leaf)) failed: duplicating node that's already been matched without I get: # assert(ldst->trailing_membar() != __null) failed: expected trailing membar BR, Stuart On Fri, 23 Nov 2018 at 13:00, Andrew Haley wrote: > > On 11/23/18 11:46 AM, Stuart Monteith wrote: > > This is due to a combination of the graph generated in > > ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier > > handling in aarch64.ad that Roland recently changed in "8209420: Track > > membars for volatile accesses so they can be properly optimized". This > > is easily triggered in the C2Example.java file I've linked to above, > > where calls to Unsafe.compareAndSwapObject provoke the issue. > > Does it work with UseBarriersForVolatile? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Nov 23 14:50:26 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 23 Nov 2018 14:50:26 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: <780e5bca-b585-fb4a-cc58-1fa2b0eeb5c2@redhat.com> On 23/11/2018 11:46, Stuart Monteith wrote: > This is due to a combination of the graph generated in > ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier > handling in aarch64.ad that Roland recently changed in "8209420: Track > membars for volatile accesses so they can be properly optimized". This > is easily triggered in the C2Example.java file I've linked to above, > where calls to Unsafe.compareAndSwapObject provoke the issue. I can see why this is going wrong when UseBarriersForVolatile is false. Roland's patch ensures that the Release and Acquire membars which bracket a CompareAndSwap node are cross-linked and that the CAS feeds the Acquire. This is needed to allow the membars to be translated to empty instruction sequence iff the CompareAndSwap node translates to ldaxr/stlxr or to hw cas. The alternative sequence is dmb ldaxr stxr dmb. ZGC is breaking this because it's way of adding a barrier around the CompareAndSwap node involves planting a secondary CAS. It tries the CAS once and, if it fails, massages the compared pointer and executes the second CAS on the assumption that the compare might include stale pointer bits. With the current implementation only one of these CASes can be tracked between the point where the leading and trailing barriers are planted. The result is that the secondary CompareAndSwap node is linked to the trailing membar but the primary CAS is left dangling with no such link. Hence the assert. I'm not sure why this fails when UseBarriersForVolatile is true. However, it may be that the linking of the Acquire as a direct feed of the secondary CAS is a problem. That CAS is only executed conditionally on the first CAS failing. If the memory flow is not ordered correctly then this might risk allowing the first CAS to complete and bypass the necessary trailing dmb. I could struggle through this code but it is probably best to ask Roland to look at it. regards, Andrew Dinn ----------- From ci_notify at linaro.org Sat Nov 24 01:43:40 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 24 Nov 2018 01:43:40 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1603801263.623.1543023821326.JavaMail.jenkins@797da5e41941> 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/2018/327/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 Build 5: aarch64/2018/nov/07 pass: 5,470; fail: 20; not run: 90 Build 6: aarch64/2018/nov/08 pass: 5,469; fail: 22; not run: 90 Build 7: aarch64/2018/nov/09 pass: 5,472; fail: 22; not run: 90 Build 8: aarch64/2018/nov/12 pass: 5,474; fail: 20; not run: 90 Build 9: aarch64/2018/nov/19 pass: 5,426; fail: 65; not run: 90 Build 10: aarch64/2018/nov/21 pass: 5,426; fail: 66; not run: 90 Build 11: aarch64/2018/nov/23 pass: 5,426; fail: 68; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 Build 5: aarch64/2018/nov/07 pass: 8,526; fail: 664; error: 31 Build 6: aarch64/2018/nov/08 pass: 8,512; fail: 678; error: 31 Build 7: aarch64/2018/nov/09 pass: 8,516; fail: 681; error: 27 Build 8: aarch64/2018/nov/12 pass: 8,507; fail: 685; error: 34 Build 9: aarch64/2018/nov/19 pass: 8,520; fail: 682; error: 26 Build 10: aarch64/2018/nov/21 pass: 8,516; fail: 689; error: 31 Build 11: aarch64/2018/nov/23 pass: 8,541; fail: 672; error: 24 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 Build 5: aarch64/2018/nov/07 pass: 3,974; fail: 5 Build 6: aarch64/2018/nov/08 pass: 3,974; fail: 5 Build 7: aarch64/2018/nov/09 pass: 3,977; fail: 4 Build 8: aarch64/2018/nov/12 pass: 3,979; fail: 5 Build 9: aarch64/2018/nov/19 pass: 3,980; fail: 4 Build 10: aarch64/2018/nov/21 pass: 3,982; fail: 4 Build 11: aarch64/2018/nov/23 pass: 3,983; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.74x Relative performance: Server critical-jOPS (nc): 8.39x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ 2018-11-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/311/results/ 2018-11-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/312/results/ 2018-11-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/313/results/ 2018-11-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/316/results/ 2018-11-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/323/results/ 2018-11-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/325/results/ 2018-11-24 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/327/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 Tue Nov 27 02:31:13 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 27 Nov 2018 02:31:13 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <278653906.981.1543285873866.JavaMail.jenkins@797da5e41941> 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/2018/330/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 Build 5: aarch64/2018/nov/07 pass: 5,470; fail: 20; not run: 90 Build 6: aarch64/2018/nov/08 pass: 5,469; fail: 22; not run: 90 Build 7: aarch64/2018/nov/09 pass: 5,472; fail: 22; not run: 90 Build 8: aarch64/2018/nov/12 pass: 5,474; fail: 20; not run: 90 Build 9: aarch64/2018/nov/19 pass: 5,426; fail: 65; not run: 90 Build 10: aarch64/2018/nov/21 pass: 5,426; fail: 66; not run: 90 Build 11: aarch64/2018/nov/23 pass: 5,426; fail: 68; not run: 90 Build 12: aarch64/2018/nov/26 pass: 5,427; fail: 67; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 Build 5: aarch64/2018/nov/07 pass: 8,526; fail: 664; error: 31 Build 6: aarch64/2018/nov/08 pass: 8,512; fail: 678; error: 31 Build 7: aarch64/2018/nov/09 pass: 8,516; fail: 681; error: 27 Build 8: aarch64/2018/nov/12 pass: 8,507; fail: 685; error: 34 Build 9: aarch64/2018/nov/19 pass: 8,520; fail: 682; error: 26 Build 10: aarch64/2018/nov/21 pass: 8,516; fail: 689; error: 31 Build 11: aarch64/2018/nov/23 pass: 8,541; fail: 672; error: 24 Build 12: aarch64/2018/nov/26 pass: 8,517; fail: 691; error: 29 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 Build 5: aarch64/2018/nov/07 pass: 3,974; fail: 5 Build 6: aarch64/2018/nov/08 pass: 3,974; fail: 5 Build 7: aarch64/2018/nov/09 pass: 3,977; fail: 4 Build 8: aarch64/2018/nov/12 pass: 3,979; fail: 5 Build 9: aarch64/2018/nov/19 pass: 3,980; fail: 4 Build 10: aarch64/2018/nov/21 pass: 3,982; fail: 4 Build 11: aarch64/2018/nov/23 pass: 3,983; fail: 4 Build 12: aarch64/2018/nov/26 pass: 3,983; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.75x Relative performance: Server critical-jOPS (nc): 9.24x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ 2018-11-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/311/results/ 2018-11-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/312/results/ 2018-11-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/313/results/ 2018-11-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/316/results/ 2018-11-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/323/results/ 2018-11-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/325/results/ 2018-11-24 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/327/results/ 2018-11-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/330/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From rwestrel at redhat.com Tue Nov 27 08:53:45 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 27 Nov 2018 09:53:45 +0100 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: <780e5bca-b585-fb4a-cc58-1fa2b0eeb5c2@redhat.com> References: <780e5bca-b585-fb4a-cc58-1fa2b0eeb5c2@redhat.com> Message-ID: <87r2f6nbom.fsf@redhat.com> > However, it may be that the linking of the Acquire as a direct feed of > the secondary CAS is a problem. That CAS is only executed conditionally > on the first CAS failing. If the memory flow is not ordered correctly > then this might risk allowing the first CAS to complete and bypass the > necessary trailing dmb. I could struggle through this code but it is > probably best to ask Roland to look at it. I'll take a look. Roland. From rwestrel at redhat.com Wed Nov 28 10:56:07 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 28 Nov 2018 11:56:07 +0100 Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far Message-ID: <877egxmpx4.fsf@redhat.com> Just noticed I didn't include the mailing lists in that reply. Roland. -------------- next part -------------- An embedded message was scrubbed... From: Roland Westrelin Subject: Re: [aarch64-port-dev ] Aarch64 port for ZGC, so far Date: Wed, 28 Nov 2018 11:53:09 +0100 Size: 9435 URL: From adinn at redhat.com Wed Nov 28 15:27:31 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 28 Nov 2018 15:27:31 +0000 Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far In-Reply-To: <877egxmpx4.fsf@redhat.com> References: <877egxmpx4.fsf@redhat.com> Message-ID: Hi Roland, On 28/11/2018 10:56, Roland Westrelin wrote: > > Just noticed I didn't include the mailing lists in that reply. I'll take your word for it that the matcher problem Stuart ran into can be fixed by the tweak you applied to Matcher::clone_address_expressions. I don't know what ZBarrierSetC2::matcher_find_shared_visit is meant to do, never mind how it interacts with clone_address_expressions. However, I don't see any problem having clone_address_expressions return false on AArch64 when the address is being consumed by a LoadStore. Anyway, what I really wanted to say was that the fix for the trailing barrier lookup using an extra precedence link is a very nice, simple solution. regards, Andrew Dinn ----------- From ci_notify at linaro.org Thu Nov 29 01:31:45 2018 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 29 Nov 2018 01:31:45 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <943672097.1226.1543455106207.JavaMail.jenkins@797da5e41941> 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/2018/332/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 5,790; fail: 18; not run: 90 Build 1: aarch64/2018/oct/29 pass: 5,789; fail: 19; not run: 90 Build 2: aarch64/2018/nov/01 pass: 5,469; fail: 21; not run: 90 Build 3: aarch64/2018/nov/02 pass: 5,469; fail: 21; not run: 90 Build 4: aarch64/2018/nov/05 pass: 5,467; fail: 22; not run: 90 Build 5: aarch64/2018/nov/07 pass: 5,470; fail: 20; not run: 90 Build 6: aarch64/2018/nov/08 pass: 5,469; fail: 22; not run: 90 Build 7: aarch64/2018/nov/09 pass: 5,472; fail: 22; not run: 90 Build 8: aarch64/2018/nov/12 pass: 5,474; fail: 20; not run: 90 Build 9: aarch64/2018/nov/19 pass: 5,426; fail: 65; not run: 90 Build 10: aarch64/2018/nov/21 pass: 5,426; fail: 66; not run: 90 Build 11: aarch64/2018/nov/23 pass: 5,426; fail: 68; not run: 90 Build 12: aarch64/2018/nov/26 pass: 5,427; fail: 67; not run: 90 Build 13: aarch64/2018/nov/28 pass: 5,430; fail: 66; not run: 90 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 8,497; fail: 685; error: 29 Build 1: aarch64/2018/oct/29 pass: 8,538; fail: 653; error: 25 Build 2: aarch64/2018/nov/01 pass: 8,512; fail: 673; error: 31 Build 3: aarch64/2018/nov/02 pass: 8,517; fail: 673; error: 29 Build 4: aarch64/2018/nov/05 pass: 8,506; fail: 684; error: 29 Build 5: aarch64/2018/nov/07 pass: 8,526; fail: 664; error: 31 Build 6: aarch64/2018/nov/08 pass: 8,512; fail: 678; error: 31 Build 7: aarch64/2018/nov/09 pass: 8,516; fail: 681; error: 27 Build 8: aarch64/2018/nov/12 pass: 8,507; fail: 685; error: 34 Build 9: aarch64/2018/nov/19 pass: 8,520; fail: 682; error: 26 Build 10: aarch64/2018/nov/21 pass: 8,516; fail: 689; error: 31 Build 11: aarch64/2018/nov/23 pass: 8,541; fail: 672; error: 24 Build 12: aarch64/2018/nov/26 pass: 8,517; fail: 691; error: 29 Build 13: aarch64/2018/nov/28 pass: 8,535; fail: 685; error: 20 6 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/22 pass: 3,971; fail: 5 Build 1: aarch64/2018/oct/29 pass: 3,972; fail: 5 Build 2: aarch64/2018/nov/01 pass: 3,973; fail: 5 Build 3: aarch64/2018/nov/02 pass: 3,974; fail: 4 Build 4: aarch64/2018/nov/05 pass: 3,973; fail: 5 Build 5: aarch64/2018/nov/07 pass: 3,974; fail: 5 Build 6: aarch64/2018/nov/08 pass: 3,974; fail: 5 Build 7: aarch64/2018/nov/09 pass: 3,977; fail: 4 Build 8: aarch64/2018/nov/12 pass: 3,979; fail: 5 Build 9: aarch64/2018/nov/19 pass: 3,980; fail: 4 Build 10: aarch64/2018/nov/21 pass: 3,982; fail: 4 Build 11: aarch64/2018/nov/23 pass: 3,983; fail: 4 Build 12: aarch64/2018/nov/26 pass: 3,983; fail: 4 Build 13: aarch64/2018/nov/28 pass: 3,987; fail: 4 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 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): 7.75x Relative performance: Server critical-jOPS (nc): 8.77x 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 server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 201.64 Server 201.64 / Server 2014-04-01 (71.00): 2.84x 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. 2018-10-23 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/295/results/ 2018-10-30 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/302/results/ 2018-11-02 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/305/results/ 2018-11-03 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/306/results/ 2018-11-06 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/309/results/ 2018-11-08 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/311/results/ 2018-11-09 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/312/results/ 2018-11-10 pass rate: 11559/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/313/results/ 2018-11-13 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/316/results/ 2018-11-20 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/323/results/ 2018-11-22 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/325/results/ 2018-11-24 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/327/results/ 2018-11-27 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/330/results/ 2018-11-29 pass rate: 11560/11560, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2018/332/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From adinn at redhat.com Thu Nov 29 08:58:46 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 29 Nov 2018 08:58:46 +0000 Subject: [aarch64-port-dev ] RFR(M): 8212043: Add floating-point Math.min/max intrinsics In-Reply-To: References: <9fe54c47-4956-0810-8220-aee4152e3ffb@redhat.com> <55f1351e-a2f2-0c55-695d-8f651aee345d@redhat.com> <5f93fb46-564c-a101-9e09-2ee5c2492e07@redhat.com> <1bd3d8ea-ac46-8871-f7c1-295a4b2738d8@redhat.com> <95b53b38-4d8d-8bb3-c7d1-b0874d3ba281@redhat.com> Message-ID: Hi Pengfei, On 08/11/2018 02:49, Pengfei Li (Arm Technology China) wrote: > Hi Andrew Dinn, > >> I am happy to commit this patch on your behalf. However, it affects >> shared code, so it will need to be pushed to the submit repo and >> successfully built before it can be committed. I will do that now >> and let you know if there are any problems. > > Thanks for your help and sorry for my late reply. How is the build > test from submit repo? Should I do a rebase now as this patch is on a > codebase of several days ago? Sorry, I did not proceed to push this because Andrew Haley said he wanted to do vectorization and I assumed he meant as part of this patch. Andrew is that what you want or would you prefer this to go in as a first step? 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 rwestrel at redhat.com Thu Nov 29 14:57:54 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 29 Nov 2018 15:57:54 +0100 Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far In-Reply-To: References: <877egxmpx4.fsf@redhat.com> Message-ID: <87d0qokk25.fsf@redhat.com> Hi Andrew, > I'll take your word for it that the matcher problem Stuart ran into can > be fixed by the tweak you applied to Matcher::clone_address_expressions. > I don't know what ZBarrierSetC2::matcher_find_shared_visit is meant to > do, never mind how it interacts with clone_address_expressions. However, > I don't see any problem having clone_address_expressions return false on > AArch64 when the address is being consumed by a LoadStore. A field load is: (LoadI (AddP base field_offset)) and we want a single instruction that embeds the address calculation. 2 field load of the same field would be: (LoadI (AddP base field_offset)) (LoadI (AddP base field_offset)) with a shared AddP. When c2 performs matching, if it sees a node that is shared such as this one, it matches it as a standalone mach node. So we would have an instruction to compute the field address and 2 loads that use the result of that instructions. Given how cheap it is to let the memory access instruction do the address calculation, that's not what we want. Instead we want the matcher to operate as if there are 2 different AddP nodes. That's what cloning in the matcher is about. It doesn't really clone anything but it makes sure the AddP above is not seen as shared and matched once for every memory access instructions. Now with ZGC, I think we can have some field access at some (AddP ...) address followed by a slow path call to the runtime in the barrier code that passes that address. So the (AddP ...) is shared between a memory access node and a call node. That causes it to be matched separately. Given the call is in the slow path, that's not what we want. So the ZGC specific code "clones" the AddP in that scenario. On aarch64, in the case of a cas, the AddP address input is "cloned" but it's not matched as part of the cas mach node which confuses the matcher logic. Roland. From stuart.monteith at linaro.org Thu Nov 29 18:34:06 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 29 Nov 2018 18:34:06 +0000 Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far In-Reply-To: <87d0qokk25.fsf@redhat.com> References: <877egxmpx4.fsf@redhat.com> <87d0qokk25.fsf@redhat.com> Message-ID: Hello, Thanks for looking at this Roland, Andrew. I don't believe I understand C2 well enough to understand what the solution would be here in the general case. I'll add these as tests in a new revision, in the meantime I'm testing with your patch, and I've come across another case. I've been running with SPECjbb-2015, as it generates sufficient garbage with enough complex methods to give some confidence at this early stage. There are a number of CompareAndSwap variants called here. The example I included was there for java.lang.class, so failed fairly early on. The current issue I find is the same trailing_membar assert: # Internal Error (/home/stuart.monteith/repos/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1435), pid=30296, tid=30392 # assert(ldst->trailing_membar() != __null) failed: expected trailing membar With this in the replay: compile java/util/concurrent/ConcurrentLinkedQueue offer (Ljava/lang/Object;)Z -1 4 inline 16 0 -1 java/util/concurrent/ConcurrentLinkedQueue offer (Ljava/lang/Object;)Z 1 5 java/util/Objects requireNonNull (Ljava/lang/Object;)Ljava/lang/Object; 1 8 java/util/concurrent/ConcurrentLinkedQueue$Node (Ljava/lang/Object;)V 2 1 java/lang/Object ()V 2 9 java/lang/invoke/VarHandleGuards guard_LL_V (Ljava/lang/invoke/VarHandle;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/VarHandle$AccessDescriptor;)V 3 30 java/lang/invoke/VarForm getMemberName (I)Ljava/lang/invoke/MemberName; 3 33 java/lang/invoke/VarHandleReferences$FieldInstanceReadWrite set (Ljava/lang/invoke/VarHandleReferences$FieldInstanceReadWrite;Ljava/lang/Object;Ljava/lang/Object;)V 4 11 java/util/Objects requireNonNull (Ljava/lang/Object;)Ljava/lang/Object; 1 39 java/lang/invoke/VarHandleGuards guard_LLL_Z (Ljava/lang/invoke/VarHandle;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/VarHandle$AccessDescriptor;)Z 2 34 java/lang/invoke/VarForm getMemberName (I)Ljava/lang/invoke/MemberName; 2 37 java/lang/invoke/VarHandleReferences$FieldInstanceReadWrite compareAndSet (Ljava/lang/invoke/VarHandleReferences$FieldInstanceReadWrite;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Z 3 11 java/util/Objects requireNonNull (Ljava/lang/Object;)Ljava/lang/Object; 1 57 java/lang/invoke/VarHandleGuards guard_LLL_Z (Ljava/lang/invoke/VarHandle;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/invoke/VarHandle$AccessDescriptor;)Z 2 34 java/lang/invoke/VarForm getMemberName (I)Ljava/lang/invoke/MemberName; 2 37 java/lang/invoke/VarHandleReferences$FieldInstanceReadWrite weakCompareAndSet (Ljava/lang/invoke/VarHandleReferences$FieldInstanceReadWrite;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Z 3 11 java/util/Objects requireNonNull (Ljava/lang/Object;)Ljava/lang/Object; ConcurrentLinkedQueue.offer is different before as is calling VarHandle instead of Unsafe, and it calls weakCompareAndSet conditionally depending on the result of a CompareAndSet. I suppose there is different graph for the matcher to handle, but I don't have that right now. I'm writing a separate testcase that calls ConcurrentLinkedQueue, as there are a few more conditions that need to be handled. As well as doing that, I'll continue looking for interesting cases, I can exclude failing cases as I encounter them. Thanks again, Stuart On Thu, 29 Nov 2018 at 14:58, Roland Westrelin wrote: > > > Hi Andrew, > > > I'll take your word for it that the matcher problem Stuart ran into can > > be fixed by the tweak you applied to Matcher::clone_address_expressions. > > I don't know what ZBarrierSetC2::matcher_find_shared_visit is meant to > > do, never mind how it interacts with clone_address_expressions. However, > > I don't see any problem having clone_address_expressions return false on > > AArch64 when the address is being consumed by a LoadStore. > > A field load is: > > (LoadI (AddP base field_offset)) > > and we want a single instruction that embeds the address calculation. > > 2 field load of the same field would be: > > (LoadI (AddP base field_offset)) > (LoadI (AddP base field_offset)) > > with a shared AddP. When c2 performs matching, if it sees a node that is > shared such as this one, it matches it as a standalone mach node. So we > would have an instruction to compute the field address and 2 loads that > use the result of that instructions. Given how cheap it is to let the > memory access instruction do the address calculation, that's not what we > want. Instead we want the matcher to operate as if there are 2 different > AddP nodes. That's what cloning in the matcher is about. It doesn't > really clone anything but it makes sure the AddP above is not seen as > shared and matched once for every memory access instructions. > > Now with ZGC, I think we can have some field access at some (AddP ...) > address followed by a slow path call to the runtime in the barrier code > that passes that address. So the (AddP ...) is shared between a memory > access node and a call node. That causes it to be matched > separately. Given the call is in the slow path, that's not what we > want. So the ZGC specific code "clones" the AddP in that scenario. > > On aarch64, in the case of a cas, the AddP address input is "cloned" but > it's not matched as part of the cas mach node which confuses the matcher > logic. > > Roland. From stuart.monteith at linaro.org Thu Nov 29 19:14:43 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 29 Nov 2018 19:14:43 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: <821e59e1a33244fea2b145d8083ab77d@huawei.com> Message-ID: Hello, This latest patch changes the arraycopy_prologue to pass the source as well as the destination, and for the ZGC array_copy prologue to use the source instead: http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181129/ I'm running a long test with the C1 compiler, so I'll see whether that removes the rarer failures. BR, Stuart On Thu, 29 Nov 2018 at 18:01, Stuart Monteith wrote: > > Thanks for pointing that out Ma Chunhui, > > What you suggest can't be done as ZGC isn't just a compile time > option, it is also a run-time option. You are quite right though - the > array prologue needs to take the src and dest and decide what it needs > to do. > > I'll incorporate this into the aarch64 specific code by adding the > source too the method signature and the other dependencies in a manner > that will be correct for with/without ZGC. > > This will explain some of the rarer problems I 'm seeing. > > On Thu, 29 Nov 2018 at 06:13, machunhui (C) wrote: > > > > Hi, Stuart > > > > With your latest patch, It seems that Interpreter and C1 works fine on my machine and my case. But there is a crash when using C2. > > > > > > > > My Option is: -XX:+UseZGC -XX:-TieredCompilation -XX:ParallelGCThreads=1 -XX:ConcGCThreads=1 -XX:+Use64BitLiteralOops > > > > And the crash happens only when java main thread is exited, after DestroyJavaVM. > > > > > > > > The crash stack: > > > > 30 V [libjvm.so+0x121b968] ZPage::is_active() const+0xc > > > > 31 V [libjvm.so+0x123b180] ZMark::try_mark_object(ZMarkCache*, unsigned long, bool)+0x48 > > > > 32 V [libjvm.so+0x123b28c] ZMark::mark_and_follow(ZMarkCache*, ZMarkStackEntry)+0x6c > > > > 33 V [libjvm.so+0x123e6d4] bool ZMark::drain(ZMarkStripe*, ZMarkThreadLocalStacks*, ZMarkCache*, ZMarkNoTimeout*)+0x7c > > > > > > > > The crash is because when trying to mark object, it failed to find page for the given object address, which is 0xbaadbabe. And the reason is because in StubGenerator:: generate_disjoint_copy, when trying to add load-barrier in aarch64, the barrier is wrongly added to dest, not src. > > > > So the fix is quite simple, when using ZGC, add load-barrier to src instead of dest. > > > > > > > > diff --git a/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp b/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp > > > > index a1fd069c7b..fc7f209d62 100644 > > > > --- a/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp > > > > +++ b/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp > > > > @@ -1377,7 +1377,11 @@ class StubGenerator: public StubCodeGenerator { > > > > } > > > > > > > > BarrierSetAssembler *bs = BarrierSet::barrier_set()->barrier_set_assembler(); > > > > +#if INCLUDE_ZGC > > > > + bs->arraycopy_prologue(_masm, decorators, is_oop, s, count, saved_reg); > > > > +#else > > > > bs->arraycopy_prologue(_masm, decorators, is_oop, d, count, saved_reg); > > > > +#endif > > > > > > > > if (is_oop) { > > > > // save regs before copy_memory > > > > @@ -1451,7 +1455,11 @@ class StubGenerator: public StubCodeGenerator { > > > > } > > > > > > > > BarrierSetAssembler *bs = BarrierSet::barrier_set()->barrier_set_assembler(); > > > > +#if INCLUDE_ZGC > > > > + bs->arraycopy_prologue(_masm, decorators, is_oop, s, count, saved_regs); > > > > +#else > > > > bs->arraycopy_prologue(_masm, decorators, is_oop, d, count, saved_regs); > > > > +#endif > > > > > > > > if (is_oop) { > > > > // save regs before copy_memory > > > > > > > > Thanks. > > > > > > > > -------------------------------------------------- > > ??? Ma Chunhui > > Mail: machunhui2 at huawei.com > > 2012???-???????? > > 2012 Laboratories-Language VM Lab,2012Labs > > > > From Derek.White at cavium.com Fri Nov 30 01:50:33 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 30 Nov 2018 01:50:33 +0000 Subject: [aarch64-port-dev ] RFC: 64 bit literal oops In-Reply-To: References: Message-ID: Hi Stuart, General comments: - I really like splitting out the oop64 patch separately. - I think it would be useful to get this checked in separately from ZGC, so some of the rest of my suggestions point in that direction. - Testing: - You mentioned testing jtreg with and without the patch: - Did you test with Use64BitLiteralOops on, off, or both? - Is this code exercised more by JVMCI/Graal? Test with Graal as well? - Can we force more checking in debug mode? - This might be overkill, but a read_literal function that reads & decodes a bunch of movz/movks would allow simple assert that the constant was written as expected. - It would be good to add an enhancement request/jira for this. - Are the SRDM questions resolved? Remove comments? cpu/aarch64/globals_aarch64.hpp - Consider making this an experimental flag instead of product. cpu/aarch64/macroAssembler_aarch64.cpp - line 293: Why are we both doing the computation and a ShouldNotReachHere()? Thanks, - Derek ________________________________ From: aarch64-port-dev on behalf of Stuart Monteith Sent: Tuesday, October 2, 2018 5:54 PM To: aarch64-port-dev Cc: zgc-dev at openjdk.java.net Subject: [aarch64-port-dev ] RFC: 64 bit literal oops External Email Hello, I've been testing my patch to make literal oops 64-bit rather than 48-bit. This is a necessary prerequisite for ZGC to operate on aarch64 using tagged pointers. I'm not submitting this in it's final form, but just for a view on whether this is the proper way to do this. The patch is here: http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ I've tested it against jtreg and G1GC, and get clean results as compared to without the patch. No issues are apparent running SPECjbb-2015. There are essentially 7 changes: 1. There is a new options: -XX:+Use64BitLiteralOops 2. MacroAssembler::patch_oop(address,address) patches 64-bit addresses if the flag is enabled. 3. MacroAssembler::target_addr_for_insn(address, unsigned) is modified to pull out a 64-bit target address, if there is an extra movk, and then calls ShouldNotReachHere(). 4. MacroAssembler::mov(Register, Address) has been changed to call movptr with a flag set if the address is an Oop. 5. MacroAssembler::movptr(Register, uintptr_t) has been modified to take a flag indicating if it is an oop that is being emitted. If Use64BitLiteralOops has been set, then an additional movk is emitted to make up the 64 bit literal. 6. NativeInstruction::is_oop_at(int) was added, to detect if an oop exists at the address. 7. NativeMovConstReg::next_instruction_address() has been changed to handle get the address after "movz, movk, movk" and with 64 bit oops "movz, movk, movk, movk." (6) has never been observed,, so I don't consider it tested - there aren't circumstances where it returns true, so arguably it it should be replaced by an appropriate assert. Likewise, (3) is also an unnecessary change - the ShouldNotReachHere() never traps during testing - it was left in for review purposes. It has been mentioned to me that we could just use 64-bit literals, as that would make things simpler - I look forward to people's opinions. It was also mentioned ages ago that in future the coloured bits could be made irrelevant for ZGC. There is the up and coming 52-bit VA scheme for Arm v8. If we are to use >48 bits of address space we will have to ask for it explicitly, in which case we'd need to use 64 bit oops. The class metadata could remain 48-bit in that case. There is an interesting presentation on 52-bit VA here: https://connect.linaro.org/resources/yvr18/yvr18-119/ BR, Stuart From Derek.White at cavium.com Fri Nov 30 01:53:20 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 30 Nov 2018 01:53:20 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: Hi Stuart, I have some superficial comments: Can we add a bug for AArch64 support for ZGC? If you're swamped I can do it. cpu/aarch64/assembler_aarch64.cpp: cpu/aarch64/c1_LIRAssembler_aarch64.cpp: - Address::lea() & LIR_Assembler::leal(): - I'm not sure where they are used, but if they can be tested separately, it might be good to pull out as a non-ZGC fix. share/gc/shared/gcArguments.cpp: - Probably better to move this into cpu/aarch64/vm_version_aarch64.cpp, along with all of the other aarch64 flag setting in get_processor_features(). - This is also ugly, but at least it's not ugly in shared code. share/gc/z/c2/zBarrierSetC2.cpp: - Is this change necessary? I'll try to look at the real parts later... - Derek ps. We're going through an email switch here, so you may get duplicate/similar versions of some email. ________________________________ From: aarch64-port-dev on behalf of Stuart Monteith Sent: Friday, November 23, 2018 6:46 AM To: aarch64-port-dev; zgc-dev at openjdk.java.net; Roland Westrelin Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far External Email Hello, I thought I'd update where I am with ZGC. The C1 code seems to be mostly working. I had an issue where ZMarkStack was stripping off the top two bits of the 64-bit addresses, which is where I've put the thread colours to avoid tags in MTE. I've added some support for C2 to the ZGC code. There are some issues, however, with the graph. As before the 64-bit Literal oops support patch is needed: http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ The patchset is here: http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ To run with ZGC enabled, you'll need to pass: -XX:+UnlockExperimentalVMOptions -XX:+UseZGC I've included a test case here: http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ Which can be executed with or without "-XX:+UseBarriersForVolatile" to reproduce two different errors. With that option I see: # Internal Error (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, tid=17048 # assert(C->node_arena()->contains(s->_leaf) || !has_new_node(s->_leaf)) failed: duplicating node that's already been matched and without I see: # Internal Error (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, tid=3503 # assert(ldst->trailing_membar() != __null) failed: expected trailing membar This is due to a combination of the graph generated in ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier handling in aarch64.ad that Roland recently changed in "8209420: Track membars for volatile accesses so they can be properly optimized". This is easily triggered in the C2Example.java file I've linked to above, where calls to Unsafe.compareAndSwapObject provoke the issue. I'm trying to unpick the problems with the graph - I've uploaded the replay, hs_err and ideal graph xml files of runs with and without +UseBarriersForVolatile, in case someone could provide some insight. BR, Stuart From per.liden at oracle.com Fri Nov 30 08:06:42 2018 From: per.liden at oracle.com (Per Liden) Date: Fri, 30 Nov 2018 09:06:42 +0100 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: Hi Stuart, On 11/23/18 12:46 PM, Stuart Monteith wrote: > Hello, > I thought I'd update where I am with ZGC. The C1 code seems to be > mostly working. I had an issue where ZMarkStack was stripping off the > top two bits of the 64-bit addresses, which is where I've put the > thread colours to avoid tags in MTE. > I've added some support for C2 to the ZGC code. There are some > issues, however, with the graph. > > As before the 64-bit Literal oops support patch is needed: > http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ > > The patchset is here: > http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ Thanks for the update. Just did a quick scan over the patch, and noticed a couple of things. src/hotspot/share/gc/shared/gcArguments.cpp ------------------------------------------- The check added here seems to belong in zArguments.cpp. We might even want to introducing a zArguments_.cpp in the future, but zArguments.cpp works for now. src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp -------------------------------------------------------------------- With VA-masking enabled, the functionality provided by the above files should not be needed since you can just map anonymous memory. cheers, Per > > To run with ZGC enabled, you'll need to pass: > -XX:+UnlockExperimentalVMOptions > -XX:+UseZGC > > I've included a test case here: > http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ > > Which can be executed with or without "-XX:+UseBarriersForVolatile" to > reproduce two different errors. > > With that option I see: > # Internal Error > (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, > tid=17048 > # assert(C->node_arena()->contains(s->_leaf) || > !has_new_node(s->_leaf)) failed: duplicating node that's already been > matched > > and without I see: > # Internal Error > (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, > tid=3503 > # assert(ldst->trailing_membar() != __null) failed: expected trailing membar > > This is due to a combination of the graph generated in > ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier > handling in aarch64.ad that Roland recently changed in "8209420: Track > membars for volatile accesses so they can be properly optimized". This > is easily triggered in the C2Example.java file I've linked to above, > where calls to Unsafe.compareAndSwapObject provoke the issue. > > I'm trying to unpick the problems with the graph - I've uploaded the > replay, hs_err and ideal graph xml files of runs with and without > +UseBarriersForVolatile, in case someone could provide some insight. > > BR, > Stuart > From aph at redhat.com Fri Nov 30 10:15:02 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 30 Nov 2018 10:15:02 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: <6c3d9115-4964-f2e4-3f22-51a28a1099bd@redhat.com> On 11/30/18 1:53 AM, White, Derek wrote: > cpu/aarch64/assembler_aarch64.cpp: > cpu/aarch64/c1_LIRAssembler_aarch64.cpp: > - Address::lea() & LIR_Assembler::leal(): I don't think this is necessary. The address of ZAddressBadMask is a constant once the program is loaded so don't really need a reloc at all. -- 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 Nov 30 10:23:27 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 30 Nov 2018 10:23:27 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: <6c3d9115-4964-f2e4-3f22-51a28a1099bd@redhat.com> References: <6c3d9115-4964-f2e4-3f22-51a28a1099bd@redhat.com> Message-ID: <2ab65b41-c2a4-200e-1499-47f851ab8cb2@redhat.com> On 11/30/18 10:15 AM, Andrew Haley wrote: > On 11/30/18 1:53 AM, White, Derek wrote: >> cpu/aarch64/assembler_aarch64.cpp: >> cpu/aarch64/c1_LIRAssembler_aarch64.cpp: >> - Address::lea() & LIR_Assembler::leal(): > > I don't think this is necessary. The address of ZAddressBadMask is a > constant once the program is loaded so don't really need a reloc at > all. The current code for leal() looks like this: void LIR_Assembler::leal(LIR_Opr addr, LIR_Opr dest) { __ lea(dest->as_register_lo(), as_Address(addr->as_address_ptr())); } There's something very wrong with this patch. It's not needed anywhere else, so it shouldn't be needed for ZGC. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From per.liden at oracle.com Fri Nov 30 10:58:34 2018 From: per.liden at oracle.com (Per Liden) Date: Fri, 30 Nov 2018 11:58:34 +0100 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: <2ab65b41-c2a4-200e-1499-47f851ab8cb2@redhat.com> References: <6c3d9115-4964-f2e4-3f22-51a28a1099bd@redhat.com> <2ab65b41-c2a4-200e-1499-47f851ab8cb2@redhat.com> Message-ID: <9334bed6-1b63-64d5-b4b2-0c854c69b43b@oracle.com> Hi, On 11/30/18 11:23 AM, Andrew Haley wrote: > On 11/30/18 10:15 AM, Andrew Haley wrote: >> On 11/30/18 1:53 AM, White, Derek wrote: >>> cpu/aarch64/assembler_aarch64.cpp: >>> cpu/aarch64/c1_LIRAssembler_aarch64.cpp: >>> - Address::lea() & LIR_Assembler::leal(): >> >> I don't think this is necessary. The address of ZAddressBadMask is a >> constant once the program is loaded so don't really need a reloc at >> all. The need for a patchable lea is not because of ZAddressBadMask, but because of unknown field offsets in not yet loaded classes. See JDK-8202976. > > The current code for leal() looks like this: > > void LIR_Assembler::leal(LIR_Opr addr, LIR_Opr dest) { > __ lea(dest->as_register_lo(), as_Address(addr->as_address_ptr())); > } > > There's something very wrong with this patch. It's not needed > anywhere else, so it shouldn't be needed for ZGC. > Hmm, are you perhaps looking at a JDK8 repo or something? It looks like this in jdk/jdk: void LIR_Assembler::leal(LIR_Opr addr, LIR_Opr dest, LIR_PatchCode patch_code, CodeEmitInfo* info) { assert(patch_code == lir_patch_none, "Patch code not supported"); __ lea(dest->as_register_lo(), as_Address(addr->as_address_ptr())); } cheers, Per From stuart.monteith at linaro.org Fri Nov 30 11:13:18 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 30 Nov 2018 11:13:18 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: Hi Derek, I've opened https://bugs.openjdk.java.net/browse/JDK-8214527 - do you think I've tagged it correctly? lea() is used in the barrier code - and sometimes it can be as simple as a register move, see zBarrierSetAssembler_aarch64.cpp for examples. I did consider putting the test into vm_version_aarch64.cpp - but that seemed inappropriate. Per has suggested putting it into zArguments.cpp, so I'll revise it to do that. Thanks, Stuart On Fri, 30 Nov 2018 at 01:53, White, Derek wrote: > > Hi Stuart, > > I have some superficial comments: > > Can we add a bug for AArch64 support for ZGC? If you're swamped I can do it. > > cpu/aarch64/assembler_aarch64.cpp: > cpu/aarch64/c1_LIRAssembler_aarch64.cpp: > - Address::lea() & LIR_Assembler::leal(): > - I'm not sure where they are used, but if they can be tested separately, it might be good to pull out as a non-ZGC fix. > > share/gc/shared/gcArguments.cpp: > - Probably better to move this into cpu/aarch64/vm_version_aarch64.cpp, along with all of the other aarch64 flag setting in get_processor_features(). > - This is also ugly, but at least it's not ugly in shared code. > > share/gc/z/c2/zBarrierSetC2.cpp: > - Is this change necessary? > > I'll try to look at the real parts later... > > - Derek > > ps. We're going through an email switch here, so you may get duplicate/similar versions of some email. > > > ________________________________ > From: aarch64-port-dev on behalf of Stuart Monteith > Sent: Friday, November 23, 2018 6:46 AM > To: aarch64-port-dev; zgc-dev at openjdk.java.net; Roland Westrelin > Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far > > External Email > > Hello, > I thought I'd update where I am with ZGC. The C1 code seems to be > mostly working. I had an issue where ZMarkStack was stripping off the > top two bits of the 64-bit addresses, which is where I've put the > thread colours to avoid tags in MTE. > I've added some support for C2 to the ZGC code. There are some > issues, however, with the graph. > > As before the 64-bit Literal oops support patch is needed: > http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ > > The patchset is here: > http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ > > To run with ZGC enabled, you'll need to pass: > -XX:+UnlockExperimentalVMOptions > -XX:+UseZGC > > I've included a test case here: > http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ > > Which can be executed with or without "-XX:+UseBarriersForVolatile" to > reproduce two different errors. > > With that option I see: > # Internal Error > (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, > tid=17048 > # assert(C->node_arena()->contains(s->_leaf) || > !has_new_node(s->_leaf)) failed: duplicating node that's already been > matched > > and without I see: > # Internal Error > (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, > tid=3503 > # assert(ldst->trailing_membar() != __null) failed: expected trailing membar > > This is due to a combination of the graph generated in > ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier > handling in aarch64.ad that Roland recently changed in "8209420: Track > membars for volatile accesses so they can be properly optimized". This > is easily triggered in the C2Example.java file I've linked to above, > where calls to Unsafe.compareAndSwapObject provoke the issue. > > I'm trying to unpick the problems with the graph - I've uploaded the > replay, hs_err and ideal graph xml files of runs with and without > +UseBarriersForVolatile, in case someone could provide some insight. > > BR, > Stuart From stuart.monteith at linaro.org Fri Nov 30 12:22:33 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 30 Nov 2018 12:22:33 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: Hello, You're right, I was halfway through hedging my bets. One thing that concerns me is the longevity of a solution that uses the ignored bits. I recently moved the ZGC's coloured bits to the top 4 bits to avoid the up and coming Memory Tagging Extensions (MTE) in ARMv8.5 - they currently use bits 56 to 59, and so I'd be clear if I used bits 60 to 63. See: https://developer.arm.com/docs/ddi0596/a/a64-shared-pseudocode-functions/aarch64-functions-pseudocode#impl-shared.AddressWithAllocationTag.2_2 I've come across an issue where zMarkStackEntry is assuming the top two bits of an address aren't significant, whereas they are. This results in references losing some of their colour. As I see it I either ignore MTE for now, take it into account and alter zMarkStackEntry to drop some bits between, say, bits 52 to 54, or to somehow have aarch64 able to use multimapping or VA-masking. But in conclusion, I won't leave that code as it is. Thanks, Stuart On Fri, 30 Nov 2018 at 08:06, Per Liden wrote: > > Hi Stuart, > > On 11/23/18 12:46 PM, Stuart Monteith wrote: > > Hello, > > I thought I'd update where I am with ZGC. The C1 code seems to be > > mostly working. I had an issue where ZMarkStack was stripping off the > > top two bits of the 64-bit addresses, which is where I've put the > > thread colours to avoid tags in MTE. > > I've added some support for C2 to the ZGC code. There are some > > issues, however, with the graph. > > > > As before the 64-bit Literal oops support patch is needed: > > http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ > > > > The patchset is here: > > http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ > > Thanks for the update. Just did a quick scan over the patch, and noticed > a couple of things. > > src/hotspot/share/gc/shared/gcArguments.cpp > ------------------------------------------- > The check added here seems to belong in zArguments.cpp. We might even > want to introducing a zArguments_.cpp in the future, but > zArguments.cpp works for now. > > > src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp > src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp > src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp > src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp > -------------------------------------------------------------------- > With VA-masking enabled, the functionality provided by the above files > should not be needed since you can just map anonymous memory. > > cheers, > Per > > > > > To run with ZGC enabled, you'll need to pass: > > -XX:+UnlockExperimentalVMOptions > > -XX:+UseZGC > > > > I've included a test case here: > > http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ > > > > Which can be executed with or without "-XX:+UseBarriersForVolatile" to > > reproduce two different errors. > > > > With that option I see: > > # Internal Error > > (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, > > tid=17048 > > # assert(C->node_arena()->contains(s->_leaf) || > > !has_new_node(s->_leaf)) failed: duplicating node that's already been > > matched > > > > and without I see: > > # Internal Error > > (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, > > tid=3503 > > # assert(ldst->trailing_membar() != __null) failed: expected trailing membar > > > > This is due to a combination of the graph generated in > > ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier > > handling in aarch64.ad that Roland recently changed in "8209420: Track > > membars for volatile accesses so they can be properly optimized". This > > is easily triggered in the C2Example.java file I've linked to above, > > where calls to Unsafe.compareAndSwapObject provoke the issue. > > > > I'm trying to unpick the problems with the graph - I've uploaded the > > replay, hs_err and ideal graph xml files of runs with and without > > +UseBarriersForVolatile, in case someone could provide some insight. > > > > BR, > > Stuart > > From aph at redhat.com Fri Nov 30 13:21:42 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 30 Nov 2018 13:21:42 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: <9334bed6-1b63-64d5-b4b2-0c854c69b43b@oracle.com> References: <6c3d9115-4964-f2e4-3f22-51a28a1099bd@redhat.com> <2ab65b41-c2a4-200e-1499-47f851ab8cb2@redhat.com> <9334bed6-1b63-64d5-b4b2-0c854c69b43b@oracle.com> Message-ID: <658b71c4-17e9-4f95-5eea-08b2f9b19993@redhat.com> On 11/30/18 10:58 AM, Per Liden wrote: > On 11/30/18 11:23 AM, Andrew Haley wrote: >> On 11/30/18 10:15 AM, Andrew Haley wrote: >>> On 11/30/18 1:53 AM, White, Derek wrote: >>>> cpu/aarch64/assembler_aarch64.cpp: >>>> cpu/aarch64/c1_LIRAssembler_aarch64.cpp: >>>> - Address::lea() & LIR_Assembler::leal(): >>> >>> I don't think this is necessary. The address of ZAddressBadMask is a >>> constant once the program is loaded so don't really need a reloc at >>> all. > > The need for a patchable lea is not because of ZAddressBadMask, but > because of unknown field offsets in not yet loaded classes. See JDK-8202976. > >> The current code for leal() looks like this: >> >> void LIR_Assembler::leal(LIR_Opr addr, LIR_Opr dest) { >> __ lea(dest->as_register_lo(), as_Address(addr->as_address_ptr())); >> } >> >> There's something very wrong with this patch. It's not needed >> anywhere else, so it shouldn't be needed for ZGC. >> > > Hmm, are you perhaps looking at a JDK8 repo or something? It looks like > this in jdk/jdk: > > void LIR_Assembler::leal(LIR_Opr addr, LIR_Opr dest, LIR_PatchCode > patch_code, CodeEmitInfo* info) { > assert(patch_code == lir_patch_none, "Patch code not supported"); > __ lea(dest->as_register_lo(), as_Address(addr->as_address_ptr())); > } Ah, yes. The "Add C1 lea patching support for x86" patch. OK, no problem. We deoptimize for C1 patching, so this shouldn't affect us. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Fri Nov 30 14:32:11 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 30 Nov 2018 15:32:11 +0100 Subject: [aarch64-port-dev ] [Roland Westrelin] Re: Aarch64 port for ZGC, so far In-Reply-To: References: <877egxmpx4.fsf@redhat.com> <87d0qokk25.fsf@redhat.com> Message-ID: <87o9a6k55g.fsf@redhat.com> Hi Stuart, Can you try the attached patch on top of the previous one? The problem is that the second cas is not always of the same type as the first one (it's always a CompareAndSwap when the first one can be a WeakCompareAndSwap for instance). That breaks the new zgc logic in LoadStoreNode::trailing_membar() but also in the ad file: the type of the cas is used as an indication of whether a trailing barrier is there. Given the types of the 2 cas for zgc can differ, that logic gets confused. The fix uses the same type of cas for the second one which I assume is correct? Roland. -------------- next part -------------- A non-text attachment was scrubbed... Name: zgc-aarch64.patch Type: text/x-patch Size: 1431 bytes Desc: not available URL: From per.liden at oracle.com Fri Nov 30 15:12:23 2018 From: per.liden at oracle.com (Per Liden) Date: Fri, 30 Nov 2018 16:12:23 +0100 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: Hi, On 11/30/18 1:22 PM, Stuart Monteith wrote: > Hello, > You're right, I was halfway through hedging my bets. One thing > that concerns me is the longevity of a solution that uses the ignored > bits. I recently moved the ZGC's coloured bits to the top 4 bits to > avoid the up and coming Memory Tagging Extensions (MTE) in ARMv8.5 - > they currently use bits 56 to 59, and so I'd be clear if I used bits > 60 to 63. See: https://developer.arm.com/docs/ddi0596/a/a64-shared-pseudocode-functions/aarch64-functions-pseudocode#impl-shared.AddressWithAllocationTag.2_2 > I've come across an issue where zMarkStackEntry is assuming the top > two bits of an address aren't significant, whereas they are. This > results in references losing some of their colour. > > As I see it I either ignore MTE for now, take it into account and > alter zMarkStackEntry to drop some bits between, say, bits 52 to 54, > or to somehow have aarch64 able to use multimapping or VA-masking. > > But in conclusion, I won't leave that code as it is. Ok, I see. The zMarkStackEntry issue should be fixable by doing something like: field_object_address::encode(object_address >> 3) and: field_object_address::decode(_entry) << 3; in the relevant places, right? cheers, Per > > Thanks, > Stuart > > > On Fri, 30 Nov 2018 at 08:06, Per Liden wrote: >> >> Hi Stuart, >> >> On 11/23/18 12:46 PM, Stuart Monteith wrote: >>> Hello, >>> I thought I'd update where I am with ZGC. The C1 code seems to be >>> mostly working. I had an issue where ZMarkStack was stripping off the >>> top two bits of the 64-bit addresses, which is where I've put the >>> thread colours to avoid tags in MTE. >>> I've added some support for C2 to the ZGC code. There are some >>> issues, however, with the graph. >>> >>> As before the 64-bit Literal oops support patch is needed: >>> http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ >>> >>> The patchset is here: >>> http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ >> >> Thanks for the update. Just did a quick scan over the patch, and noticed >> a couple of things. >> >> src/hotspot/share/gc/shared/gcArguments.cpp >> ------------------------------------------- >> The check added here seems to belong in zArguments.cpp. We might even >> want to introducing a zArguments_.cpp in the future, but >> zArguments.cpp works for now. >> >> >> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp >> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp >> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp >> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp >> -------------------------------------------------------------------- >> With VA-masking enabled, the functionality provided by the above files >> should not be needed since you can just map anonymous memory. >> >> cheers, >> Per >> >>> >>> To run with ZGC enabled, you'll need to pass: >>> -XX:+UnlockExperimentalVMOptions >>> -XX:+UseZGC >>> >>> I've included a test case here: >>> http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ >>> >>> Which can be executed with or without "-XX:+UseBarriersForVolatile" to >>> reproduce two different errors. >>> >>> With that option I see: >>> # Internal Error >>> (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, >>> tid=17048 >>> # assert(C->node_arena()->contains(s->_leaf) || >>> !has_new_node(s->_leaf)) failed: duplicating node that's already been >>> matched >>> >>> and without I see: >>> # Internal Error >>> (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, >>> tid=3503 >>> # assert(ldst->trailing_membar() != __null) failed: expected trailing membar >>> >>> This is due to a combination of the graph generated in >>> ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier >>> handling in aarch64.ad that Roland recently changed in "8209420: Track >>> membars for volatile accesses so they can be properly optimized". This >>> is easily triggered in the C2Example.java file I've linked to above, >>> where calls to Unsafe.compareAndSwapObject provoke the issue. >>> >>> I'm trying to unpick the problems with the graph - I've uploaded the >>> replay, hs_err and ideal graph xml files of runs with and without >>> +UseBarriersForVolatile, in case someone could provide some insight. >>> >>> BR, >>> Stuart >>> From stuart.monteith at linaro.org Fri Nov 30 16:31:12 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 30 Nov 2018 16:31:12 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: Thanks. zBitField has a "ValueShift" template parameter, so I can just do this instead: typedef ZBitField field_object_address; And that will preserve the top bits. On Fri, 30 Nov 2018 at 15:12, Per Liden wrote: > > Hi, > > On 11/30/18 1:22 PM, Stuart Monteith wrote: > > Hello, > > You're right, I was halfway through hedging my bets. One thing > > that concerns me is the longevity of a solution that uses the ignored > > bits. I recently moved the ZGC's coloured bits to the top 4 bits to > > avoid the up and coming Memory Tagging Extensions (MTE) in ARMv8.5 - > > they currently use bits 56 to 59, and so I'd be clear if I used bits > > 60 to 63. See: https://developer.arm.com/docs/ddi0596/a/a64-shared-pseudocode-functions/aarch64-functions-pseudocode#impl-shared.AddressWithAllocationTag.2_2 > > I've come across an issue where zMarkStackEntry is assuming the top > > two bits of an address aren't significant, whereas they are. This > > results in references losing some of their colour. > > > > As I see it I either ignore MTE for now, take it into account and > > alter zMarkStackEntry to drop some bits between, say, bits 52 to 54, > > or to somehow have aarch64 able to use multimapping or VA-masking. > > > > But in conclusion, I won't leave that code as it is. > > Ok, I see. The zMarkStackEntry issue should be fixable by doing > something like: > > field_object_address::encode(object_address >> 3) > > and: > > field_object_address::decode(_entry) << 3; > > in the relevant places, right? > > cheers, > Per > > > > > Thanks, > > Stuart > > > > > > On Fri, 30 Nov 2018 at 08:06, Per Liden wrote: > >> > >> Hi Stuart, > >> > >> On 11/23/18 12:46 PM, Stuart Monteith wrote: > >>> Hello, > >>> I thought I'd update where I am with ZGC. The C1 code seems to be > >>> mostly working. I had an issue where ZMarkStack was stripping off the > >>> top two bits of the 64-bit addresses, which is where I've put the > >>> thread colours to avoid tags in MTE. > >>> I've added some support for C2 to the ZGC code. There are some > >>> issues, however, with the graph. > >>> > >>> As before the 64-bit Literal oops support patch is needed: > >>> http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ > >>> > >>> The patchset is here: > >>> http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ > >> > >> Thanks for the update. Just did a quick scan over the patch, and noticed > >> a couple of things. > >> > >> src/hotspot/share/gc/shared/gcArguments.cpp > >> ------------------------------------------- > >> The check added here seems to belong in zArguments.cpp. We might even > >> want to introducing a zArguments_.cpp in the future, but > >> zArguments.cpp works for now. > >> > >> > >> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp > >> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp > >> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp > >> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp > >> -------------------------------------------------------------------- > >> With VA-masking enabled, the functionality provided by the above files > >> should not be needed since you can just map anonymous memory. > >> > >> cheers, > >> Per > >> > >>> > >>> To run with ZGC enabled, you'll need to pass: > >>> -XX:+UnlockExperimentalVMOptions > >>> -XX:+UseZGC > >>> > >>> I've included a test case here: > >>> http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ > >>> > >>> Which can be executed with or without "-XX:+UseBarriersForVolatile" to > >>> reproduce two different errors. > >>> > >>> With that option I see: > >>> # Internal Error > >>> (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, > >>> tid=17048 > >>> # assert(C->node_arena()->contains(s->_leaf) || > >>> !has_new_node(s->_leaf)) failed: duplicating node that's already been > >>> matched > >>> > >>> and without I see: > >>> # Internal Error > >>> (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, > >>> tid=3503 > >>> # assert(ldst->trailing_membar() != __null) failed: expected trailing membar > >>> > >>> This is due to a combination of the graph generated in > >>> ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier > >>> handling in aarch64.ad that Roland recently changed in "8209420: Track > >>> membars for volatile accesses so they can be properly optimized". This > >>> is easily triggered in the C2Example.java file I've linked to above, > >>> where calls to Unsafe.compareAndSwapObject provoke the issue. > >>> > >>> I'm trying to unpick the problems with the graph - I've uploaded the > >>> replay, hs_err and ideal graph xml files of runs with and without > >>> +UseBarriersForVolatile, in case someone could provide some insight. > >>> > >>> BR, > >>> Stuart > >>> From per.liden at oracle.com Fri Nov 30 19:53:41 2018 From: per.liden at oracle.com (Per Liden) Date: Fri, 30 Nov 2018 20:53:41 +0100 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: Message-ID: <1e2f2a5c-5c46-7b76-ec1f-66c57b002858@oracle.com> Ah, yes! I had forgot about that little feature, that's even better of course ;) /Per On 2018-11-30 17:31, Stuart Monteith wrote: > Thanks. zBitField has a "ValueShift" template parameter, so I can > just do this instead: > > typedef ZBitField field_object_address; > > And that will preserve the top bits. > > On Fri, 30 Nov 2018 at 15:12, Per Liden wrote: >> >> Hi, >> >> On 11/30/18 1:22 PM, Stuart Monteith wrote: >>> Hello, >>> You're right, I was halfway through hedging my bets. One thing >>> that concerns me is the longevity of a solution that uses the ignored >>> bits. I recently moved the ZGC's coloured bits to the top 4 bits to >>> avoid the up and coming Memory Tagging Extensions (MTE) in ARMv8.5 - >>> they currently use bits 56 to 59, and so I'd be clear if I used bits >>> 60 to 63. See: https://developer.arm.com/docs/ddi0596/a/a64-shared-pseudocode-functions/aarch64-functions-pseudocode#impl-shared.AddressWithAllocationTag.2_2 >>> I've come across an issue where zMarkStackEntry is assuming the top >>> two bits of an address aren't significant, whereas they are. This >>> results in references losing some of their colour. >>> >>> As I see it I either ignore MTE for now, take it into account and >>> alter zMarkStackEntry to drop some bits between, say, bits 52 to 54, >>> or to somehow have aarch64 able to use multimapping or VA-masking. >>> >>> But in conclusion, I won't leave that code as it is. >> >> Ok, I see. The zMarkStackEntry issue should be fixable by doing >> something like: >> >> field_object_address::encode(object_address >> 3) >> >> and: >> >> field_object_address::decode(_entry) << 3; >> >> in the relevant places, right? >> >> cheers, >> Per >> >>> >>> Thanks, >>> Stuart >>> >>> >>> On Fri, 30 Nov 2018 at 08:06, Per Liden wrote: >>>> >>>> Hi Stuart, >>>> >>>> On 11/23/18 12:46 PM, Stuart Monteith wrote: >>>>> Hello, >>>>> I thought I'd update where I am with ZGC. The C1 code seems to be >>>>> mostly working. I had an issue where ZMarkStack was stripping off the >>>>> top two bits of the 64-bit addresses, which is where I've put the >>>>> thread colours to avoid tags in MTE. >>>>> I've added some support for C2 to the ZGC code. There are some >>>>> issues, however, with the graph. >>>>> >>>>> As before the 64-bit Literal oops support patch is needed: >>>>> http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ >>>>> >>>>> The patchset is here: >>>>> http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ >>>> >>>> Thanks for the update. Just did a quick scan over the patch, and noticed >>>> a couple of things. >>>> >>>> src/hotspot/share/gc/shared/gcArguments.cpp >>>> ------------------------------------------- >>>> The check added here seems to belong in zArguments.cpp. We might even >>>> want to introducing a zArguments_.cpp in the future, but >>>> zArguments.cpp works for now. >>>> >>>> >>>> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.cpp >>>> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingFile_linux_aarch64.hpp >>>> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.cpp >>>> src/hotspot/os_cpu/linux_aarch64/gc/z/zBackingPath_linux_aarch64.hpp >>>> -------------------------------------------------------------------- >>>> With VA-masking enabled, the functionality provided by the above files >>>> should not be needed since you can just map anonymous memory. >>>> >>>> cheers, >>>> Per >>>> >>>>> >>>>> To run with ZGC enabled, you'll need to pass: >>>>> -XX:+UnlockExperimentalVMOptions >>>>> -XX:+UseZGC >>>>> >>>>> I've included a test case here: >>>>> http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ >>>>> >>>>> Which can be executed with or without "-XX:+UseBarriersForVolatile" to >>>>> reproduce two different errors. >>>>> >>>>> With that option I see: >>>>> # Internal Error >>>>> (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, >>>>> tid=17048 >>>>> # assert(C->node_arena()->contains(s->_leaf) || >>>>> !has_new_node(s->_leaf)) failed: duplicating node that's already been >>>>> matched >>>>> >>>>> and without I see: >>>>> # Internal Error >>>>> (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, >>>>> tid=3503 >>>>> # assert(ldst->trailing_membar() != __null) failed: expected trailing membar >>>>> >>>>> This is due to a combination of the graph generated in >>>>> ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier >>>>> handling in aarch64.ad that Roland recently changed in "8209420: Track >>>>> membars for volatile accesses so they can be properly optimized". This >>>>> is easily triggered in the C2Example.java file I've linked to above, >>>>> where calls to Unsafe.compareAndSwapObject provoke the issue. >>>>> >>>>> I'm trying to unpick the problems with the graph - I've uploaded the >>>>> replay, hs_err and ideal graph xml files of runs with and without >>>>> +UseBarriersForVolatile, in case someone could provide some insight. >>>>> >>>>> BR, >>>>> Stuart >>>>> From Derek.White at cavium.com Fri Nov 30 20:13:17 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 30 Nov 2018 20:13:17 +0000 Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far In-Reply-To: References: , Message-ID: Hi Stuart, Thanks, bug looks good. Per's suggestion is fine with me. - Derek ________________________________ From: Stuart Monteith Sent: Friday, November 30, 2018 6:13 AM To: White, Derek Cc: aarch64-port-dev; zgc-dev at openjdk.java.net; Roland Westrelin Subject: Re: [aarch64-port-dev ] Aarch64 port for ZGC, so far Hi Derek, I've opened https://bugs.openjdk.java.net/browse/JDK-8214527 - do you think I've tagged it correctly? lea() is used in the barrier code - and sometimes it can be as simple as a register move, see zBarrierSetAssembler_aarch64.cpp for examples. I did consider putting the test into vm_version_aarch64.cpp - but that seemed inappropriate. Per has suggested putting it into zArguments.cpp, so I'll revise it to do that. Thanks, Stuart On Fri, 30 Nov 2018 at 01:53, White, Derek wrote: > > Hi Stuart, > > I have some superficial comments: > > Can we add a bug for AArch64 support for ZGC? If you're swamped I can do it. > > cpu/aarch64/assembler_aarch64.cpp: > cpu/aarch64/c1_LIRAssembler_aarch64.cpp: > - Address::lea() & LIR_Assembler::leal(): > - I'm not sure where they are used, but if they can be tested separately, it might be good to pull out as a non-ZGC fix. > > share/gc/shared/gcArguments.cpp: > - Probably better to move this into cpu/aarch64/vm_version_aarch64.cpp, along with all of the other aarch64 flag setting in get_processor_features(). > - This is also ugly, but at least it's not ugly in shared code. > > share/gc/z/c2/zBarrierSetC2.cpp: > - Is this change necessary? > > I'll try to look at the real parts later... > > - Derek > > ps. We're going through an email switch here, so you may get duplicate/similar versions of some email. > > > ________________________________ > From: aarch64-port-dev on behalf of Stuart Monteith > Sent: Friday, November 23, 2018 6:46 AM > To: aarch64-port-dev; zgc-dev at openjdk.java.net; Roland Westrelin > Subject: [aarch64-port-dev ] Aarch64 port for ZGC, so far > > External Email > > Hello, > I thought I'd update where I am with ZGC. The C1 code seems to be > mostly working. I had an issue where ZMarkStack was stripping off the > top two bits of the 64-bit addresses, which is where I've put the > thread colours to avoid tags in MTE. > I've added some support for C2 to the ZGC code. There are some > issues, however, with the graph. > > As before the 64-bit Literal oops support patch is needed: > http://cr.openjdk.java.net/~smonteith/oop64/webrev-20181002/ > > The patchset is here: > http://cr.openjdk.java.net/~smonteith/zgc/webrev-20181121/ > > To run with ZGC enabled, you'll need to pass: > -XX:+UnlockExperimentalVMOptions > -XX:+UseZGC > > I've included a test case here: > http://cr.openjdk.java.net/~smonteith/zgc/C2Examples/ > > Which can be executed with or without "-XX:+UseBarriersForVolatile" to > reproduce two different errors. > > With that option I see: > # Internal Error > (/home/stuart/jdk/src/hotspot/share/opto/matcher.cpp:1663), pid=16859, > tid=17048 > # assert(C->node_arena()->contains(s->_leaf) || > !has_new_node(s->_leaf)) failed: duplicating node that's already been > matched > > and without I see: > # Internal Error > (/home/stuart/jdk/src/hotspot/cpu/aarch64/aarch64.ad:1438), pid=3436, > tid=3503 > # assert(ldst->trailing_membar() != __null) failed: expected trailing membar > > This is due to a combination of the graph generated in > ZBarrierSetC2::make_cas_loadbarrier and apparently the memory barrier > handling in aarch64.ad that Roland recently changed in "8209420: Track > membars for volatile accesses so they can be properly optimized". This > is easily triggered in the C2Example.java file I've linked to above, > where calls to Unsafe.compareAndSwapObject provoke the issue. > > I'm trying to unpick the problems with the graph - I've uploaded the > replay, hs_err and ideal graph xml files of runs with and without > +UseBarriersForVolatile, in case someone could provide some insight. > > BR, > Stuart