From ci_notify at linaro.org Mon Jun 1 03:57:42 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 1 Jun 2020 03:57:42 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <880808893.900.1590983863082.JavaMail.javamailuser@localhost> 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/jdk11u/openjdk-jtreg-nightly-tests/summary/2020/151/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 1: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 2: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 3: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 4: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 5: aarch64/2019/dec/17 pass: 5,775; fail: 1 Build 6: aarch64/2019/dec/21 pass: 5,775; fail: 1 Build 7: aarch64/2020/jan/16 pass: 5,775; fail: 1 Build 8: aarch64/2020/jan/30 pass: 5,791; fail: 1 Build 9: aarch64/2020/feb/06 pass: 5,791; fail: 1 Build 10: aarch64/2020/feb/13 pass: 5,792; fail: 1 Build 11: aarch64/2020/apr/30 pass: 5,813; fail: 1 Build 12: aarch64/2020/may/07 pass: 5,813; fail: 2 Build 13: aarch64/2020/may/15 pass: 5,814; fail: 1 Build 14: aarch64/2020/may/30 pass: 5,818; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 1: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 2: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 3: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 4: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 5: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 Build 6: aarch64/2019/dec/21 pass: 8,499; fail: 496; error: 10 Build 7: aarch64/2020/jan/16 pass: 8,513; fail: 474; error: 17 Build 8: aarch64/2020/jan/30 pass: 8,513; fail: 501; error: 13 Build 9: aarch64/2020/feb/06 pass: 8,496; fail: 517; error: 14 Build 10: aarch64/2020/feb/13 pass: 8,509; fail: 507; error: 14 Build 11: aarch64/2020/apr/30 pass: 8,534; fail: 519; error: 15 Build 12: aarch64/2020/may/07 pass: 8,540; fail: 515; error: 12 Build 13: aarch64/2020/may/15 pass: 8,558; fail: 498; error: 11 Build 14: aarch64/2020/may/30 pass: 8,544; fail: 507; error: 16 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/16 pass: 3,910 Build 1: aarch64/2019/nov/21 pass: 3,910 Build 2: aarch64/2019/dec/05 pass: 3,910 Build 3: aarch64/2019/dec/08 pass: 3,910 Build 4: aarch64/2019/dec/14 pass: 3,910 Build 5: aarch64/2019/dec/17 pass: 3,910 Build 6: aarch64/2019/dec/21 pass: 3,910 Build 7: aarch64/2020/jan/16 pass: 3,910 Build 8: aarch64/2020/jan/30 pass: 3,913 Build 9: aarch64/2020/feb/06 pass: 3,913 Build 10: aarch64/2020/feb/13 pass: 3,913 Build 11: aarch64/2020/apr/30 pass: 3,913 Build 12: aarch64/2020/may/07 pass: 3,913 Build 13: aarch64/2020/may/15 pass: 3,913 Build 14: aarch64/2020/may/30 pass: 3,913 Previous results can be found here: http://openjdk.linaro.org/jdk11u/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.29x Relative performance: Server critical-jOPS (nc): 8.34x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/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/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ 2019-12-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/355/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/037/results/ 2020-02-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/044/results/ 2020-05-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/121/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/128/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/136/results/ 2020-06-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/151/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From ci_notify at linaro.org Mon Jun 1 04:02:17 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 1 Jun 2020 04:02:17 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <1883579482.902.1590984137886.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2020/151/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/02 pass: 843; fail: 9; error: 1 Build 1: aarch64/2019/nov/14 pass: 843; fail: 9; error: 1 Build 2: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 3: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 4: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 Build 5: aarch64/2019/dec/21 pass: 848; fail: 10; error: 2 Build 6: aarch64/2020/jan/09 pass: 848; fail: 10; error: 1 Build 7: aarch64/2020/jan/11 pass: 848; fail: 10; error: 1 Build 8: aarch64/2020/jan/20 pass: 848; fail: 10; error: 1 Build 9: aarch64/2020/jan/25 pass: 848; fail: 10; error: 1 Build 10: aarch64/2020/may/06 pass: 885; fail: 12; error: 1 Build 11: aarch64/2020/may/10 pass: 885; fail: 12; error: 1 Build 12: aarch64/2020/may/12 pass: 885; fail: 12; error: 1 Build 13: aarch64/2020/may/19 pass: 886; fail: 12; error: 1 Build 14: aarch64/2020/may/30 pass: 890; fail: 11; error: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/14 pass: 5,956; fail: 275; error: 21 Build 1: aarch64/2019/dec/16 pass: 5,964; fail: 267; error: 21 Build 2: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 Build 3: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 Build 4: aarch64/2019/dec/21 pass: 5,970; fail: 262; error: 21 Build 5: aarch64/2020/jan/09 pass: 5,963; fail: 276; error: 20 Build 6: aarch64/2020/jan/11 pass: 5,959; fail: 279; error: 21 Build 7: aarch64/2020/jan/20 pass: 5,987; fail: 256; error: 24 Build 8: aarch64/2020/jan/25 pass: 5,962; fail: 285; error: 22 Build 9: aarch64/2020/feb/03 pass: 5,976; fail: 278; error: 19 Build 10: aarch64/2020/may/06 pass: 5,998; fail: 281; error: 21 Build 11: aarch64/2020/may/10 pass: 6,025; fail: 695; error: 21 Build 12: aarch64/2020/may/12 pass: 6,011; fail: 709; error: 21 Build 13: aarch64/2020/may/19 pass: 6,009; fail: 712; error: 22 Build 14: aarch64/2020/may/30 pass: 6,013; fail: 709; error: 23 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/02 pass: 3,116; fail: 2 Build 1: aarch64/2019/nov/14 pass: 3,116; fail: 2 Build 2: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 3: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 4: aarch64/2019/dec/19 pass: 3,117; fail: 2 Build 5: aarch64/2019/dec/21 pass: 3,117; fail: 2 Build 6: aarch64/2020/jan/09 pass: 3,117; fail: 2 Build 7: aarch64/2020/jan/11 pass: 3,117; fail: 2 Build 8: aarch64/2020/jan/20 pass: 3,117; fail: 2 Build 9: aarch64/2020/jan/25 pass: 3,117; fail: 2 Build 10: aarch64/2020/may/06 pass: 3,117; fail: 2 Build 11: aarch64/2020/may/10 pass: 3,117; fail: 2 Build 12: aarch64/2020/may/12 pass: 3,117; fail: 2 Build 13: aarch64/2020/may/19 pass: 3,117; fail: 2 Build 14: aarch64/2020/may/30 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 6.57x Relative performance: Server critical-jOPS (nc): 8.61x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 172.13 Server 172.13 / Server 2014-04-01 (71.00): 2.42x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-02 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/306/results/ 2019-11-15 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/318/results/ 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ 2019-12-22 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/355/results/ 2020-01-09 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/009/results/ 2020-01-11 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/011/results/ 2020-01-20 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/020/results/ 2020-01-25 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/025/results/ 2020-05-06 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/127/results/ 2020-05-10 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/131/results/ 2020-05-14 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/133/results/ 2020-05-20 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/140/results/ 2020-06-01 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/151/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From aph at redhat.com Mon Jun 1 12:53:13 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Jun 2020 13:53:13 +0100 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: On 30/05/2020 00:24, Liu, Xin wrote: > Since JDK-8245986(aarch64) has been resolved, may I ask a sponsor to push this change? Done. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jun 1 12:54:29 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Jun 2020 13:54:29 +0100 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: <7a0dbb2a-80b7-b768-f8c4-3577c2e9177c@redhat.com> On 01/06/2020 13:53, Andrew Haley wrote: > On 30/05/2020 00:24, Liu, Xin wrote: >> Since JDK-8245986(aarch64) has been resolved, may I ask a sponsor to push this change? > > Done. Next time, please make sure that the patch in webrev/jdk.patch is a real Hg webrev. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zhuoren.wz at alibaba-inc.com Tue Jun 2 08:29:53 2020 From: zhuoren.wz at alibaba-inc.com (=?UTF-8?B?V2FuZyBaaHVvKFpodW9yZW4p?=) Date: Tue, 02 Jun 2020 16:29:53 +0800 Subject: [aarch64-port-dev ] =?utf-8?q?RFR=3A8246051=3A=5BAArch64=5DSIGBUS?= =?utf-8?q?_by_unaligned_Unsafe_compare=5Fand=5Fswap?= In-Reply-To: <497b376c-561c-c40c-add6-a63af8736a3c@redhat.com> References: , <497b376c-561c-c40c-add6-a63af8736a3c@redhat.com> Message-ID: <6a308572-98db-4603-81c7-159833ebc15e.zhuoren.wz@alibaba-inc.com> Updated the test. Not AArch64-only now. http://cr.openjdk.java.net/~wzhuo/8246051/webrev.02/ BTW, the behavior of unaligned Unsafe swap on aarch64(throw InternalError) are different from on X86(do the swap). Not sure whether the difference makes sence. Regards, Zhuoren ------------------------------------------------------------------ From:Andrew Haley Sent At:2020 May 31 (Sun.) 04:15 To:Sandler ; Nick Gasson Cc:hotspot-compiler-dev\@openjdk.java.net ; aarch64-port-dev Subject:Re: [aarch64-port-dev ] RFR:8246051:[AArch64]SIGBUS by unaligned Unsafe compare_and_swap On 29/05/2020 13:36, Wang Zhuo(Zhuoren) wrote: > Update patch. A jtreg test added > http://cr.openjdk.java.net/~wzhuo/8246051/webrev.01/ The test is AArch64-only but the patch is to shared code. This doesn't make sense to me. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Jun 2 09:44:17 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 2 Jun 2020 10:44:17 +0100 Subject: [aarch64-port-dev ] RFR:8246051:[AArch64]SIGBUS by unaligned Unsafe compare_and_swap In-Reply-To: <6a308572-98db-4603-81c7-159833ebc15e.zhuoren.wz@alibaba-inc.com> References: <497b376c-561c-c40c-add6-a63af8736a3c@redhat.com> <6a308572-98db-4603-81c7-159833ebc15e.zhuoren.wz@alibaba-inc.com> Message-ID: <88adc311-4d0e-4037-f2fb-f581e1a9d0b8@redhat.com> On 02/06/2020 09:29, Wang Zhuo(Zhuoren) wrote: > Updated the test. Not AArch64-only now. > http://cr.openjdk.java.net/~wzhuo/8246051/webrev.02/ OK, looks good. It should work on PPC and similar as well. > BTW, the behavior of unaligned Unsafe swap on aarch64(throw > InternalError) are different from on X86(do the swap). Not sure > whether the difference makes sence. We need to make sure that the VM doesn't error out and exit; there's not much more we can do. It's all rather horrible. "Accesses to cacheable memory that are split across cache lines and page boundaries are not guaranteed to be atomic by the Intel Core 2 Duo, Intel ? AtomTM, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors. The Intel Core 2 Duo, Intel Atom, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, and P6 family processors provide bus control signals that permit external memory subsystems to make split accesses atomic; however, nonaligned data accesses will seriously impact the performance of the processor and should be avoided." https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf Aiee! Run away! :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Tue Jun 2 14:36:39 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 2 Jun 2020 14:36:39 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64 Message-ID: <1691528480.1281.1591108599974.JavaMail.javamailuser@localhost> 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/jdk14/openjdk-jtreg-nightly-tests/summary/2020/153/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 Build 6: aarch64/2020/may/07 pass: 5,763; fail: 44 Build 7: aarch64/2020/may/12 pass: 5,761; fail: 46 Build 8: aarch64/2020/may/15 pass: 5,784; fail: 46 Build 9: aarch64/2020/may/28 pass: 5,785; fail: 45 Build 10: aarch64/2020/jun/01 pass: 5,784; fail: 47 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 Build 6: aarch64/2020/may/07 pass: 8,835; fail: 517; error: 20 Build 7: aarch64/2020/may/12 pass: 8,836; fail: 517; error: 19 Build 8: aarch64/2020/may/15 pass: 8,845; fail: 509; error: 18 Build 9: aarch64/2020/may/28 pass: 8,838; fail: 516; error: 18 Build 10: aarch64/2020/jun/01 pass: 8,847; fail: 509; error: 16 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Build 7: aarch64/2020/may/07 pass: 4,031 Build 8: aarch64/2020/may/12 pass: 4,031 Build 9: aarch64/2020/may/15 pass: 4,031 Build 10: aarch64/2020/may/28 pass: 4,031 Build 11: aarch64/2020/jun/01 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/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.58x Relative performance: Server critical-jOPS (nc): 9.43x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/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/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/128/results/ 2020-05-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/133/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/136/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/149/results/ 2020-06-02 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/153/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/ From zhuoren.wz at alibaba-inc.com Wed Jun 3 09:59:57 2020 From: zhuoren.wz at alibaba-inc.com (=?UTF-8?B?V2FuZyBaaHVvKFpodW9yZW4p?=) Date: Wed, 03 Jun 2020 17:59:57 +0800 Subject: [aarch64-port-dev ] =?utf-8?q?RFR=3A8246051=3A=5BAArch64=5DSIGBUS?= =?utf-8?q?_by_unaligned_Unsafe_compare=5Fand=5Fswap?= In-Reply-To: <88adc311-4d0e-4037-f2fb-f581e1a9d0b8@redhat.com> References: <497b376c-561c-c40c-add6-a63af8736a3c@redhat.com> <6a308572-98db-4603-81c7-159833ebc15e.zhuoren.wz@alibaba-inc.com>, <88adc311-4d0e-4037-f2fb-f581e1a9d0b8@redhat.com> Message-ID: <67c97176-bbc1-4e95-a81e-0115d5de011c.zhuoren.wz@alibaba-inc.com> Andrew, thanks for the detailed explanation. Could you help push this patch, or I need to wait for other reviews? Regards, Zhuoren ------------------------------------------------------------------ From:Andrew Haley Sent At:2020 Jun. 2 (Tue.) 17:44 To:Sandler ; Nick Gasson Cc:hotspot-compiler-dev at openjdk.java.net ; aarch64-port-dev Subject:Re: [aarch64-port-dev ] RFR:8246051:[AArch64]SIGBUS by unaligned Unsafe compare_and_swap On 02/06/2020 09:29, Wang Zhuo(Zhuoren) wrote: > Updated the test. Not AArch64-only now. > http://cr.openjdk.java.net/~wzhuo/8246051/webrev.02/ OK, looks good. It should work on PPC and similar as well. > BTW, the behavior of unaligned Unsafe swap on aarch64(throw > InternalError) are different from on X86(do the swap). Not sure > whether the difference makes sence. We need to make sure that the VM doesn't error out and exit; there's not much more we can do. It's all rather horrible. "Accesses to cacheable memory that are split across cache lines and page boundaries are not guaranteed to be atomic by the Intel Core 2 Duo, Intel (r) AtomTM, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors. The Intel Core 2 Duo, Intel Atom, Intel Core Duo, Pentium M, Pentium 4, Intel Xeon, and P6 family processors provide bus control signals that permit external memory subsystems to make split accesses atomic; however, nonaligned data accesses will seriously impact the performance of the processor and should be avoided." https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf Aiee! Run away! :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Wed Jun 3 17:08:17 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 3 Jun 2020 19:08:17 +0200 Subject: [aarch64-port-dev ] [8] RFR (XS) 8246482: Build failures with +JFR -PCH Message-ID: <47e2ccca-d33f-0269-9b02-93d624c7034d@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8246482 This build failure is AArch64+JFR specific: .../hotspot/src/share/vm/jfr/writers/jfrEncoders.hpp: In static member function 'static size_t BigEndianEncoderImpl::encode(T, u1*)': .../hotspot/src/share/vm/jfr/writers/jfrEncoders.hpp:91:8: error: 'Bytes' has not been declared Bytes::put_Java_u2(dest, value); ^~~~~ Fix: diff -r 1ac56046129c src/share/vm/jfr/writers/jfrEncoders.hpp --- a/src/share/vm/jfr/writers/jfrEncoders.hpp Tue May 26 03:05:00 2020 +0100 +++ b/src/share/vm/jfr/writers/jfrEncoders.hpp Wed Jun 03 13:03:31 2020 -0400 @@ -43,6 +43,9 @@ #ifdef TARGET_ARCH_ppc # include "bytes_ppc.hpp" #endif +#ifdef TARGET_ARCH_aarch64 +# include "bytes_aarch64.hpp" +#endif // // The Encoding policy prescribes a template There is another one that is JFR+Shenandoah specific, it would come with a merge: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012413.html https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e16a3f855bf3 Testing: aarch64 build with +JFR -PCH -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Jun 3 21:30:24 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 3 Jun 2020 22:30:24 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b05 Upstream Sync Message-ID: <0df7cf7b-079a-87f9-34ac-3e6ef1bc7f0c@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b05: - JDK-7147060: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode - JDK-8178374: Problematic ByteBuffer handling in CipherSpi.bufferCrypt method - JDK-8181841: A TSA server returns timestamp with precision higher than milliseconds - JDK-8227269: Slow class loading when running with JDWP - JDK-8229899: Make java.io.File.isInvalid() less racy - JDK-8236996: Incorrect Roboto font rendering on Windows with subpixel antialiasing - JDK-8238842: AIOOBE in GIFImageReader.initializeStringTable - JDK-8241750: x86_32 build failure after JDK-8227269 - JDK-8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in - JDK-8244843: JapanEraNameCompatTest fails Main issues of note: None, clean merge. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/src/share/back/classTrack.c | 357 ++----- b/src/share/back/classTrack.h | 6 b/src/share/back/eventHandler.c | 3 b/src/share/back/util.c | 2 b/src/share/back/util.h | 2 b/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java | 5 b/src/share/classes/java/io/File.java | 10 b/src/share/classes/javax/crypto/CipherSpi.java | 142 +- b/src/share/classes/sun/font/FileFontStrike.java | 12 b/src/share/classes/sun/font/TrueTypeFont.java | 11 b/src/share/classes/sun/security/util/DerInputBuffer.java | 48 b/src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java | 20 b/src/share/classes/sun/text/resources/in/JavaTimeSupplementary_in.java | 497 ++++++++++ b/src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java | 20 b/src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java | 20 b/src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java | 20 b/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java | 20 b/src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java | 20 b/src/windows/native/sun/font/lcdglyph.c | 15 b/test/ProblemList.txt | 3 b/test/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java | 6 b/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java | 165 +++ b/test/javax/imageio/plugins/gif/GIFCodeSizeTest.java | 52 + b/test/sun/security/util/DerInputBuffer/TimeParsing.java | 19 25 files changed, 1139 insertions(+), 337 deletions(-) diffstat for hotspot b/.hgtags | 1 b/src/share/vm/opto/loopnode.cpp | 14 ++- b/test/compiler/loopopts/TestBeautifyLoops_2.java | 81 ++++++++++++++++++++++ 3 files changed, 93 insertions(+), 3 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Thu Jun 4 06:36:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Jun 2020 08:36:22 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b05 Upstream Sync In-Reply-To: <0df7cf7b-079a-87f9-34ac-3e6ef1bc7f0c@redhat.com> References: <0df7cf7b-079a-87f9-34ac-3e6ef1bc7f0c@redhat.com> Message-ID: <3c0dc3ea-354f-56fc-da18-6fc6102f4ed8@redhat.com> On 6/3/20 11:30 PM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxws/merge.changeset Look good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset Looks good. This would temporarily break Windows builds until 8246223 is here, right? > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/root/merge.changeset Look good. > Ok to push? Yes. -- Thanks, -Aleksey From aph at redhat.com Thu Jun 4 08:50:35 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Jun 2020 09:50:35 +0100 Subject: [aarch64-port-dev ] [8] RFR (XS) 8246482: Build failures with +JFR -PCH In-Reply-To: <47e2ccca-d33f-0269-9b02-93d624c7034d@redhat.com> References: <47e2ccca-d33f-0269-9b02-93d624c7034d@redhat.com> Message-ID: On 03/06/2020 18:08, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8246482 > > This build failure is AArch64+JFR specific: > > .../hotspot/src/share/vm/jfr/writers/jfrEncoders.hpp: In static member function 'static size_t > BigEndianEncoderImpl::encode(T, u1*)': > .../hotspot/src/share/vm/jfr/writers/jfrEncoders.hpp:91:8: error: 'Bytes' has not been declared > Bytes::put_Java_u2(dest, value); > ^~~~~ > > Fix: > > diff -r 1ac56046129c src/share/vm/jfr/writers/jfrEncoders.hpp > --- a/src/share/vm/jfr/writers/jfrEncoders.hpp Tue May 26 03:05:00 2020 +0100 > +++ b/src/share/vm/jfr/writers/jfrEncoders.hpp Wed Jun 03 13:03:31 2020 -0400 > @@ -43,6 +43,9 @@ > #ifdef TARGET_ARCH_ppc > # include "bytes_ppc.hpp" > #endif > +#ifdef TARGET_ARCH_aarch64 > +# include "bytes_aarch64.hpp" > +#endif > > // > // The Encoding policy prescribes a template > > There is another one that is JFR+Shenandoah specific, it would come with a merge: > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012413.html > https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e16a3f855bf3 > > Testing: aarch64 build with +JFR -PCH OK -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Jun 4 09:23:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Jun 2020 11:23:58 +0200 Subject: [aarch64-port-dev ] RFR: 2020-06-04, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah Message-ID: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com> https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/webrev.01/ This is another integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge. The webrev is not very large, and mostly contains file moves and associated build changes. IMO, the only thing that deserves explanation is the addition in src/share/vm/runtime/os.hpp: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012413.html We would negotiate the push order w.r.t. upstream sync with Andrew Hughes. Changes: Shenandoah: move parallelCleaning.* to shenandoah/ Shenandoah: fix formats in ShenandoahStringSymbolTableUnlinkTask [backport] 8245812: Shenandoah: compute root phase parallelism [backport] 8245814: Shenandoah: reconsider format specifiers for stats [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch [backport] 8245461: Shenandoah: refine mode name()-s [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties [backport] 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots Shenandoah: move barrier sets to their proper locations Shenandoah: Fix build failure with +JFR -PCH Shenandoah: fix runtime linking failure due to non-compiled shenandoahBarrierSetC1 [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits Merge Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 with a few nightlies -- Thanks, -Aleksey From ci_notify at linaro.org Thu Jun 4 15:20:21 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 4 Jun 2020 15:20:21 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <17604389.1544.1591284022367.JavaMail.javamailuser@localhost> 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/jdk11u/openjdk-jtreg-nightly-tests/summary/2020/154/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 1: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 2: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 3: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 4: aarch64/2019/dec/17 pass: 5,775; fail: 1 Build 5: aarch64/2019/dec/21 pass: 5,775; fail: 1 Build 6: aarch64/2020/jan/16 pass: 5,775; fail: 1 Build 7: aarch64/2020/jan/30 pass: 5,791; fail: 1 Build 8: aarch64/2020/feb/06 pass: 5,791; fail: 1 Build 9: aarch64/2020/feb/13 pass: 5,792; fail: 1 Build 10: aarch64/2020/apr/30 pass: 5,813; fail: 1 Build 11: aarch64/2020/may/07 pass: 5,813; fail: 2 Build 12: aarch64/2020/may/15 pass: 5,814; fail: 1 Build 13: aarch64/2020/may/30 pass: 5,818; fail: 1 Build 14: aarch64/2020/jun/02 pass: 5,818; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 1: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 2: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 3: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 4: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 Build 5: aarch64/2019/dec/21 pass: 8,499; fail: 496; error: 10 Build 6: aarch64/2020/jan/16 pass: 8,513; fail: 474; error: 17 Build 7: aarch64/2020/jan/30 pass: 8,513; fail: 501; error: 13 Build 8: aarch64/2020/feb/06 pass: 8,496; fail: 517; error: 14 Build 9: aarch64/2020/feb/13 pass: 8,509; fail: 507; error: 14 Build 10: aarch64/2020/apr/30 pass: 8,534; fail: 519; error: 15 Build 11: aarch64/2020/may/07 pass: 8,540; fail: 515; error: 12 Build 12: aarch64/2020/may/15 pass: 8,558; fail: 498; error: 11 Build 13: aarch64/2020/may/30 pass: 8,544; fail: 507; error: 16 Build 14: aarch64/2020/jun/02 pass: 8,535; fail: 515; error: 17 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/21 pass: 3,910 Build 1: aarch64/2019/dec/05 pass: 3,910 Build 2: aarch64/2019/dec/08 pass: 3,910 Build 3: aarch64/2019/dec/14 pass: 3,910 Build 4: aarch64/2019/dec/17 pass: 3,910 Build 5: aarch64/2019/dec/21 pass: 3,910 Build 6: aarch64/2020/jan/16 pass: 3,910 Build 7: aarch64/2020/jan/30 pass: 3,913 Build 8: aarch64/2020/feb/06 pass: 3,913 Build 9: aarch64/2020/feb/13 pass: 3,913 Build 10: aarch64/2020/apr/30 pass: 3,913 Build 11: aarch64/2020/may/07 pass: 3,913 Build 12: aarch64/2020/may/15 pass: 3,913 Build 13: aarch64/2020/may/30 pass: 3,913 Build 14: aarch64/2020/jun/02 pass: 3,913 Previous results can be found here: http://openjdk.linaro.org/jdk11u/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.29x Relative performance: Server critical-jOPS (nc): 8.09x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/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/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ 2019-12-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/355/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/037/results/ 2020-02-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/044/results/ 2020-05-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/121/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/128/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/136/results/ 2020-06-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/151/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/154/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From ci_notify at linaro.org Thu Jun 4 15:27:29 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 4 Jun 2020 15:27:29 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <1258318202.1546.1591284449870.JavaMail.javamailuser@localhost> 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/jdk13/openjdk-jtreg-nightly-tests/summary/2020/154/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/25 pass: 5,644; fail: 3 Build 1: aarch64/2019/jul/30 pass: 5,645; fail: 2 Build 2: aarch64/2019/aug/01 pass: 5,646; fail: 1 Build 3: aarch64/2019/aug/03 pass: 5,646; fail: 1 Build 4: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 5: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 6: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 7: aarch64/2019/nov/12 pass: 5,652 Build 8: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 9: aarch64/2019/nov/16 pass: 5,652 Build 10: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 11: aarch64/2019/dec/14 pass: 5,652 Build 12: aarch64/2020/jan/16 pass: 5,652 Build 13: aarch64/2020/may/28 pass: 5,669 Build 14: aarch64/2020/jun/02 pass: 5,677 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/25 pass: 8,620; fail: 528; error: 23 Build 1: aarch64/2019/jul/30 pass: 8,610; fail: 529; error: 32 Build 2: aarch64/2019/aug/01 pass: 8,620; fail: 527; error: 24 Build 3: aarch64/2019/aug/03 pass: 8,596; fail: 552; error: 23 Build 4: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 5: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 6: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 7: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 8: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 9: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 10: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 11: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 12: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 13: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 Build 14: aarch64/2020/jun/02 pass: 8,686; fail: 509; error: 17 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/25 pass: 3,964 Build 1: aarch64/2019/jul/30 pass: 3,964 Build 2: aarch64/2019/aug/01 pass: 3,964 Build 3: aarch64/2019/aug/03 pass: 3,964 Build 4: aarch64/2019/aug/06 pass: 3,964 Build 5: aarch64/2019/aug/08 pass: 3,964 Build 6: aarch64/2019/aug/10 pass: 3,964 Build 7: aarch64/2019/nov/12 pass: 3,964 Build 8: aarch64/2019/nov/14 pass: 3,964 Build 9: aarch64/2019/nov/16 pass: 3,964 Build 10: aarch64/2019/dec/03 pass: 3,964 Build 11: aarch64/2019/dec/14 pass: 3,964 Build 12: aarch64/2020/jan/16 pass: 3,964 Build 13: aarch64/2020/may/28 pass: 3,964 Build 14: aarch64/2020/jun/02 pass: 3,964 Previous results can be found here: http://openjdk.linaro.org/jdk13/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.46x Relative performance: Server critical-jOPS (nc): 9.34x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/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/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-07-24 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/204/results/ 2019-07-26 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/206/results/ 2019-07-31 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/211/results/ 2019-08-02 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/213/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/154/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From aph at redhat.com Thu Jun 4 15:34:23 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Jun 2020 16:34:23 +0100 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: <759f7e99-91a4-7c5f-36df-89b3ae96f74f@redhat.com> On 06/05/2020 09:46, Yang Zhang wrote: > Could you please help to review this patch? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243597 > Webrev: http://cr.openjdk.java.net/~yzhang/8243597/webrev.00/ I'm working on it. Sorry for the delay. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Jun 4 16:09:41 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Jun 2020 17:09:41 +0100 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: On 18/05/2020 06:51, Yang Zhang wrote: > Testing: > Full jtreg test > Vector API tests which cover vector abs > > Test case: > public static void absvs(short[] a, short[] b, short[] c) { > for (int i = 0; i < a.length; i++) { > c[i] = (short)Math.abs((a[i] + b[i])); > } > } > > Assembly code generated by C2: > 0x0000ffffaca3f3ac: ldr q17, [x16, #16] > 0x0000ffffaca3f3b0: ldr q16, [x15, #16] > 0x0000ffffaca3f3b4: add v16.8h, v16.8h, v17.8h > 0x0000ffffaca3f3b8: abs v16.8h, v16.8h > 0x0000ffffaca3f3c0: str q16, [x12, #16] > > Similar test cases for byte/int/long are also tested and NEON abs instruction is generated by C2. Unfortunately the test cases you provided do not include the method absvs(short). I'm not seeing this result. All I get with your patch applied in the case of your test TestScalar @Benchmark public void testAbsI() { for (int n = 0; n < LOOP_CNT; n++) { for (int i = 0; i < ia.length; i += 4) { ic[i] = Math.abs(ia[i] + ib[i]); } } } is ;; B18: # out( B18 B19 ) <- in( B17 B18 ) Loop( B18-B18 inner main of N82 strip mined) Freq: 9.69583e+08 0x0000ffff78824da0: sbfiz x11, x4, #2, #32 0x0000ffff78824da4: add x7, x0, x11 ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 36 (line 44) 0x0000ffff78824da8: add xmethod, x18, x11 ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 30 (line 44) 0x0000ffff78824dac: ldr w2, [x7,#16] 0x0000ffff78824db0: ldr w13, [xmethod,#16] 0x0000ffff78824db4: add w13, w13, w2 0x0000ffff78824db8: cmp w13, wzr 0x0000ffff78824dbc: cneg w1, w13, lt 0x0000ffff78824dc0: add x11, x3, x11 0x0000ffff78824dc4: str w1, [x11,#16] 0x0000ffff78824dc8: ldr w2, [x7,#32] 0x0000ffff78824dcc: ldr w1, [xmethod,#32] 0x0000ffff78824dd0: add w13, w1, w2 0x0000ffff78824dd4: cmp w13, wzr 0x0000ffff78824dd8: cneg w1, w13, lt 0x0000ffff78824ddc: str w1, [x11,#32] 0x0000ffff78824de0: ldr w13, [x7,#48] 0x0000ffff78824de4: ldr w1, [xmethod,#48] 0x0000ffff78824de8: add w1, w1, w13 0x0000ffff78824dec: cmp w1, wzr 0x0000ffff78824df0: cneg w13, w1, lt 0x0000ffff78824df4: str w13, [x11,#48] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 41 (line 44) 0x0000ffff78824df8: ldr w1, [x7,#64] 0x0000ffff78824dfc: ldr w12, [xmethod,#64] 0x0000ffff78824e00: add w12, w12, w1 0x0000ffff78824e04: cmp w12, wzr 0x0000ffff78824e08: cneg w13, w12, lt 0x0000ffff78824e0c: add w4, w4, #0x10 ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 42 (line 43) 0x0000ffff78824e10: str w13, [x11,#64] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 41 (line 44) 0x0000ffff78824e14: cmp w4, w6 0x0000ffff78824e18: b.lt 0x0000ffff78824da0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 17 (line 43) Please provide me with a Java program that reproduces the result above, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Thu Jun 4 17:01:27 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 4 Jun 2020 18:01:27 +0100 Subject: [aarch64-port-dev ] RFR: 2020-06-04, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com> References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com> Message-ID: <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com> On 04/06/2020 10:23, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/webrev.01/ > > This is another integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was > generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge. > > The webrev is not very large, and mostly contains file moves and associated build changes. IMO, the > only thing that deserves explanation is the addition in src/share/vm/runtime/os.hpp: > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012413.html > > We would negotiate the push order w.r.t. upstream sync with Andrew Hughes. > > Changes: > Shenandoah: move parallelCleaning.* to shenandoah/ > Shenandoah: fix formats in ShenandoahStringSymbolTableUnlinkTask > [backport] 8245812: Shenandoah: compute root phase parallelism > [backport] 8245814: Shenandoah: reconsider format specifiers for stats > [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments > [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch > [backport] 8245461: Shenandoah: refine mode name()-s > [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties > [backport] 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots > Shenandoah: move barrier sets to their proper locations > Shenandoah: Fix build failure with +JFR -PCH > Shenandoah: fix runtime linking failure due to non-compiled shenandoahBarrierSetC1 > [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off > [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits > Merge > > Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 with a few nightlies > Is it possible to get the merge changeset itself, exported in git diff format? What webrev has produced shows moved files as huge diffs of one file being removed and another being added. os.hpp change is ugly, but I guess needed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Jun 4 17:06:56 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 4 Jun 2020 18:06:56 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b05 Upstream Sync In-Reply-To: <3c0dc3ea-354f-56fc-da18-6fc6102f4ed8@redhat.com> References: <0df7cf7b-079a-87f9-34ac-3e6ef1bc7f0c@redhat.com> <3c0dc3ea-354f-56fc-da18-6fc6102f4ed8@redhat.com> Message-ID: On 04/06/2020 07:36, Aleksey Shipilev wrote: > On 6/3/20 11:30 PM, Andrew Hughes wrote: >> Merge changesets: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jaxws/merge.changeset > > Look good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset > > Looks good. > > This would temporarily break Windows builds until 8246223 is here, right? Yes, should be fixed in b06. Not much that can be done about this because it wasn't caught before b05 was promoted. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/hotspot/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/root/merge.changeset > > Look good. > >> Ok to push? > > Yes. > Pushing now. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Thu Jun 4 17:07:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Jun 2020 19:07:22 +0200 Subject: [aarch64-port-dev ] RFR: 2020-06-04, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com> References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com> <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com> Message-ID: <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com> On 6/4/20 7:01 PM, Andrew Hughes wrote: > Is it possible to get the merge changeset itself, exported in git diff > format? What webrev has produced shows moved files as huge diffs of one > file being removed and another being added. Sure, here it is: https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.01.changeset I would have to redo the merge anyway, but I expect it would be the same. It was fully automatic. -- Thanks, -Aleksey From gnu.andrew at redhat.com Thu Jun 4 17:06:47 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 04 Jun 2020 17:06:47 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <202006041706.054H6lRt022710@aojmv0008.oracle.com> Changeset: 2f973e405849 Author: andrew Date: 2020-06-01 14:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/2f973e405849 Added tag jdk8u262-b05 for changeset ecb485e1572c ! .hgtags Changeset: 661e44b4a851 Author: andrew Date: 2020-06-02 05:08 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/661e44b4a851 Merge jdk8u262-b05 ! .hgtags Changeset: add96d4a4e82 Author: andrew Date: 2020-06-02 05:12 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/add96d4a4e82 Added tag aarch64-shenandoah-jdk8u262-b05 for changeset 661e44b4a851 ! .hgtags From gnu.andrew at redhat.com Thu Jun 4 17:06:56 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 04 Jun 2020 17:06:56 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <202006041706.054H6uuB022911@aojmv0008.oracle.com> Changeset: c4db66b4dcf7 Author: andrew Date: 2020-06-01 14:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/c4db66b4dcf7 Added tag jdk8u262-b05 for changeset 61a6c87db285 ! .hgtags Changeset: 11cc43f63583 Author: andrew Date: 2020-06-02 05:08 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/11cc43f63583 Merge jdk8u262-b05 ! .hgtags Changeset: fd70a68d284a Author: andrew Date: 2020-06-02 05:12 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/fd70a68d284a Added tag aarch64-shenandoah-jdk8u262-b05 for changeset 11cc43f63583 ! .hgtags From gnu.andrew at redhat.com Thu Jun 4 17:07:12 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 04 Jun 2020 17:07:12 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 3 new changesets Message-ID: <202006041707.054H7CGE023083@aojmv0008.oracle.com> Changeset: 0e54ba3037a2 Author: andrew Date: 2020-06-01 14:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/0e54ba3037a2 Added tag jdk8u262-b05 for changeset 96946cef7ead ! .hgtags Changeset: 702483d5017a Author: andrew Date: 2020-06-02 05:09 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/702483d5017a Merge jdk8u262-b05 ! .hgtags Changeset: 3bf12ab76730 Author: andrew Date: 2020-06-02 05:12 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/3bf12ab76730 Added tag aarch64-shenandoah-jdk8u262-b05 for changeset 702483d5017a ! .hgtags From gnu.andrew at redhat.com Thu Jun 4 17:07:20 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 04 Jun 2020 17:07:20 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 3 new changesets Message-ID: <202006041707.054H7Kkg023149@aojmv0008.oracle.com> Changeset: 26690d83c12e Author: andrew Date: 2020-06-01 14:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/26690d83c12e Added tag jdk8u262-b05 for changeset 07fc22e7080d ! .hgtags Changeset: c4203fd0a1ee Author: andrew Date: 2020-06-02 05:09 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/c4203fd0a1ee Merge jdk8u262-b05 ! .hgtags Changeset: 06dfdbe0cea1 Author: andrew Date: 2020-06-02 05:12 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/06dfdbe0cea1 Added tag aarch64-shenandoah-jdk8u262-b05 for changeset c4203fd0a1ee ! .hgtags From gnu.andrew at redhat.com Thu Jun 4 17:07:48 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 04 Jun 2020 17:07:48 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 4 new changesets Message-ID: <202006041707.054H7mDs023477@aojmv0008.oracle.com> Changeset: f7691a80458c Author: fyang Date: 2020-05-25 14:24 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f7691a80458c 8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in Reviewed-by: thartmann, kvn, andrew Contributed-by: zhouyong44 at huawei.com ! src/share/vm/opto/loopnode.cpp + test/compiler/loopopts/TestBeautifyLoops_2.java Changeset: de6565b66f94 Author: andrew Date: 2020-06-01 14:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/de6565b66f94 Added tag jdk8u262-b05 for changeset f7691a80458c ! .hgtags Changeset: 082fad85c036 Author: andrew Date: 2020-06-02 05:10 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/082fad85c036 Merge jdk8u262-b05 ! .hgtags ! src/share/vm/opto/loopnode.cpp Changeset: 1ffe5ca34ef7 Author: andrew Date: 2020-06-02 05:12 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1ffe5ca34ef7 Added tag aarch64-shenandoah-jdk8u262-b05 for changeset 082fad85c036 ! .hgtags From aph at redhat.com Thu Jun 4 15:34:23 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Jun 2020 16:34:23 +0100 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: <759f7e99-91a4-7c5f-36df-89b3ae96f74f@redhat.com> On 06/05/2020 09:46, Yang Zhang wrote: > Could you please help to review this patch? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243597 > Webrev: http://cr.openjdk.java.net/~yzhang/8243597/webrev.00/ I'm working on it. Sorry for the delay. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Jun 4 17:37:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Jun 2020 19:37:14 +0200 Subject: [aarch64-port-dev ] [8] RFR (XS) 8246482: Build failures with +JFR -PCH In-Reply-To: References: <47e2ccca-d33f-0269-9b02-93d624c7034d@redhat.com> Message-ID: <02a08109-d510-e7fa-112d-a9e38322564b@redhat.com> On 6/4/20 10:50 AM, Andrew Haley wrote: > On 03/06/2020 18:08, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8246482 >> >> This build failure is AArch64+JFR specific: >> >> .../hotspot/src/share/vm/jfr/writers/jfrEncoders.hpp: In static member function 'static size_t >> BigEndianEncoderImpl::encode(T, u1*)': >> .../hotspot/src/share/vm/jfr/writers/jfrEncoders.hpp:91:8: error: 'Bytes' has not been declared >> Bytes::put_Java_u2(dest, value); >> ^~~~~ >> >> Fix: >> >> diff -r 1ac56046129c src/share/vm/jfr/writers/jfrEncoders.hpp >> --- a/src/share/vm/jfr/writers/jfrEncoders.hpp Tue May 26 03:05:00 2020 +0100 >> +++ b/src/share/vm/jfr/writers/jfrEncoders.hpp Wed Jun 03 13:03:31 2020 -0400 >> @@ -43,6 +43,9 @@ >> #ifdef TARGET_ARCH_ppc >> # include "bytes_ppc.hpp" >> #endif >> +#ifdef TARGET_ARCH_aarch64 >> +# include "bytes_aarch64.hpp" >> +#endif >> >> // >> // The Encoding policy prescribes a template >> >> There is another one that is JFR+Shenandoah specific, it would come with a merge: >> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-June/012413.html >> https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e16a3f855bf3 >> >> Testing: aarch64 build with +JFR -PCH > > OK Thank you, pushed. -- -Aleksey From shade at redhat.com Thu Jun 4 17:52:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Jun 2020 19:52:46 +0200 Subject: [aarch64-port-dev ] RFR: 2020-06-04, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com> References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com> <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com> <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com> Message-ID: On 6/4/20 7:07 PM, Aleksey Shipilev wrote: > On 6/4/20 7:01 PM, Andrew Hughes wrote: >> Is it possible to get the merge changeset itself, exported in git diff >> format? What webrev has produced shows moved files as huge diffs of one >> file being removed and another being added. > > Sure, here it is: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.01.changeset > > I would have to redo the merge anyway, but I expect it would be the same. It was fully automatic. Redid the merge after recent 8u sync: https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/webrev.02/ https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.02.changeset AFAIU, it is pretty much the same. Just added the tags: aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 -- Thanks, -Aleksey From gnu.andrew at redhat.com Thu Jun 4 18:24:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 4 Jun 2020 19:24:49 +0100 Subject: [aarch64-port-dev ] RFR: 2020-06-04, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com> <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com> <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com> Message-ID: <4069f49a-d7e6-f079-7b41-d4671e755a68@redhat.com> On 04/06/2020 18:52, Aleksey Shipilev wrote: > On 6/4/20 7:07 PM, Aleksey Shipilev wrote: >> On 6/4/20 7:01 PM, Andrew Hughes wrote: >>> Is it possible to get the merge changeset itself, exported in git diff >>> format? What webrev has produced shows moved files as huge diffs of one >>> file being removed and another being added. >> >> Sure, here it is: >> https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.01.changeset >> >> I would have to redo the merge anyway, but I expect it would be the same. It was fully automatic. > > Redid the merge after recent 8u sync: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/webrev.02/ > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200604/merge.02.changeset > > AFAIU, it is pretty much the same. Just added the tags: > aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 > Thanks! This is a lot shorter and things like: diff --git a/src/share/vm/gc_implementation/shared/parallelCleaning.cpp b/src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp rename from src/share/vm/gc_implementation/shared/parallelCleaning.cpp rename to src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp --- a/src/share/vm/gc_implementation/shared/parallelCleaning.cpp +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp @@ -23,6 +23,6 @@ */ #include "precompiled.hpp" -#include "gc_implementation/shared/parallelCleaning.hpp" +#include "gc_implementation/shenandoah/shenandoahParallelCleaning.hpp" are much easier to read than two long diffs :) Push it and I'll do builds of the new tags. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Thu Jun 4 18:28:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 4 Jun 2020 20:28:14 +0200 Subject: [aarch64-port-dev ] RFR: 2020-06-04, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: <4069f49a-d7e6-f079-7b41-d4671e755a68@redhat.com> References: <5da81b78-61d0-6402-dbaf-ea879da354c8@redhat.com> <06aab6d9-803b-212c-79ec-291467c2951e@redhat.com> <776b5b9c-f48f-8851-7d9e-e75bd13beb75@redhat.com> <4069f49a-d7e6-f079-7b41-d4671e755a68@redhat.com> Message-ID: <90ab5c12-3089-ed82-0089-3ee0b75d89e7@redhat.com> On 6/4/20 8:24 PM, Andrew Hughes wrote: > Push it and I'll do builds of the new tags. Pushed. Cheers! -- -Aleksey From shade at redhat.com Thu Jun 4 18:27:37 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 04 Jun 2020 18:27:37 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 16 new changesets Message-ID: <202006041827.054IRcOh005498@aojmv0008.oracle.com> Changeset: aa45dd2b3ee3 Author: shade Date: 2020-05-26 14:45 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/aa45dd2b3ee3 Shenandoah: move parallelCleaning.* to shenandoah/ Reviewed-by: rkennke - src/share/vm/gc_implementation/shared/parallelCleaning.cpp - src/share/vm/gc_implementation/shared/parallelCleaning.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.hpp Changeset: b95b2bbb79e7 Author: shade Date: 2020-05-26 14:45 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b95b2bbb79e7 Shenandoah: fix formats in ShenandoahStringSymbolTableUnlinkTask Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.hpp Changeset: 7e157a282fa3 Author: shade Date: 2020-05-27 09:22 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7e157a282fa3 [backport] 8245812: Shenandoah: compute root phase parallelism Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp Changeset: fe04e68d29c8 Author: shade Date: 2020-05-27 15:57 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fe04e68d29c8 [backport] 8245814: Shenandoah: reconsider format specifiers for stats Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp Changeset: 36fd80f59d2a Author: shade Date: 2020-05-20 15:24 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/36fd80f59d2a [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: c910dfb55687 Author: shade Date: 2020-05-26 09:30 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c910dfb55687 [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 51ceee5b74da Author: shade Date: 2020-05-20 15:24 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/51ceee5b74da [backport] 8245461: Shenandoah: refine mode name()-s Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.hpp ! src/share/vm/gc_implementation/shenandoah/mode/shenandoahSATBMode.hpp Changeset: c9809df41411 Author: shade Date: 2020-05-26 09:30 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c9809df41411 [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.hpp Changeset: ab4d2e37ff6d Author: zgu Date: 2020-05-27 08:53 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ab4d2e37ff6d [backport] 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: db0c4aad24d9 Author: shade Date: 2020-06-02 22:34 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/db0c4aad24d9 Shenandoah: move barrier sets to their proper locations Reviewed-by: rkennke ! make/excludeSrc.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/vm.make ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp + src/share/vm/gc_implementation/shenandoah/c1/shenandoahBarrierSetC1.cpp + src/share/vm/gc_implementation/shenandoah/c1/shenandoahBarrierSetC1.hpp + src/share/vm/gc_implementation/shenandoah/c2/shenandoahBarrierSetC2.cpp + src/share/vm/gc_implementation/shenandoah/c2/shenandoahBarrierSetC2.hpp + src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.cpp + src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/subnode.cpp Changeset: e16a3f855bf3 Author: shade Date: 2020-06-02 22:34 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e16a3f855bf3 Shenandoah: Fix build failure with +JFR -PCH Reviewed-by: rkennke ! src/share/vm/runtime/os.hpp Changeset: f21732517ad9 Author: shade Date: 2020-06-03 14:21 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f21732517ad9 Shenandoah: fix runtime linking failure due to non-compiled shenandoahBarrierSetC1 Reviewed-by: rkennke ! make/linux/makefiles/vm.make Changeset: 381e483af639 Author: zgu Date: 2020-05-29 13:44 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/381e483af639 [backport] 8246162: Shenandoah: full GC does not mark code roots when class unloading is off Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 6398a22a767e Author: shade Date: 2020-05-26 09:31 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6398a22a767e [backport] 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/runtime/arguments.cpp Changeset: ed044fa3f6e3 Author: shade Date: 2020-06-04 19:38 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ed044fa3f6e3 Merge - src/share/vm/gc_implementation/shared/parallelCleaning.cpp - src/share/vm/gc_implementation/shared/parallelCleaning.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 86a87ce31ccb Author: shade Date: 2020-06-04 19:39 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/86a87ce31ccb Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset ed044fa3f6e3 ! .hgtags From shade at redhat.com Thu Jun 4 18:27:44 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 04 Jun 2020 18:27:44 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset 06dfdbe0cea1 Message-ID: <202006041827.054IRiD2005887@aojmv0008.oracle.com> Changeset: d9236197e0cc Author: shade Date: 2020-06-04 19:39 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/d9236197e0cc Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset 06dfdbe0cea1 ! .hgtags From shade at redhat.com Thu Jun 4 18:27:45 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 04 Jun 2020 18:27:45 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset add96d4a4e82 Message-ID: <202006041827.054IRjFw005915@aojmv0008.oracle.com> Changeset: 7a8895924076 Author: shade Date: 2020-06-04 19:39 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/7a8895924076 Added tag aarch64-shenandoah-jdk8u262-b05-shenandoah-merge-2020-06-04 for changeset add96d4a4e82 ! .hgtags From Yang.Zhang at arm.com Fri Jun 5 05:52:51 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Fri, 5 Jun 2020 05:52:51 +0000 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: Hi Andrew Thanks a lot for your review. The test cases in TestScalar.java are used to benchmark AbsI. @Benchmark public void testAbsI() { for (int n = 0; n < LOOP_CNT; n++) { for (int i = 0; i < ia.length; i += 4) { ----------> That stride is *4* will make auto-vectorization fail. Only AbsI node is generated. ic[i] = Math.abs(ia[i] + ib[i]); } } } To reproduce my result, you can try this test case: public static void absvs(short[] a, short[] b, short[] c) { for (int i = 0; i < a.length; i++) { c[i] = (short)Math.abs((a[i] + b[i])); } } Or you can also use jmh vector test cases which are used to benchmark vector abs. http://cr.openjdk.java.net/~yzhang/8243597/TestVect.java Regards Yang -----Original Message----- From: Andrew Haley Sent: Friday, June 5, 2020 12:10 AM To: Yang Zhang ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: Re: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs On 18/05/2020 06:51, Yang Zhang wrote: > Testing: > Full jtreg test > Vector API tests which cover vector abs > > Test case: > public static void absvs(short[] a, short[] b, short[] c) { > for (int i = 0; i < a.length; i++) { > c[i] = (short)Math.abs((a[i] + b[i])); > } > } > > Assembly code generated by C2: > 0x0000ffffaca3f3ac: ldr q17, [x16, #16] > 0x0000ffffaca3f3b0: ldr q16, [x15, #16] > 0x0000ffffaca3f3b4: add v16.8h, v16.8h, v17.8h > 0x0000ffffaca3f3b8: abs v16.8h, v16.8h > 0x0000ffffaca3f3c0: str q16, [x12, #16] > > Similar test cases for byte/int/long are also tested and NEON abs instruction is generated by C2. Unfortunately the test cases you provided do not include the method absvs(short). I'm not seeing this result. All I get with your patch applied in the case of your test TestScalar @Benchmark public void testAbsI() { for (int n = 0; n < LOOP_CNT; n++) { for (int i = 0; i < ia.length; i += 4) { ic[i] = Math.abs(ia[i] + ib[i]); } } } is ;; B18: # out( B18 B19 ) <- in( B17 B18 ) Loop( B18-B18 inner main of N82 strip mined) Freq: 9.69583e+08 0x0000ffff78824da0: sbfiz x11, x4, #2, #32 0x0000ffff78824da4: add x7, x0, x11 ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 36 (line 44) 0x0000ffff78824da8: add xmethod, x18, x11 ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 30 (line 44) 0x0000ffff78824dac: ldr w2, [x7,#16] 0x0000ffff78824db0: ldr w13, [xmethod,#16] 0x0000ffff78824db4: add w13, w13, w2 0x0000ffff78824db8: cmp w13, wzr 0x0000ffff78824dbc: cneg w1, w13, lt 0x0000ffff78824dc0: add x11, x3, x11 0x0000ffff78824dc4: str w1, [x11,#16] 0x0000ffff78824dc8: ldr w2, [x7,#32] 0x0000ffff78824dcc: ldr w1, [xmethod,#32] 0x0000ffff78824dd0: add w13, w1, w2 0x0000ffff78824dd4: cmp w13, wzr 0x0000ffff78824dd8: cneg w1, w13, lt 0x0000ffff78824ddc: str w1, [x11,#32] 0x0000ffff78824de0: ldr w13, [x7,#48] 0x0000ffff78824de4: ldr w1, [xmethod,#48] 0x0000ffff78824de8: add w1, w1, w13 0x0000ffff78824dec: cmp w1, wzr 0x0000ffff78824df0: cneg w13, w1, lt 0x0000ffff78824df4: str w13, [x11,#48] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 41 (line 44) 0x0000ffff78824df8: ldr w1, [x7,#64] 0x0000ffff78824dfc: ldr w12, [xmethod,#64] 0x0000ffff78824e00: add w12, w12, w1 0x0000ffff78824e04: cmp w12, wzr 0x0000ffff78824e08: cneg w13, w12, lt 0x0000ffff78824e0c: add w4, w4, #0x10 ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 42 (line 43) 0x0000ffff78824e10: str w13, [x11,#64] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 41 (line 44) 0x0000ffff78824e14: cmp w4, w6 0x0000ffff78824e18: b.lt 0x0000ffff78824da0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ; - org.openjdk.TestScalar::testAbsI at 17 (line 43) Please provide me with a Java program that reproduces the result above, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Jun 5 07:53:00 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Jun 2020 08:53:00 +0100 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: On 05/06/2020 06:52, Yang Zhang wrote: > The test cases in TestScalar.java are used to benchmark AbsI. When I ask for a java program that reproduces your result, it's not unreasonable for me to expect you to send one. You still haven't, and I don't understand why your test case wasn't provided. Can you please add a benchmark to your JMH benchmarks that actually shows the result you claimed? Thank you? > @Benchmark > public void testAbsI() { > for (int n = 0; n < LOOP_CNT; n++) { > for (int i = 0; i < ia.length; i += 4) { ----------> That stride is *4* will make auto-vectorization fail. Only AbsI node is generated. > ic[i] = Math.abs(ia[i] + ib[i]); > } > } > } > Or you can also use jmh vector test cases which are used to benchmark vector abs. > http://cr.openjdk.java.net/~yzhang/8243597/TestVect.java That is what I have been doing. They do not show the result above. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Yang.Zhang at arm.com Fri Jun 5 10:35:26 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Fri, 5 Jun 2020 10:35:26 +0000 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: Hi Andrew Please check this java program. http://cr.openjdk.java.net/~yzhang/8243597/TestAbs.java absvs is used to generate AbsVS node. Abss is used to generate AbsI node. I update the jmh benchmarks to make them aligned with absvs and abss above. The new results are as follows: New vector jmh: http://cr.openjdk.java.net/~yzhang/8243597/TestVectNew.java New scalar jmh: http://cr.openjdk.java.net/~yzhang/8243597/TestScalarNew.java Before: Benchmark (size) Mode Cnt Score Error Units TestVectNew.testVectAbsVB 1024 avgt 5 1221.852 ? 3.336 us/op TestVectNew.testVectAbsVI 1024 avgt 5 1450.422 ? 6.344 us/op TestVectNew.testVectAbsVL 1024 avgt 5 1429.934 ? 4.901 us/op TestVectNew.testVectAbsVS 1024 avgt 5 1227.134 ? 2.901 us/op TestScalarNew.testAbsI 1024 avgt 5 3777.007 ? 10.067 us/op TestScalarNew.testAbsL 1024 avgt 5 3776.717 ? 13.776 us/op TestScalarNew.testAbsS 1024 avgt 5 3153.195 ? 10.175 us/op After Benchmark (size) Mode Cnt Score Error Units TestVectNew.testVectAbsVB 1024 avgt 5 147.389 ? 0.921 us/op TestVectNew.testVectAbsVI 1024 avgt 5 444.318 ? 14.107 us/op TestVectNew.testVectAbsVL 1024 avgt 5 874.074 ? 2.224 us/op TestVectNew.testVectAbsVS 1024 avgt 5 224.559 ? 0.902 us/op TestScalarNew.testAbsI 1024 avgt 5 3087.172 ? 62.372 us/op TestScalarNew.testAbsL 1024 avgt 5 3113.322 ? 10.237 us/op TestScalarNew.testAbsS 1024 avgt 5 2723.048 ? 8.338 us/op Why the improvement of scalar abs is not as obvious as vector abs is because only one instruction is reduced than before. Before: 0x0000ffff80b763d8: cmp w12, #0x0 0x0000ffff80b763dc: neg w11, w12 0x0000ffff80b763e0: csel w11, w11, w12, lt // lt = tstop After: 0x0000ffffa0bd7a38: cmp w12, wzr 0x0000ffffa0bd7a3c: cneg w13, w12, lt // lt = tstop Ps. The generated assembly files are also attached. Before this patch http://cr.openjdk.java.net/~yzhang/8243597/TestAbs.java.aarch64.ori.asm After this patch: http://cr.openjdk.java.net/~yzhang/8243597/TestAbs.java.aarch64.asm Regards Yang -----Original Message----- From: Andrew Haley Sent: Friday, June 5, 2020 3:53 PM To: Yang Zhang ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: Re: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs On 05/06/2020 06:52, Yang Zhang wrote: > The test cases in TestScalar.java are used to benchmark AbsI. When I ask for a java program that reproduces your result, it's not unreasonable for me to expect you to send one. You still haven't, and I don't understand why your test case wasn't provided. Can you please add a benchmark to your JMH benchmarks that actually shows the result you claimed? Thank you? > @Benchmark > public void testAbsI() { > for (int n = 0; n < LOOP_CNT; n++) { > for (int i = 0; i < ia.length; i += 4) { ----------> That stride is *4* will make auto-vectorization fail. Only AbsI node is generated. > ic[i] = Math.abs(ia[i] + ib[i]); > } > } > } > Or you can also use jmh vector test cases which are used to benchmark vector abs. > http://cr.openjdk.java.net/~yzhang/8243597/TestVect.java That is what I have been doing. They do not show the result above. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Jun 5 15:01:48 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 5 Jun 2020 16:01:48 +0100 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: <90584282-f46e-e45b-72e9-acea5d01b999@redhat.com> On 05/06/2020 11:35, Yang Zhang wrote: > Hi Andrew > > Please check this java program. > http://cr.openjdk.java.net/~yzhang/8243597/TestAbs.java > absvs is used to generate AbsVS node. > Abss is used to generate AbsI node. > > I update the jmh benchmarks to make them aligned with absvs and abss above. The new results are as follows: > New vector jmh: > http://cr.openjdk.java.net/~yzhang/8243597/TestVectNew.java > New scalar jmh: > http://cr.openjdk.java.net/~yzhang/8243597/TestScalarNew.java > > Before: > Benchmark (size) Mode Cnt Score Error Units > TestVectNew.testVectAbsVB 1024 avgt 5 1221.852 ? 3.336 us/op > TestVectNew.testVectAbsVI 1024 avgt 5 1450.422 ? 6.344 us/op > TestVectNew.testVectAbsVL 1024 avgt 5 1429.934 ? 4.901 us/op > TestVectNew.testVectAbsVS 1024 avgt 5 1227.134 ? 2.901 us/op > TestScalarNew.testAbsI 1024 avgt 5 3777.007 ? 10.067 us/op > TestScalarNew.testAbsL 1024 avgt 5 3776.717 ? 13.776 us/op > TestScalarNew.testAbsS 1024 avgt 5 3153.195 ? 10.175 us/op > > After > Benchmark (size) Mode Cnt Score Error Units > TestVectNew.testVectAbsVB 1024 avgt 5 147.389 ? 0.921 us/op > TestVectNew.testVectAbsVI 1024 avgt 5 444.318 ? 14.107 us/op > TestVectNew.testVectAbsVL 1024 avgt 5 874.074 ? 2.224 us/op > TestVectNew.testVectAbsVS 1024 avgt 5 224.559 ? 0.902 us/op > TestScalarNew.testAbsI 1024 avgt 5 3087.172 ? 62.372 us/op > TestScalarNew.testAbsL 1024 avgt 5 3113.322 ? 10.237 us/op > TestScalarNew.testAbsS 1024 avgt 5 2723.048 ? 8.338 us/op I tried TestAbs with a ThunderX2, and it certainly looks nice: great improvement across the board. Benchmark Mode Cnt Score Error Units TestAbs.absvb avgt 8 971.100 ? 1.544 ns/op TestAbs.absvs avgt 8 983.061 ? 1.626 ns/op TestAbs.absvi avgt 8 1170.826 ? 11.055 ns/op TestAbs.absvl avgt 8 1159.936 ? 3.747 ns/op Benchmark Mode Cnt Score Error Units TestAbs.absvb avgt 8 117.981 ? 1.048 ns/op TestAbs.absvs avgt 8 174.949 ? 4.158 ns/op TestAbs.absvi avgt 8 352.012 ? 0.884 ns/op TestAbs.absvl avgt 8 702.076 ? 0.116 ns/op OK, we're good to go. Thanks, approved. > Why the improvement of scalar abs is not as obvious as vector abs is because only one instruction is reduced than before. > Before: > 0x0000ffff80b763d8: cmp w12, #0x0 > 0x0000ffff80b763dc: neg w11, w12 > 0x0000ffff80b763e0: csel w11, w11, w12, lt // lt = tstop > > After: > 0x0000ffffa0bd7a38: cmp w12, wzr > 0x0000ffffa0bd7a3c: cneg w13, w12, lt // lt = tstop That's interesting, too: we don't have a cneg pattern, which is I guess an omission. > Ps. The generated assembly files are also attached. > Before this patch > http://cr.openjdk.java.net/~yzhang/8243597/TestAbs.java.aarch64.ori.asm > After this patch: > http://cr.openjdk.java.net/~yzhang/8243597/TestAbs.java.aarch64.asm Great. Again, sorry for the slow response. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Sun Jun 7 03:17:36 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 7 Jun 2020 03:17:36 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64 Message-ID: <1284983135.1943.1591499856598.JavaMail.javamailuser@localhost> 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/jdk14/openjdk-jtreg-nightly-tests/summary/2020/156/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 Build 6: aarch64/2020/may/07 pass: 5,763; fail: 44 Build 7: aarch64/2020/may/12 pass: 5,761; fail: 46 Build 8: aarch64/2020/may/15 pass: 5,784; fail: 46 Build 9: aarch64/2020/may/28 pass: 5,785; fail: 45 Build 10: aarch64/2020/jun/01 pass: 5,784; fail: 47 Build 11: aarch64/2020/jun/04 pass: 5,787; fail: 45 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 Build 6: aarch64/2020/may/07 pass: 8,835; fail: 517; error: 20 Build 7: aarch64/2020/may/12 pass: 8,836; fail: 517; error: 19 Build 8: aarch64/2020/may/15 pass: 8,845; fail: 509; error: 18 Build 9: aarch64/2020/may/28 pass: 8,838; fail: 516; error: 18 Build 10: aarch64/2020/jun/01 pass: 8,847; fail: 509; error: 16 Build 11: aarch64/2020/jun/04 pass: 8,838; fail: 517; error: 17 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Build 7: aarch64/2020/may/07 pass: 4,031 Build 8: aarch64/2020/may/12 pass: 4,031 Build 9: aarch64/2020/may/15 pass: 4,031 Build 10: aarch64/2020/may/28 pass: 4,031 Build 11: aarch64/2020/jun/01 pass: 4,031 Build 12: aarch64/2020/jun/04 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/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.91x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/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/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/128/results/ 2020-05-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/133/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/136/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/149/results/ 2020-06-02 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/153/results/ 2020-06-07 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/156/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/ From ci_notify at linaro.org Mon Jun 8 14:01:55 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 8 Jun 2020 14:01:55 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <1033302400.2086.1591624916094.JavaMail.javamailuser@localhost> 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/jdk11u/openjdk-jtreg-nightly-tests/summary/2020/159/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 1: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 2: aarch64/2019/dec/17 pass: 5,775; fail: 1 Build 3: aarch64/2019/dec/21 pass: 5,775; fail: 1 Build 4: aarch64/2020/jan/16 pass: 5,775; fail: 1 Build 5: aarch64/2020/jan/30 pass: 5,791; fail: 1 Build 6: aarch64/2020/feb/06 pass: 5,791; fail: 1 Build 7: aarch64/2020/feb/13 pass: 5,792; fail: 1 Build 8: aarch64/2020/apr/30 pass: 5,813; fail: 1 Build 9: aarch64/2020/may/07 pass: 5,813; fail: 2 Build 10: aarch64/2020/may/15 pass: 5,814; fail: 1 Build 11: aarch64/2020/may/30 pass: 5,818; fail: 1 Build 12: aarch64/2020/jun/02 pass: 5,818; fail: 1 Build 13: aarch64/2020/jun/04 pass: 5,818; fail: 1 Build 14: aarch64/2020/jun/07 pass: 5,818; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 1: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 2: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 Build 3: aarch64/2019/dec/21 pass: 8,499; fail: 496; error: 10 Build 4: aarch64/2020/jan/16 pass: 8,513; fail: 474; error: 17 Build 5: aarch64/2020/jan/30 pass: 8,513; fail: 501; error: 13 Build 6: aarch64/2020/feb/06 pass: 8,496; fail: 517; error: 14 Build 7: aarch64/2020/feb/13 pass: 8,509; fail: 507; error: 14 Build 8: aarch64/2020/apr/30 pass: 8,534; fail: 519; error: 15 Build 9: aarch64/2020/may/07 pass: 8,540; fail: 515; error: 12 Build 10: aarch64/2020/may/15 pass: 8,558; fail: 498; error: 11 Build 11: aarch64/2020/may/30 pass: 8,544; fail: 507; error: 16 Build 12: aarch64/2020/jun/02 pass: 8,535; fail: 515; error: 17 Build 13: aarch64/2020/jun/04 pass: 8,560; fail: 496; error: 13 Build 14: aarch64/2020/jun/07 pass: 8,534; fail: 523; error: 12 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/08 pass: 3,910 Build 1: aarch64/2019/dec/14 pass: 3,910 Build 2: aarch64/2019/dec/17 pass: 3,910 Build 3: aarch64/2019/dec/21 pass: 3,910 Build 4: aarch64/2020/jan/16 pass: 3,910 Build 5: aarch64/2020/jan/30 pass: 3,913 Build 6: aarch64/2020/feb/06 pass: 3,913 Build 7: aarch64/2020/feb/13 pass: 3,913 Build 8: aarch64/2020/apr/30 pass: 3,913 Build 9: aarch64/2020/may/07 pass: 3,913 Build 10: aarch64/2020/may/15 pass: 3,913 Build 11: aarch64/2020/may/30 pass: 3,913 Build 12: aarch64/2020/jun/02 pass: 3,913 Build 13: aarch64/2020/jun/04 pass: 3,913 Build 14: aarch64/2020/jun/07 pass: 3,913 Previous results can be found here: http://openjdk.linaro.org/jdk11u/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.21x Relative performance: Server critical-jOPS (nc): 8.40x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/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/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ 2019-12-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/355/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/037/results/ 2020-02-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/044/results/ 2020-05-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/121/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/128/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/136/results/ 2020-06-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/151/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/154/results/ 2020-06-07 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/156/results/ 2020-06-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/159/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From ci_notify at linaro.org Wed Jun 10 04:09:03 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 10 Jun 2020 04:09:03 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <1537063616.2406.1591762144045.JavaMail.javamailuser@localhost> 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/jdk13/openjdk-jtreg-nightly-tests/summary/2020/161/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/30 pass: 5,645; fail: 2 Build 1: aarch64/2019/aug/01 pass: 5,646; fail: 1 Build 2: aarch64/2019/aug/03 pass: 5,646; fail: 1 Build 3: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 4: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 5: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 6: aarch64/2019/nov/12 pass: 5,652 Build 7: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 8: aarch64/2019/nov/16 pass: 5,652 Build 9: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 10: aarch64/2019/dec/14 pass: 5,652 Build 11: aarch64/2020/jan/16 pass: 5,652 Build 12: aarch64/2020/may/28 pass: 5,669 Build 13: aarch64/2020/jun/02 pass: 5,677 Build 14: aarch64/2020/jun/09 pass: 5,691 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/30 pass: 8,610; fail: 529; error: 32 Build 1: aarch64/2019/aug/01 pass: 8,620; fail: 527; error: 24 Build 2: aarch64/2019/aug/03 pass: 8,596; fail: 552; error: 23 Build 3: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 4: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 5: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 6: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 7: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 8: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 9: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 10: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 11: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 12: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 Build 13: aarch64/2020/jun/02 pass: 8,686; fail: 509; error: 17 Build 14: aarch64/2020/jun/09 pass: 8,698; fail: 505; error: 16 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/30 pass: 3,964 Build 1: aarch64/2019/aug/01 pass: 3,964 Build 2: aarch64/2019/aug/03 pass: 3,964 Build 3: aarch64/2019/aug/06 pass: 3,964 Build 4: aarch64/2019/aug/08 pass: 3,964 Build 5: aarch64/2019/aug/10 pass: 3,964 Build 6: aarch64/2019/nov/12 pass: 3,964 Build 7: aarch64/2019/nov/14 pass: 3,964 Build 8: aarch64/2019/nov/16 pass: 3,964 Build 9: aarch64/2019/dec/03 pass: 3,964 Build 10: aarch64/2019/dec/14 pass: 3,964 Build 11: aarch64/2020/jan/16 pass: 3,964 Build 12: aarch64/2020/may/28 pass: 3,964 Build 13: aarch64/2020/jun/02 pass: 3,964 Build 14: aarch64/2020/jun/09 pass: 3,965 Previous results can be found here: http://openjdk.linaro.org/jdk13/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.54x Relative performance: Server critical-jOPS (nc): 8.89x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/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/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-07-26 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/206/results/ 2019-07-31 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/211/results/ 2019-08-02 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/213/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/154/results/ 2020-06-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/161/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From gnu.andrew at redhat.com Wed Jun 10 20:29:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 10 Jun 2020 21:29:49 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b06 Upstream Sync Message-ID: <8c66b7c0-113f-2996-14fd-4135a74d8442@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b06: - JDK-8246223: Windows build fails after JDK-8227269 Main issues of note: None, clean merge. Things should be quieter now, as we're in rampdown for 8u262. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 + b/src/share/back/classTrack.c | 20 +++++++++++--------- 2 files changed, 12 insertions(+), 9 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From vladimir.kozlov at oracle.com Thu Jun 11 00:40:19 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jun 2020 17:40:19 -0700 Subject: [aarch64-port-dev ] [15] RFR(XS) 8247350: [aarch64] assert(false) failed: wrong size of mach node Message-ID: <612fcc45-0886-eb21-ef25-723d934a358b@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8247350 https://cr.openjdk.java.net/~kvn/8247350/webrev.00/ Code size for decodeHeapOop is different in scratch buffer with -XX:+VerifyOops flag on. The difference comes from MacroAssembler::mov_immediate64() which generates different code if distance to message string 'b' in mov(rscratch1, (address)b) is different. Use movptr() instead of mov() in verify_oop() method to generate consistent code for loading C string address. Added debug dump code in case of mismatching code generation. Tested with failing test case. Thanks, Vladimir From vladimir.kozlov at oracle.com Thu Jun 11 01:06:19 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Jun 2020 18:06:19 -0700 Subject: [aarch64-port-dev ] [15] RFR(XS) 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: <4E8B20A3-F150-45E6-9CF5-95D4CD8DA905@amazon.com> References: <612fcc45-0886-eb21-ef25-723d934a358b@oracle.com> <4E8B20A3-F150-45E6-9CF5-95D4CD8DA905@amazon.com> Message-ID: <6765b33e-b22a-4312-b6bf-eac2e6142d5e@oracle.com> Thank you, Azeem Vladimir On 6/10/20 5:47 PM, Jiva, Azeem wrote: > Looks good to me. > From adinn at redhat.com Thu Jun 11 08:32:53 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 11 Jun 2020 09:32:53 +0100 Subject: [aarch64-port-dev ] [15] RFR(XS) 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: <612fcc45-0886-eb21-ef25-723d934a358b@oracle.com> References: <612fcc45-0886-eb21-ef25-723d934a358b@oracle.com> Message-ID: <9d651b83-3a63-d4ae-37e9-0a664bb702cd@redhat.com> On 11/06/2020 01:40, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8247350 > https://cr.openjdk.java.net/~kvn/8247350/webrev.00/ > > Code size for decodeHeapOop is different in scratch buffer with > -XX:+VerifyOops flag on. The difference comes from > MacroAssembler::mov_immediate64() which generates different code if > distance to message string 'b' in mov(rscratch1, (address)b) is different. > > Use movptr() instead of mov() in verify_oop() method to generate > consistent code for loading C string address. > Added debug dump code in case of mismatching code generation. > > Tested with failing test case. Looks ok to me, Vladimir. 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 From shade at redhat.com Thu Jun 11 08:55:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 11 Jun 2020 10:55:46 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b06 Upstream Sync In-Reply-To: <8c66b7c0-113f-2996-14fd-4135a74d8442@redhat.com> References: <8c66b7c0-113f-2996-14fd-4135a74d8442@redhat.com> Message-ID: On 6/10/20 10:29 PM, Andrew Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/ > > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/root/merge.changeset Look trivially good. > Ok to push? Yes! -- Thanks, -Aleksey From vladimir.kozlov at oracle.com Thu Jun 11 16:35:16 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Jun 2020 09:35:16 -0700 Subject: [aarch64-port-dev ] [15] RFR(XS) 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: <9d651b83-3a63-d4ae-37e9-0a664bb702cd@redhat.com> References: <612fcc45-0886-eb21-ef25-723d934a358b@oracle.com> <9d651b83-3a63-d4ae-37e9-0a664bb702cd@redhat.com> Message-ID: Thank you, Andrew Vladimir On 6/11/20 1:32 AM, Andrew Dinn wrote: > On 11/06/2020 01:40, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8247350 >> https://cr.openjdk.java.net/~kvn/8247350/webrev.00/ >> >> Code size for decodeHeapOop is different in scratch buffer with >> -XX:+VerifyOops flag on. The difference comes from >> MacroAssembler::mov_immediate64() which generates different code if >> distance to message string 'b' in mov(rscratch1, (address)b) is different. >> >> Use movptr() instead of mov() in verify_oop() method to generate >> consistent code for loading C string address. >> Added debug dump code in case of mismatching code generation. >> >> Tested with failing test case. > Looks ok to me, Vladimir. > > 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 > From vladimir.kozlov at oracle.com Thu Jun 11 16:56:23 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 11 Jun 2020 09:56:23 -0700 Subject: [aarch64-port-dev ] RFR(S): 8247200: [aarch64] assert((unsigned)fpargs < 32) In-Reply-To: <40b781a4-5a1f-bd83-0dab-00dc2890e06d@oracle.com> References: <40b781a4-5a1f-bd83-0dab-00dc2890e06d@oracle.com> Message-ID: CCing to aarch64 mailing list. Vladimir On 6/11/20 1:24 AM, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8247200 > Webrev: http://cr.openjdk.java.net/~phedlin/tr8247200/ > > > Removing assert and some associated dead code. > > > Testing: tier1-3,6 > > > Best regards, > Patric From boris.ulasevich at bell-sw.com Fri Jun 12 18:10:13 2020 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 12 Jun 2020 21:10:13 +0300 Subject: [aarch64-port-dev ] AARCH64 optimization: using TBZ instruction for bit check Message-ID: Hi all, Please review the new AARCH64 instruction selection rules. The change applies TBZ instruction for bit checks: "if ((var&16) == 16)". This makes 17% performance improvement on the benchmark and 5% on a real application. http://bugs.openjdk.java.net/browse/JDK-8247408 http://cr.openjdk.java.net/~bulasevich/8247408/webrev.00 - from the full change I excluded far branch test is because it works a long time, and I'm not sure C2 will not change its behaviour: http://cr.openjdk.java.net/~bulasevich/8247408/webrev.00.plus The change was tested on jtreg in fastdebug mode: no regressions. thanks, Boris ======================================================================================== Benchmark?????????????????????????????????????????????? Mode Cnt??????? Score??? Error? Units?????????? Score???? Error TBZBenchmark.cmpAndBranch2Tbz????????????????????????? thrpt?? 25 1329060.879 ? 42.780? ops/s???? 1504990.708 ? 158.096 TBZBenchmark.cmpAndBranch2Tbz:CPI????????????????????? thrpt 5??????? 0.325 ?? 0.001?? #/op?????????? 0.410 ??? 0.001 TBZBenchmark.cmpAndBranch2Tbz:L1-dcache-load-misses??? thrpt 5??????? 0.019 ?? 0.031?? #/op?????????? 0.018 ??? 0.025 TBZBenchmark.cmpAndBranch2Tbz:L1-dcache-loads????????? thrpt 5 16.811 ?? 0.791?? #/op????????? 16.809 ??? 0.914 TBZBenchmark.cmpAndBranch2Tbz:L1-dcache-store-misses?? thrpt 5??????? 0.016 ?? 0.017?? #/op?????????? 0.014 ??? 0.022 TBZBenchmark.cmpAndBranch2Tbz:L1-dcache-stores???????? thrpt 5 16.704 ?? 0.634?? #/op????????? 16.771 ??? 0.539 TBZBenchmark.cmpAndBranch2Tbz:L1-icache-load-misses??? thrpt 5??????? 0.017 ?? 0.027?? #/op?????????? 0.016 ??? 0.023 TBZBenchmark.cmpAndBranch2Tbz:L1-icache-loads????????? thrpt 5 1811.848 ?? 3.552?? #/op??????? 1148.737 ??? 2.993 TBZBenchmark.cmpAndBranch2Tbz:branch-misses??????????? thrpt 5??????? 1.013 ?? 0.009?? #/op?????????? 1.011 ??? 0.018 TBZBenchmark.cmpAndBranch2Tbz:cycles?????????????????? thrpt 5 1882.193 ?? 3.799?? #/op??????? 1662.994 ??? 5.935 TBZBenchmark.cmpAndBranch2Tbz:dTLB-load-misses???????? thrpt 5??????? 0.004 ?? 0.008?? #/op?????????? 0.005 ??? 0.016 TBZBenchmark.cmpAndBranch2Tbz:dTLB-loads?????????????? thrpt 5 16.687 ?? 0.732?? #/op????????? 16.669 ??? 0.958 TBZBenchmark.cmpAndBranch2Tbz:iTLB-load-misses???????? thrpt 5??????? 0.003 ?? 0.009?? #/op?????????? 0.003 ??? 0.008 TBZBenchmark.cmpAndBranch2Tbz:iTLB-loads?????????????? thrpt 5 1586.390 ?? 2.612?? #/op??????? 1353.981 ??? 3.469 TBZBenchmark.cmpAndBranch2Tbz:instructions???????????? thrpt 5 5791.824 ? 15.362?? #/op??????? 4055.443 ?? 17.785 TBZBenchmark.cmpAndBranch2Tbz:stalled-cycles-backend?? thrpt 5??????? 5.279 ?? 1.968?? #/op????????? 20.459 ??? 5.258 TBZBenchmark.cmpAndBranch2Tbz:stalled-cycles-frontend? thrpt 5 66.808 ?? 0.700?? #/op????????? 12.738 ??? 1.040 public class TBZBenchmark { ??? @Benchmark ??? public int cmpAndBranch2Tbz() { ??????? int count = 0; ??????? for (int value = 0; value < 1000; value++) { ??????????? if ((value & 32) == 32) { ??????????????? count--; ??????????? } else { ??????????????? count++; ??????????? } ??????? } ??????? return count; ??? } } From ci_notify at linaro.org Sun Jun 14 18:48:51 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 14 Jun 2020 18:48:51 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64 Message-ID: <423007335.3353.1592160531588.JavaMail.javamailuser@localhost> 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/jdk14/openjdk-jtreg-nightly-tests/summary/2020/165/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 Build 6: aarch64/2020/may/07 pass: 5,763; fail: 44 Build 7: aarch64/2020/may/12 pass: 5,761; fail: 46 Build 8: aarch64/2020/may/15 pass: 5,784; fail: 46 Build 9: aarch64/2020/may/28 pass: 5,785; fail: 45 Build 10: aarch64/2020/jun/01 pass: 5,784; fail: 47 Build 11: aarch64/2020/jun/04 pass: 5,787; fail: 45 Build 12: aarch64/2020/jun/13 pass: 5,786; fail: 46 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 Build 6: aarch64/2020/may/07 pass: 8,835; fail: 517; error: 20 Build 7: aarch64/2020/may/12 pass: 8,836; fail: 517; error: 19 Build 8: aarch64/2020/may/15 pass: 8,845; fail: 509; error: 18 Build 9: aarch64/2020/may/28 pass: 8,838; fail: 516; error: 18 Build 10: aarch64/2020/jun/01 pass: 8,847; fail: 509; error: 16 Build 11: aarch64/2020/jun/04 pass: 8,838; fail: 517; error: 17 Build 12: aarch64/2020/jun/13 pass: 8,846; fail: 510; error: 17 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Build 7: aarch64/2020/may/07 pass: 4,031 Build 8: aarch64/2020/may/12 pass: 4,031 Build 9: aarch64/2020/may/15 pass: 4,031 Build 10: aarch64/2020/may/28 pass: 4,031 Build 11: aarch64/2020/jun/01 pass: 4,031 Build 12: aarch64/2020/jun/04 pass: 4,031 Build 13: aarch64/2020/jun/13 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/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): 9.18x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/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/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/128/results/ 2020-05-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/133/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/136/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/149/results/ 2020-06-02 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/153/results/ 2020-06-07 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/156/results/ 2020-06-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/165/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/ From aph at redhat.com Mon Jun 15 09:17:07 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Jun 2020 10:17:07 +0100 Subject: [aarch64-port-dev ] RFR(S): 8247200: [aarch64] assert((unsigned)fpargs < 32) In-Reply-To: References: <40b781a4-5a1f-bd83-0dab-00dc2890e06d@oracle.com> Message-ID: <61acad9c-98a1-46b2-8e24-d3cb84fa2628@redhat.com> On 11/06/2020 17:56, Vladimir Kozlov wrote: > On 6/11/20 1:24 AM, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8247200 >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8247200/ >> >> >> Removing assert and some associated dead code. Looks good. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jun 15 09:28:59 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Jun 2020 10:28:59 +0100 Subject: [aarch64-port-dev ] AARCH64 optimization: using TBZ instruction for bit check In-Reply-To: References: Message-ID: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> On 12/06/2020 19:10, Boris Ulasevich wrote: > Please review the new AARCH64 instruction selection rules. > The change applies TBZ instruction for bit checks: "if ((var&16) == 16)". > This makes 17% performance improvement on the benchmark and 5% on a real > application. Please forgive me if I am misunderstanding, but... This is strange Java for anyone to write. The expression "((var&16) == 16)" is, I think, equivalent to "((var&16) != 0)". Do you believe that it is wise to add new patterns to do this to (potentially) every HotSpot back end rather than canonicalize the expression during the machine-independent part of C2? This would have the same improvement on all targets. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Jun 15 19:23:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 15 Jun 2020 20:23:39 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b06 Upstream Sync In-Reply-To: References: <8c66b7c0-113f-2996-14fd-4135a74d8442@redhat.com> Message-ID: <64951325-50bd-511c-e077-6351003d08d2@redhat.com> On 11/06/2020 09:55, Aleksey Shipilev wrote: > On 6/10/20 10:29 PM, Andrew Hughes wrote: >> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/ >> >> Merge changesets: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/jaxws/merge.changeset > > Look trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/hotspot/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b06/root/merge.changeset > > Look trivially good. > >> Ok to push? > > Yes! > Pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jun 15 19:23:34 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 15 Jun 2020 19:23:34 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <202006151923.05FJNYMq017586@aojmv0008.oracle.com> Changeset: 4f5c1e68c85e Author: andrew Date: 2020-06-07 18:57 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/4f5c1e68c85e Added tag jdk8u262-b06 for changeset 2f973e405849 ! .hgtags Changeset: 7efe633748e5 Author: andrew Date: 2020-06-08 12:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/7efe633748e5 Merge jdk8u262-b06 ! .hgtags Changeset: 3fbc7863e3cd Author: andrew Date: 2020-06-08 12:15 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/3fbc7863e3cd Added tag aarch64-shenandoah-jdk8u262-b06 for changeset 7efe633748e5 ! .hgtags From gnu.andrew at redhat.com Mon Jun 15 19:23:44 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 15 Jun 2020 19:23:44 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <202006151923.05FJNi0c017725@aojmv0008.oracle.com> Changeset: 7709711670b4 Author: andrew Date: 2020-06-07 18:57 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/7709711670b4 Added tag jdk8u262-b06 for changeset c4db66b4dcf7 ! .hgtags Changeset: 13ab85819388 Author: andrew Date: 2020-06-08 12:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/13ab85819388 Merge jdk8u262-b06 ! .hgtags Changeset: 7310e941ca49 Author: andrew Date: 2020-06-08 12:15 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/7310e941ca49 Added tag aarch64-shenandoah-jdk8u262-b06 for changeset 13ab85819388 ! .hgtags From gnu.andrew at redhat.com Mon Jun 15 19:23:53 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 15 Jun 2020 19:23:53 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 3 new changesets Message-ID: <202006151923.05FJNr64017883@aojmv0008.oracle.com> Changeset: ebb0a284b7e7 Author: andrew Date: 2020-06-07 18:57 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/ebb0a284b7e7 Added tag jdk8u262-b06 for changeset ddbd85633843 ! .hgtags Changeset: 2863d39135d5 Author: andrew Date: 2020-06-08 12:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/2863d39135d5 Merge jdk8u262-b06 ! .hgtags Changeset: 9d82c8a8e14a Author: andrew Date: 2020-06-08 12:15 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/9d82c8a8e14a Added tag aarch64-shenandoah-jdk8u262-b06 for changeset 2863d39135d5 ! .hgtags From gnu.andrew at redhat.com Mon Jun 15 19:24:36 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 15 Jun 2020 19:24:36 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 4 new changesets Message-ID: <202006151924.05FJOaMY018367@aojmv0008.oracle.com> Changeset: 097f47e7fe97 Author: andrew Date: 2020-06-07 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/097f47e7fe97 8246223: Windows build fails after JDK-8227269 Summary: MSVC 2013 uses a modified variant of C90 and requires all declarations before statements Reviewed-by: andrew Contributed-by: Alex Kashchenko ! src/share/back/classTrack.c Changeset: a8d895846054 Author: andrew Date: 2020-06-07 18:57 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/a8d895846054 Added tag jdk8u262-b06 for changeset 097f47e7fe97 ! .hgtags Changeset: 1cf70821a22b Author: andrew Date: 2020-06-08 12:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1cf70821a22b Merge jdk8u262-b06 ! .hgtags Changeset: b5c4cff71824 Author: andrew Date: 2020-06-08 12:15 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/b5c4cff71824 Added tag aarch64-shenandoah-jdk8u262-b06 for changeset 1cf70821a22b ! .hgtags From gnu.andrew at redhat.com Mon Jun 15 19:24:48 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 15 Jun 2020 19:24:48 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 3 new changesets Message-ID: <202006151924.05FJOmEv018459@aojmv0008.oracle.com> Changeset: 89fb452b3688 Author: andrew Date: 2020-06-07 18:57 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/89fb452b3688 Added tag jdk8u262-b06 for changeset de6565b66f94 ! .hgtags Changeset: 6c828395dd7f Author: andrew Date: 2020-06-08 12:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6c828395dd7f Merge jdk8u262-b06 ! .hgtags Changeset: 408cdb13e63e Author: andrew Date: 2020-06-08 12:15 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/408cdb13e63e Added tag aarch64-shenandoah-jdk8u262-b06 for changeset 6c828395dd7f ! .hgtags From ci_notify at linaro.org Tue Jun 16 14:34:35 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 16 Jun 2020 14:34:35 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <1798486930.3774.1592318076109.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2020/168/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 1: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 2: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 Build 3: aarch64/2019/dec/21 pass: 848; fail: 10; error: 2 Build 4: aarch64/2020/jan/09 pass: 848; fail: 10; error: 1 Build 5: aarch64/2020/jan/11 pass: 848; fail: 10; error: 1 Build 6: aarch64/2020/jan/20 pass: 848; fail: 10; error: 1 Build 7: aarch64/2020/jan/25 pass: 848; fail: 10; error: 1 Build 8: aarch64/2020/may/06 pass: 885; fail: 12; error: 1 Build 9: aarch64/2020/may/10 pass: 885; fail: 12; error: 1 Build 10: aarch64/2020/may/12 pass: 885; fail: 12; error: 1 Build 11: aarch64/2020/may/19 pass: 886; fail: 12; error: 1 Build 12: aarch64/2020/may/30 pass: 890; fail: 11; error: 1 Build 13: aarch64/2020/jun/07 pass: 891; fail: 11; error: 1 Build 14: aarch64/2020/jun/16 pass: 890; fail: 11; error: 2 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 Build 1: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 Build 2: aarch64/2019/dec/21 pass: 5,970; fail: 262; error: 21 Build 3: aarch64/2020/jan/09 pass: 5,963; fail: 276; error: 20 Build 4: aarch64/2020/jan/11 pass: 5,959; fail: 279; error: 21 Build 5: aarch64/2020/jan/20 pass: 5,987; fail: 256; error: 24 Build 6: aarch64/2020/jan/25 pass: 5,962; fail: 285; error: 22 Build 7: aarch64/2020/feb/03 pass: 5,976; fail: 278; error: 19 Build 8: aarch64/2020/may/06 pass: 5,998; fail: 281; error: 21 Build 9: aarch64/2020/may/10 pass: 6,025; fail: 695; error: 21 Build 10: aarch64/2020/may/12 pass: 6,011; fail: 709; error: 21 Build 11: aarch64/2020/may/19 pass: 6,009; fail: 712; error: 22 Build 12: aarch64/2020/may/30 pass: 6,013; fail: 709; error: 23 Build 13: aarch64/2020/jun/07 pass: 6,016; fail: 711; error: 21 Build 14: aarch64/2020/jun/16 pass: 6,017; fail: 709; error: 22 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 1: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 2: aarch64/2019/dec/19 pass: 3,117; fail: 2 Build 3: aarch64/2019/dec/21 pass: 3,117; fail: 2 Build 4: aarch64/2020/jan/09 pass: 3,117; fail: 2 Build 5: aarch64/2020/jan/11 pass: 3,117; fail: 2 Build 6: aarch64/2020/jan/20 pass: 3,117; fail: 2 Build 7: aarch64/2020/jan/25 pass: 3,117; fail: 2 Build 8: aarch64/2020/may/06 pass: 3,117; fail: 2 Build 9: aarch64/2020/may/10 pass: 3,117; fail: 2 Build 10: aarch64/2020/may/12 pass: 3,117; fail: 2 Build 11: aarch64/2020/may/19 pass: 3,117; fail: 2 Build 12: aarch64/2020/may/30 pass: 3,117; fail: 2 Build 13: aarch64/2020/jun/07 pass: 3,117; fail: 2 Build 14: aarch64/2020/jun/16 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 6.65x Relative performance: Server critical-jOPS (nc): 8.71x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 172.13 Server 172.13 / Server 2014-04-01 (71.00): 2.42x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ 2019-12-22 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/355/results/ 2020-01-09 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/009/results/ 2020-01-11 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/011/results/ 2020-01-20 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/020/results/ 2020-01-25 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/025/results/ 2020-05-06 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/127/results/ 2020-05-10 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/131/results/ 2020-05-14 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/133/results/ 2020-05-20 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/140/results/ 2020-06-01 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/151/results/ 2020-06-08 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/159/results/ 2020-06-16 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/168/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From gnu.andrew at redhat.com Tue Jun 16 23:12:14 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 17 Jun 2020 00:12:14 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b07 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b07: - JDK-8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing - JDK-8243541: (tz) Upgrade time-zone data to tzdata2020a - JDK-8245167: Top package in method profiling shows null in JMC - JDK-8246703: [TESTBUG] Add test for JDK-8233197 Main issues of note: None, clean merge. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/make/data/tzdata/VERSION | 2 b/make/data/tzdata/africa | 52 - b/make/data/tzdata/asia | 212 +++- b/make/data/tzdata/backward | 1 b/make/data/tzdata/europe | 16 b/make/data/tzdata/leapseconds | 12 b/make/data/tzdata/northamerica | 48 - b/make/data/tzdata/zone.tab | 12 b/src/share/classes/sun/util/resources/TimeZoneNames.java | 14 b/src/share/classes/sun/util/resources/de/TimeZoneNames_de.java | 14 b/src/share/classes/sun/util/resources/es/TimeZoneNames_es.java | 14 b/src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java | 14 b/src/share/classes/sun/util/resources/it/TimeZoneNames_it.java | 14 b/src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java | 14 b/src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java | 14 b/src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java | 14 b/src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java | 14 b/src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java | 14 b/src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java | 14 b/test/java/time/test/java/time/format/ZoneName.java | 1 b/test/jdk/jfr/event/runtime/TestClassLoadEvent.java | 4 b/test/sun/util/calendar/zi/tzdata/VERSION | 2 b/test/sun/util/calendar/zi/tzdata/africa | 190 +++- b/test/sun/util/calendar/zi/tzdata/antarctica | 14 b/test/sun/util/calendar/zi/tzdata/asia | 455 ++++++---- b/test/sun/util/calendar/zi/tzdata/australasia | 154 ++- b/test/sun/util/calendar/zi/tzdata/backward | 1 b/test/sun/util/calendar/zi/tzdata/europe | 314 ++++-- b/test/sun/util/calendar/zi/tzdata/factory | 2 b/test/sun/util/calendar/zi/tzdata/leapseconds | 47 - b/test/sun/util/calendar/zi/tzdata/northamerica | 339 ++++--- b/test/sun/util/calendar/zi/tzdata/pacificnew | 2 b/test/sun/util/calendar/zi/tzdata/southamerica | 79 - b/test/sun/util/calendar/zi/tzdata/systemv | 2 b/test/sun/util/calendar/zi/tzdata/zone.tab | 15 36 files changed, 1421 insertions(+), 710 deletions(-) diffstat for hotspot b/.hgtags | 1 b/src/share/vm/classfile/classLoader.cpp | 58 +++ b/src/share/vm/classfile/classLoader.hpp | 5 b/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp | 127 ++++--- b/src/share/vm/jfr/jfr.cpp | 19 - b/src/share/vm/jfr/jfr.hpp | 5 b/src/share/vm/jfr/jni/jfrJavaSupport.cpp | 4 b/src/share/vm/jfr/jni/jfrJavaSupport.hpp | 1 b/src/share/vm/jfr/jni/jfrJniMethod.cpp | 4 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.cpp | 163 ++-------- b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.hpp | 2 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp | 19 + b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp | 16 b/src/share/vm/jfr/recorder/jfrRecorder.cpp | 28 + b/src/share/vm/jfr/recorder/jfrRecorder.hpp | 5 b/src/share/vm/jfr/recorder/service/jfrOptionSet.cpp | 26 - b/src/share/vm/jfr/recorder/service/jfrOptionSet.hpp | 4 b/src/share/vm/runtime/thread.cpp | 21 + b/test/runtime/8233197/T.java | 11 b/test/runtime/8233197/Test8233197.sh | 153 +++++++++ b/test/runtime/8233197/libJvmtiAgent.c | 124 +++++++ 21 files changed, 581 insertions(+), 215 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Jun 17 07:54:18 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Jun 2020 09:54:18 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b07 Upstream Sync In-Reply-To: References: Message-ID: On 6/17/20 1:12 AM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b05/jdk/merge.changeset This must be: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/jdk/merge.changeset Looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b07/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From aph at redhat.com Thu Jun 18 07:46:46 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Jun 2020 08:46:46 +0100 Subject: [aarch64-port-dev ] Access to AArch64 build & test machines Message-ID: Amazon now have high-performance AArch64 machines in the cloud, known as m6g instances. They are keen to encourage OpenJDK developers to apply for access to these machines. The information page is at https://aws.amazon.com/blogs/opensource/aws-promotional-credits-open-source-projects/ Please let us know how you get on. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Jun 18 12:56:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 18 Jun 2020 14:56:43 +0200 Subject: [aarch64-port-dev ] RFR: 2020-06-18, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200618/webrev.01/ This is another integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge. It fixes a few critical issues discovered during 8u stabilization. Changes: Shenandoah: missing SystemDictionary roots in ShenandoahHeapIterationRootScanner Shenandoah: add JFR roots to root processor after JFR integration [backport] 8247310: Shenandoah: pacer should not affect interrupt status [backport] 8247474: Shenandoah: Windows build warning after JDK-8247310 [backport] 8247358: Shenandoah: reconsider free budget slice for marking [backport] 8247560: Shenandoah: heap iteration holds root locks all the time Added tag aarch64-shenandoah-jdk8u262-b06-shenandoah-merge-2020-06-18 for changeset e49e42485e22 Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 with a few nightlies -- Thanks, -Aleksey From gnu.andrew at redhat.com Thu Jun 18 17:35:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 18 Jun 2020 18:35:19 +0100 Subject: [aarch64-port-dev ] RFR: 2020-06-18, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: References: Message-ID: <839052e1-322b-2843-95f7-1496328c01b4@redhat.com> On 18/06/2020 13:56, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200618/webrev.01/ > > This is another integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was > generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge. > > It fixes a few critical issues discovered during 8u stabilization. > > Changes: > Shenandoah: missing SystemDictionary roots in ShenandoahHeapIterationRootScanner > Shenandoah: add JFR roots to root processor after JFR integration > [backport] 8247310: Shenandoah: pacer should not affect interrupt status > [backport] 8247474: Shenandoah: Windows build warning after JDK-8247310 > [backport] 8247358: Shenandoah: reconsider free budget slice for marking > [backport] 8247560: Shenandoah: heap iteration holds root locks all the time > Added tag aarch64-shenandoah-jdk8u262-b06-shenandoah-merge-2020-06-18 for changeset e49e42485e22 > > Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 with a few nightlies > Looks fine to me. If you push this, I'll merge with b07 and re-tag based on that (sorry for not getting around to pushing that earlier) Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Thu Jun 18 18:09:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 18 Jun 2020 20:09:05 +0200 Subject: [aarch64-port-dev ] RFR: 2020-06-18, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: <839052e1-322b-2843-95f7-1496328c01b4@redhat.com> References: <839052e1-322b-2843-95f7-1496328c01b4@redhat.com> Message-ID: <0156853d-3c63-0363-9d20-946c0f60f6e7@redhat.com> On 6/18/20 7:35 PM, Andrew Hughes wrote: > If you push this, I'll merge with b07 and re-tag based on that (sorry > for not getting around to pushing that earlier) Thanks, rebased/retagged to newly pushed b07: https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200618/webrev.02/ -- -Aleksey From gnu.andrew at redhat.com Thu Jun 18 18:11:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 18 Jun 2020 19:11:39 +0100 Subject: [aarch64-port-dev ] RFR: 2020-06-18, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: <0156853d-3c63-0363-9d20-946c0f60f6e7@redhat.com> References: <839052e1-322b-2843-95f7-1496328c01b4@redhat.com> <0156853d-3c63-0363-9d20-946c0f60f6e7@redhat.com> Message-ID: On 18/06/2020 19:09, Aleksey Shipilev wrote: > On 6/18/20 7:35 PM, Andrew Hughes wrote: >> If you push this, I'll merge with b07 and re-tag based on that (sorry >> for not getting around to pushing that earlier) > > Thanks, rebased/retagged to newly pushed b07: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200618/webrev.02/ > Thanks. Push as soon as you're ready. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Jun 18 18:02:35 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 18 Jun 2020 18:02:35 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 3 new changesets Message-ID: <202006181802.05II2Z8l000811@aojmv0008.oracle.com> Changeset: 0cccb32a5047 Author: andrew Date: 2020-06-15 20:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/0cccb32a5047 Added tag jdk8u262-b07 for changeset ebb0a284b7e7 ! .hgtags Changeset: 89e8c5bbcb74 Author: andrew Date: 2020-06-16 02:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/89e8c5bbcb74 Merge jdk8u262-b07 ! .hgtags Changeset: a0218138dbe9 Author: andrew Date: 2020-06-16 02:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/a0218138dbe9 Added tag aarch64-shenandoah-jdk8u262-b07 for changeset 89e8c5bbcb74 ! .hgtags From gnu.andrew at redhat.com Thu Jun 18 18:02:54 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 18 Jun 2020 18:02:54 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 3 new changesets Message-ID: <202006181802.05II2scb001074@aojmv0008.oracle.com> Changeset: ac5fce891621 Author: andrew Date: 2020-06-15 20:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/ac5fce891621 Added tag jdk8u262-b07 for changeset 774e6c9b9296 ! .hgtags Changeset: 55ba08a960ee Author: andrew Date: 2020-06-16 02:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/55ba08a960ee Merge jdk8u262-b07 ! .hgtags Changeset: 1ffa984bb69a Author: andrew Date: 2020-06-16 02:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/1ffa984bb69a Added tag aarch64-shenandoah-jdk8u262-b07 for changeset 55ba08a960ee ! .hgtags From gnu.andrew at redhat.com Thu Jun 18 18:03:03 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 18 Jun 2020 18:03:03 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 3 new changesets Message-ID: <202006181803.05II33mH001220@aojmv0008.oracle.com> Changeset: 18103a6d9d49 Author: andrew Date: 2020-06-15 20:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/18103a6d9d49 Added tag jdk8u262-b07 for changeset e085d9bd4f65 ! .hgtags Changeset: 6a3e6008cd64 Author: andrew Date: 2020-06-16 02:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/6a3e6008cd64 Merge jdk8u262-b07 ! .hgtags Changeset: 3a2f377da5c1 Author: andrew Date: 2020-06-16 02:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/3a2f377da5c1 Added tag aarch64-shenandoah-jdk8u262-b07 for changeset 6a3e6008cd64 ! .hgtags From gnu.andrew at redhat.com Thu Jun 18 18:03:14 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 18 Jun 2020 18:03:14 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 5 new changesets Message-ID: <202006181803.05II3FVB001349@aojmv0008.oracle.com> Changeset: 219276e7623e Author: andrew Date: 2020-06-10 21:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/219276e7623e 8243541: (tz) Upgrade time-zone data to tzdata2020a Reviewed-by: martin ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/backward ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/java/time/test/java/time/format/ZoneName.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/factory ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/pacificnew ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/systemv ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: 745caf348aee Author: apetushkov Date: 2020-06-15 14:08 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/745caf348aee 8245167: Top package in method profiling shows null in JMC Reviewed-by: neugens Contributed-by: asemenov at azul.com ! test/jdk/jfr/event/runtime/TestClassLoadEvent.java Changeset: d70c3e992833 Author: andrew Date: 2020-06-15 20:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d70c3e992833 Added tag jdk8u262-b07 for changeset 745caf348aee ! .hgtags Changeset: 1e6d8a09233f Author: andrew Date: 2020-06-16 02:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1e6d8a09233f Merge jdk8u262-b07 ! .hgtags ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/asia ! make/data/tzdata/backward ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: b27f15c5e48a Author: andrew Date: 2020-06-16 02:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/b27f15c5e48a Added tag aarch64-shenandoah-jdk8u262-b07 for changeset 1e6d8a09233f ! .hgtags From shade at redhat.com Thu Jun 18 18:20:43 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 18 Jun 2020 18:20:43 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset 1ffa984bb69a Message-ID: <202006181820.05IIKhtT012082@aojmv0008.oracle.com> Changeset: c3237ab976f1 Author: shade Date: 2020-06-18 20:06 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/c3237ab976f1 Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset 1ffa984bb69a ! .hgtags From shade at redhat.com Thu Jun 18 18:20:47 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 18 Jun 2020 18:20:47 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset 8353a7cdc56c Message-ID: <202006181820.05IIKlHN012385@aojmv0008.oracle.com> Changeset: 762a9e298656 Author: shade Date: 2020-06-18 20:06 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/762a9e298656 Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset 8353a7cdc56c ! .hgtags From shade at redhat.com Thu Jun 18 18:20:44 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 18 Jun 2020 18:20:44 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset b27f15c5e48a Message-ID: <202006181820.05IIKima012174@aojmv0008.oracle.com> Changeset: 0d61467843b8 Author: shade Date: 2020-06-18 20:06 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/0d61467843b8 Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset b27f15c5e48a ! .hgtags From shade at redhat.com Thu Jun 18 18:20:50 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 18 Jun 2020 18:20:50 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8 new changesets Message-ID: <202006181820.05IIKoOK012392@aojmv0008.oracle.com> Changeset: 4526d0272113 Author: zgu Date: 2020-06-10 10:43 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4526d0272113 Shenandoah: missing SystemDictionary roots in ShenandoahHeapIterationRootScanner Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: ca85aabcaa4c Author: zgu Date: 2020-06-10 13:54 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ca85aabcaa4c Shenandoah: add JFR roots to root processor after JFR integration Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: ea4a41be4b74 Author: shade Date: 2020-06-10 16:05 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ea4a41be4b74 [backport] 8247310: Shenandoah: pacer should not affect interrupt status Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp Changeset: fd461a41b1f5 Author: shade Date: 2020-06-14 18:16 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fd461a41b1f5 [backport] 8247474: Shenandoah: Windows build warning after JDK-8247310 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp Changeset: 26032f3f4e86 Author: shade Date: 2020-06-11 18:16 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/26032f3f4e86 [backport] 8247358: Shenandoah: reconsider free budget slice for marking Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: b47e8d24e17a Author: shade Date: 2020-06-15 14:11 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b47e8d24e17a [backport] 8247560: Shenandoah: heap iteration holds root locks all the time Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 09960584744b Author: shade Date: 2020-06-18 20:06 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/09960584744b Merge Changeset: 9aa29814702c Author: shade Date: 2020-06-18 20:06 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9aa29814702c Added tag aarch64-shenandoah-jdk8u262-b07-shenandoah-merge-2020-06-18 for changeset 09960584744b ! .hgtags From boris.ulasevich at bell-sw.com Fri Jun 19 16:49:43 2020 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 19 Jun 2020 19:49:43 +0300 Subject: [aarch64-port-dev ] AARCH64 optimization: using TBZ instruction for bit check In-Reply-To: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> References: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> Message-ID: <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> Hi Andrew, I added the expression canonicalization in the BoolNode::Ideal method: http://cr.openjdk.java.net/~bulasevich/8247408/webrev.02b The change reduces a number of generated machine instructions on all ARM/x86/PPC architectures. Benchmark shows positive results on ARM64 and ARM32 with the given change. On x86 benchmark performance improves from +1% to +13% depending on the CPU generation, except of machines affected by Intel Erratum (JDK-8234160) issue. Maximum decrease observed is -%11. It does not look like a problem with the proposed benchmark though, but rather like an issue with Erratum mitigation. On PowerPC result of the micro-benchmark is also positive. I changed the micro-benchmark to make it a little bulkier so that we don't hit the limitations of architectures with a less elaborate branch prediction mechanism. The original application performance does not change on PowerPC. thanks, Boris Cascade Lake? 817.639 ? 15.806? -> 810.058 ? 3.128?? ns/op Whiskey Lake? 751.560 ? 29.690? -> 751.390 ? 24.406? ns/op Whiskey Lake* 803.742 ? 14.280? -> 746.670 ?? 5.626? ns/op Ivy Bridge?? 1021.523 ? 166.719 -> 903.092 ? 81.799? ns/op Skylake?????? 690.554 ? 4.839?? -> 769.115 ? 18.775? ns/op --- this is the only case where we see a regression Skylake*????? 734.354 ? 8.136?? -> 712.512 ? 10.301? ns/op ARM32?????? 11760.804 ? 335.050 -> 7133.137 ? 17.058 ns/op ARM64???????? 896.789 ? 3.524?? -> 758.096 ? 3.367?? ns/op PowerPC8???? 5313.218 ? 248.753 -> 1919.234 ? 605.326 ns/op PowerPC9???? 6174.107 ? 26.885? -> 1435.108 ? 48.447 ns/op * = -XX:-IntelJccErratumMitigation On 15.06.2020 12:28, Andrew Haley wrote: > On 12/06/2020 19:10, Boris Ulasevich wrote: >> Please review the new AARCH64 instruction selection rules. >> The change applies TBZ instruction for bit checks: "if ((var&16) == 16)". >> This makes 17% performance improvement on the benchmark and 5% on a real >> application. > Please forgive me if I am misunderstanding, but... > > This is strange Java for anyone to write. The expression "((var&16) == 16)" > is, I think, equivalent to "((var&16) != 0)". Do you believe that it > is wise to add new patterns to do this to (potentially) every HotSpot > back end rather than canonicalize the expression during the > machine-independent part of C2? This would have the same improvement > on all targets. > From aph at redhat.com Fri Jun 19 17:07:37 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 19 Jun 2020 18:07:37 +0100 Subject: [aarch64-port-dev ] RFR: C2: Canonicalize (x & 16 == 16) [Was: AARCH64 optimization: using TBZ instruction for bit check] In-Reply-To: <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> References: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> Message-ID: <14d3f034-b637-f74a-7567-d4e589260887@redhat.com> Hi, On 19/06/2020 17:49, Boris Ulasevich wrote: > I added the expression canonicalization in the BoolNode::Ideal method: > http://cr.openjdk.java.net/~bulasevich/8247408/webrev.02b > > The change reduces a number of generated machine instructions on all > ARM/x86/PPC architectures. Benchmark shows positive results on ARM64 and > ARM32 with the given change. > > On x86 benchmark performance improves from +1% to +13% depending on the > CPU generation, except of machines affected by Intel Erratum (JDK-8234160) > issue. Maximum decrease observed is -%11. It does not look like a problem > with the proposed benchmark though, but rather like an issue with > Erratum mitigation. > > On PowerPC result of the micro-benchmark is also positive. I changed the > micro-benchmark to make it a little bulkier so that we don't hit the > limitations of architectures with a less elaborate branch prediction > mechanism. The original application performance does not change on PowerPC. Fantastic work, thanks! You've done a remarkably thorough job. It's slightly unfortunate that one of the targets regresses. If there had been no regressions, I'd approve this straight away. Forwarding to hotspot-compiler-dev for more comments. VladimirK, what do you think? I guess we could turn this off on the machines affected by JDK-8234160. Should we? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Fri Jun 19 18:36:31 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Jun 2020 11:36:31 -0700 Subject: [aarch64-port-dev ] RFR: C2: Canonicalize (x & 16 == 16) [Was: AARCH64 optimization: using TBZ instruction for bit check] In-Reply-To: <14d3f034-b637-f74a-7567-d4e589260887@redhat.com> References: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> <14d3f034-b637-f74a-7567-d4e589260887@redhat.com> Message-ID: Nice optimization. I don't think we should turn it off on any machine. In real application you will not see such tight loops only with such branch. On other hand reducing code size should help in all cases. Would be nice to know if any Java benchmark is affected. I will try to run our set of benchmarks with these changes. Regards, Vladimir K On 6/19/20 10:07 AM, Andrew Haley wrote: > Hi, > > On 19/06/2020 17:49, Boris Ulasevich wrote: >> I added the expression canonicalization in the BoolNode::Ideal method: >> http://cr.openjdk.java.net/~bulasevich/8247408/webrev.02b >> >> The change reduces a number of generated machine instructions on all >> ARM/x86/PPC architectures. Benchmark shows positive results on ARM64 and >> ARM32 with the given change. >> >> On x86 benchmark performance improves from +1% to +13% depending on the >> CPU generation, except of machines affected by Intel Erratum (JDK-8234160) >> issue. Maximum decrease observed is -%11. It does not look like a problem >> with the proposed benchmark though, but rather like an issue with >> Erratum mitigation. >> >> On PowerPC result of the micro-benchmark is also positive. I changed the >> micro-benchmark to make it a little bulkier so that we don't hit the >> limitations of architectures with a less elaborate branch prediction >> mechanism. The original application performance does not change on PowerPC. > > Fantastic work, thanks! You've done a remarkably thorough job. It's > slightly unfortunate that one of the targets regresses. If there had > been no regressions, I'd approve this straight away. > > Forwarding to hotspot-compiler-dev for more comments. > > VladimirK, what do you think? I guess we could turn this off on the > machines affected by JDK-8234160. Should we? > From ci_notify at linaro.org Sat Jun 20 05:49:27 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 20 Jun 2020 05:49:27 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <804214239.4564.1592632168386.JavaMail.javamailuser@localhost> 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/jdk11u/openjdk-jtreg-nightly-tests/summary/2020/170/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 1: aarch64/2019/dec/17 pass: 5,775; fail: 1 Build 2: aarch64/2019/dec/21 pass: 5,775; fail: 1 Build 3: aarch64/2020/jan/16 pass: 5,775; fail: 1 Build 4: aarch64/2020/jan/30 pass: 5,791; fail: 1 Build 5: aarch64/2020/feb/06 pass: 5,791; fail: 1 Build 6: aarch64/2020/feb/13 pass: 5,792; fail: 1 Build 7: aarch64/2020/apr/30 pass: 5,813; fail: 1 Build 8: aarch64/2020/may/07 pass: 5,813; fail: 2 Build 9: aarch64/2020/may/15 pass: 5,814; fail: 1 Build 10: aarch64/2020/may/30 pass: 5,818; fail: 1 Build 11: aarch64/2020/jun/02 pass: 5,818; fail: 1 Build 12: aarch64/2020/jun/04 pass: 5,818; fail: 1 Build 13: aarch64/2020/jun/07 pass: 5,818; fail: 1 Build 14: aarch64/2020/jun/18 pass: 5,818; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 1: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 Build 2: aarch64/2019/dec/21 pass: 8,499; fail: 496; error: 10 Build 3: aarch64/2020/jan/16 pass: 8,513; fail: 474; error: 17 Build 4: aarch64/2020/jan/30 pass: 8,513; fail: 501; error: 13 Build 5: aarch64/2020/feb/06 pass: 8,496; fail: 517; error: 14 Build 6: aarch64/2020/feb/13 pass: 8,509; fail: 507; error: 14 Build 7: aarch64/2020/apr/30 pass: 8,534; fail: 519; error: 15 Build 8: aarch64/2020/may/07 pass: 8,540; fail: 515; error: 12 Build 9: aarch64/2020/may/15 pass: 8,558; fail: 498; error: 11 Build 10: aarch64/2020/may/30 pass: 8,544; fail: 507; error: 16 Build 11: aarch64/2020/jun/02 pass: 8,535; fail: 515; error: 17 Build 12: aarch64/2020/jun/04 pass: 8,560; fail: 496; error: 13 Build 13: aarch64/2020/jun/07 pass: 8,534; fail: 523; error: 12 Build 14: aarch64/2020/jun/18 pass: 8,544; fail: 511; error: 15 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/14 pass: 3,910 Build 1: aarch64/2019/dec/17 pass: 3,910 Build 2: aarch64/2019/dec/21 pass: 3,910 Build 3: aarch64/2020/jan/16 pass: 3,910 Build 4: aarch64/2020/jan/30 pass: 3,913 Build 5: aarch64/2020/feb/06 pass: 3,913 Build 6: aarch64/2020/feb/13 pass: 3,913 Build 7: aarch64/2020/apr/30 pass: 3,913 Build 8: aarch64/2020/may/07 pass: 3,913 Build 9: aarch64/2020/may/15 pass: 3,913 Build 10: aarch64/2020/may/30 pass: 3,913 Build 11: aarch64/2020/jun/02 pass: 3,913 Build 12: aarch64/2020/jun/04 pass: 3,913 Build 13: aarch64/2020/jun/07 pass: 3,913 Build 14: aarch64/2020/jun/18 pass: 3,913 Previous results can be found here: http://openjdk.linaro.org/jdk11u/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.29x Relative performance: Server critical-jOPS (nc): 7.98x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/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/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ 2019-12-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/355/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/037/results/ 2020-02-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/044/results/ 2020-05-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/121/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/128/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/136/results/ 2020-06-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/151/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/154/results/ 2020-06-07 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/156/results/ 2020-06-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/159/results/ 2020-06-20 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/170/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From ci_notify at linaro.org Sat Jun 20 05:53:56 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 20 Jun 2020 05:53:56 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <1516242933.4566.1592632437160.JavaMail.javamailuser@localhost> 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/jdk13/openjdk-jtreg-nightly-tests/summary/2020/170/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/01 pass: 5,646; fail: 1 Build 1: aarch64/2019/aug/03 pass: 5,646; fail: 1 Build 2: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 3: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 4: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 5: aarch64/2019/nov/12 pass: 5,652 Build 6: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 7: aarch64/2019/nov/16 pass: 5,652 Build 8: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 9: aarch64/2019/dec/14 pass: 5,652 Build 10: aarch64/2020/jan/16 pass: 5,652 Build 11: aarch64/2020/may/28 pass: 5,669 Build 12: aarch64/2020/jun/02 pass: 5,677 Build 13: aarch64/2020/jun/09 pass: 5,691 Build 14: aarch64/2020/jun/18 pass: 5,696 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/01 pass: 8,620; fail: 527; error: 24 Build 1: aarch64/2019/aug/03 pass: 8,596; fail: 552; error: 23 Build 2: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 3: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 4: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 5: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 6: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 7: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 8: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 9: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 10: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 11: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 Build 12: aarch64/2020/jun/02 pass: 8,686; fail: 509; error: 17 Build 13: aarch64/2020/jun/09 pass: 8,698; fail: 505; error: 16 Build 14: aarch64/2020/jun/18 pass: 8,712; fail: 495; error: 15 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/01 pass: 3,964 Build 1: aarch64/2019/aug/03 pass: 3,964 Build 2: aarch64/2019/aug/06 pass: 3,964 Build 3: aarch64/2019/aug/08 pass: 3,964 Build 4: aarch64/2019/aug/10 pass: 3,964 Build 5: aarch64/2019/nov/12 pass: 3,964 Build 6: aarch64/2019/nov/14 pass: 3,964 Build 7: aarch64/2019/nov/16 pass: 3,964 Build 8: aarch64/2019/dec/03 pass: 3,964 Build 9: aarch64/2019/dec/14 pass: 3,964 Build 10: aarch64/2020/jan/16 pass: 3,964 Build 11: aarch64/2020/may/28 pass: 3,964 Build 12: aarch64/2020/jun/02 pass: 3,964 Build 13: aarch64/2020/jun/09 pass: 3,965 Build 14: aarch64/2020/jun/18 pass: 3,965 Previous results can be found here: http://openjdk.linaro.org/jdk13/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.54x Relative performance: Server critical-jOPS (nc): 9.14x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/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/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-07-31 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/211/results/ 2019-08-02 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/213/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/154/results/ 2020-06-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/161/results/ 2020-06-20 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/170/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From ci_notify at linaro.org Sun Jun 21 14:23:09 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 21 Jun 2020 14:23:09 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <879550779.4647.1592749390302.JavaMail.javamailuser@localhost> 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/jdk13/openjdk-jtreg-nightly-tests/summary/2020/172/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/03 pass: 5,646; fail: 1 Build 1: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 2: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 3: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 4: aarch64/2019/nov/12 pass: 5,652 Build 5: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 6: aarch64/2019/nov/16 pass: 5,652 Build 7: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 8: aarch64/2019/dec/14 pass: 5,652 Build 9: aarch64/2020/jan/16 pass: 5,652 Build 10: aarch64/2020/may/28 pass: 5,669 Build 11: aarch64/2020/jun/02 pass: 5,677 Build 12: aarch64/2020/jun/09 pass: 5,691 Build 13: aarch64/2020/jun/18 pass: 5,696 Build 14: aarch64/2020/jun/20 pass: 5,695; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/03 pass: 8,596; fail: 552; error: 23 Build 1: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 2: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 3: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 4: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 5: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 6: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 7: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 8: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 9: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 10: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 Build 11: aarch64/2020/jun/02 pass: 8,686; fail: 509; error: 17 Build 12: aarch64/2020/jun/09 pass: 8,698; fail: 505; error: 16 Build 13: aarch64/2020/jun/18 pass: 8,712; fail: 495; error: 15 Build 14: aarch64/2020/jun/20 pass: 8,701; fail: 506; error: 16 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/03 pass: 3,964 Build 1: aarch64/2019/aug/06 pass: 3,964 Build 2: aarch64/2019/aug/08 pass: 3,964 Build 3: aarch64/2019/aug/10 pass: 3,964 Build 4: aarch64/2019/nov/12 pass: 3,964 Build 5: aarch64/2019/nov/14 pass: 3,964 Build 6: aarch64/2019/nov/16 pass: 3,964 Build 7: aarch64/2019/dec/03 pass: 3,964 Build 8: aarch64/2019/dec/14 pass: 3,964 Build 9: aarch64/2020/jan/16 pass: 3,964 Build 10: aarch64/2020/may/28 pass: 3,964 Build 11: aarch64/2020/jun/02 pass: 3,964 Build 12: aarch64/2020/jun/09 pass: 3,965 Build 13: aarch64/2020/jun/18 pass: 3,965 Build 14: aarch64/2020/jun/20 pass: 3,965 Previous results can be found here: http://openjdk.linaro.org/jdk13/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.54x Relative performance: Server critical-jOPS (nc): 8.61x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/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/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-02 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/213/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/154/results/ 2020-06-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/161/results/ 2020-06-20 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/170/results/ 2020-06-21 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/172/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From ci_notify at linaro.org Sun Jun 21 14:26:48 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 21 Jun 2020 14:26:48 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <1110113761.4649.1592749609049.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2020/172/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 1: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 Build 2: aarch64/2019/dec/21 pass: 848; fail: 10; error: 2 Build 3: aarch64/2020/jan/09 pass: 848; fail: 10; error: 1 Build 4: aarch64/2020/jan/11 pass: 848; fail: 10; error: 1 Build 5: aarch64/2020/jan/20 pass: 848; fail: 10; error: 1 Build 6: aarch64/2020/jan/25 pass: 848; fail: 10; error: 1 Build 7: aarch64/2020/may/06 pass: 885; fail: 12; error: 1 Build 8: aarch64/2020/may/10 pass: 885; fail: 12; error: 1 Build 9: aarch64/2020/may/12 pass: 885; fail: 12; error: 1 Build 10: aarch64/2020/may/19 pass: 886; fail: 12; error: 1 Build 11: aarch64/2020/may/30 pass: 890; fail: 11; error: 1 Build 12: aarch64/2020/jun/07 pass: 891; fail: 11; error: 1 Build 13: aarch64/2020/jun/16 pass: 890; fail: 11; error: 2 Build 14: aarch64/2020/jun/20 pass: 889; fail: 12; error: 3 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 Build 1: aarch64/2019/dec/21 pass: 5,970; fail: 262; error: 21 Build 2: aarch64/2020/jan/09 pass: 5,963; fail: 276; error: 20 Build 3: aarch64/2020/jan/11 pass: 5,959; fail: 279; error: 21 Build 4: aarch64/2020/jan/20 pass: 5,987; fail: 256; error: 24 Build 5: aarch64/2020/jan/25 pass: 5,962; fail: 285; error: 22 Build 6: aarch64/2020/feb/03 pass: 5,976; fail: 278; error: 19 Build 7: aarch64/2020/may/06 pass: 5,998; fail: 281; error: 21 Build 8: aarch64/2020/may/10 pass: 6,025; fail: 695; error: 21 Build 9: aarch64/2020/may/12 pass: 6,011; fail: 709; error: 21 Build 10: aarch64/2020/may/19 pass: 6,009; fail: 712; error: 22 Build 11: aarch64/2020/may/30 pass: 6,013; fail: 709; error: 23 Build 12: aarch64/2020/jun/07 pass: 6,016; fail: 711; error: 21 Build 13: aarch64/2020/jun/16 pass: 6,017; fail: 709; error: 22 Build 14: aarch64/2020/jun/20 pass: 6,012; fail: 716; error: 20 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 1: aarch64/2019/dec/19 pass: 3,117; fail: 2 Build 2: aarch64/2019/dec/21 pass: 3,117; fail: 2 Build 3: aarch64/2020/jan/09 pass: 3,117; fail: 2 Build 4: aarch64/2020/jan/11 pass: 3,117; fail: 2 Build 5: aarch64/2020/jan/20 pass: 3,117; fail: 2 Build 6: aarch64/2020/jan/25 pass: 3,117; fail: 2 Build 7: aarch64/2020/may/06 pass: 3,117; fail: 2 Build 8: aarch64/2020/may/10 pass: 3,117; fail: 2 Build 9: aarch64/2020/may/12 pass: 3,117; fail: 2 Build 10: aarch64/2020/may/19 pass: 3,117; fail: 2 Build 11: aarch64/2020/may/30 pass: 3,117; fail: 2 Build 12: aarch64/2020/jun/07 pass: 3,117; fail: 2 Build 13: aarch64/2020/jun/16 pass: 3,117; fail: 2 Build 14: aarch64/2020/jun/20 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 6.89x Relative performance: Server critical-jOPS (nc): 8.70x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 174.26 Server 174.26 / Server 2014-04-01 (71.00): 2.45x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ 2019-12-22 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/355/results/ 2020-01-09 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/009/results/ 2020-01-11 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/011/results/ 2020-01-20 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/020/results/ 2020-01-25 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/025/results/ 2020-05-06 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/127/results/ 2020-05-10 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/131/results/ 2020-05-14 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/133/results/ 2020-05-20 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/140/results/ 2020-06-01 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/151/results/ 2020-06-08 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/159/results/ 2020-06-16 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/168/results/ 2020-06-21 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/172/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From boris.ulasevich at bell-sw.com Mon Jun 22 14:45:13 2020 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Mon, 22 Jun 2020 17:45:13 +0300 Subject: [aarch64-port-dev ] RFR: C2: Canonicalize (x & 16 == 16) [Was: AARCH64 optimization: using TBZ instruction for bit check] In-Reply-To: References: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> <14d3f034-b637-f74a-7567-d4e589260887@redhat.com> Message-ID: Hi Vladimir, > Would be nice to know if any Java benchmark is affected. With the change we have got 5% performance boost on lucene tokenizer method on ARM64. Same time on x86 there is no visible improvement on lucene tokenizer. thanks, Boris import org.apache.lucene.analysis.standard.StandardTokenizerImpl; import java.nio.file.Files; import java.io.*; class Test { ? public static void main(String args[]) { ??? long count = 0; ??? try { ????? byte[] content = Files.readAllBytes(new File("aarch64.ad").toPath()); ????? for (int i=0; i < 1000; i++) { ??????? Reader reader = new InputStreamReader(new ByteArrayInputStream(content)); ??????? StandardTokenizerImpl sti = new StandardTokenizerImpl(reader); ??????? while (sti.getNextToken() != -1) { ????????? count ++; ??????? } ????? } ??? } catch (Exception ex) { System.out.println(ex); } ??? System.out.println(count); ? } } On 19.06.2020 21:36, Vladimir Kozlov wrote: > Nice optimization. > > I don't think we should turn it off on any machine. In real > application you will not see such tight loops only with such branch. > On other hand reducing code size should help in all cases. > > Would be nice to know if any Java benchmark is affected. > > I will try to run our set of benchmarks with these changes. > > Regards, > Vladimir K > > On 6/19/20 10:07 AM, Andrew Haley wrote: >> Hi, >> >> On 19/06/2020 17:49, Boris Ulasevich wrote: >>> I added the expression canonicalization in the BoolNode::Ideal method: >>> http://cr.openjdk.java.net/~bulasevich/8247408/webrev.02b >>> >>> The change reduces a number of generated machine instructions on all >>> ARM/x86/PPC architectures. Benchmark shows positive results on ARM64 >>> and >>> ARM32 with the given change. >>> >>> On x86 benchmark performance improves from +1% to +13% depending on the >>> CPU generation, except of machines affected by Intel Erratum >>> (JDK-8234160) >>> issue. Maximum decrease observed is -%11. It does not look like a >>> problem >>> with the proposed benchmark though, but rather like an issue with >>> Erratum mitigation. >>> >>> On PowerPC result of the micro-benchmark is also positive. I changed >>> the >>> micro-benchmark to make it a little bulkier so that we don't hit the >>> limitations of architectures with a less elaborate branch prediction >>> mechanism. The original application performance does not change on >>> PowerPC. >> >> Fantastic work, thanks! You've done a remarkably thorough job. It's >> slightly unfortunate that one of the targets regresses. If there had >> been no regressions, I'd approve this straight away. >> >> Forwarding to hotspot-compiler-dev for more comments. >> >> VladimirK, what do you think? I guess we could turn this off on the >> machines affected by JDK-8234160. Should we? >> From vladimir.kozlov at oracle.com Mon Jun 22 15:48:07 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 22 Jun 2020 08:48:07 -0700 Subject: [aarch64-port-dev ] RFR: C2: Canonicalize (x & 16 == 16) [Was: AARCH64 optimization: using TBZ instruction for bit check] In-Reply-To: References: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> <14d3f034-b637-f74a-7567-d4e589260887@redhat.com> Message-ID: <709f87e9-9c4f-b9ad-5246-90c9c92c5e6b@oracle.com> On 6/22/20 7:45 AM, Boris Ulasevich wrote: > Hi Vladimir, > > > Would be nice to know if any Java benchmark is affected. > > With the change we have got 5% performance boost on lucene tokenizer method on ARM64. Same time on x86 there is no > visible improvement on lucene tokenizer. Good. I ran our benchmarks (mostly jvm2008) on x86 and don't see any effects too. Thanks, Vladimir > > thanks, > Boris > > import org.apache.lucene.analysis.standard.StandardTokenizerImpl; > import java.nio.file.Files; > import java.io.*; > > class Test { > ? public static void main(String args[]) { > ??? long count = 0; > ??? try { > ????? byte[] content = Files.readAllBytes(new File("aarch64.ad").toPath()); > ????? for (int i=0; i < 1000; i++) { > ??????? Reader reader = new InputStreamReader(new ByteArrayInputStream(content)); > ??????? StandardTokenizerImpl sti = new StandardTokenizerImpl(reader); > ??????? while (sti.getNextToken() != -1) { > ????????? count ++; > ??????? } > ????? } > ??? } catch (Exception ex) { System.out.println(ex); } > ??? System.out.println(count); > ? } > } > > > On 19.06.2020 21:36, Vladimir Kozlov wrote: >> Nice optimization. >> >> I don't think we should turn it off on any machine. In real application you will not see such tight loops only with >> such branch. On other hand reducing code size should help in all cases. >> >> Would be nice to know if any Java benchmark is affected. >> >> I will try to run our set of benchmarks with these changes. >> >> Regards, >> Vladimir K >> >> On 6/19/20 10:07 AM, Andrew Haley wrote: >>> Hi, >>> >>> On 19/06/2020 17:49, Boris Ulasevich wrote: >>>> I added the expression canonicalization in the BoolNode::Ideal method: >>>> http://cr.openjdk.java.net/~bulasevich/8247408/webrev.02b >>>> >>>> The change reduces a number of generated machine instructions on all >>>> ARM/x86/PPC architectures. Benchmark shows positive results on ARM64 and >>>> ARM32 with the given change. >>>> >>>> On x86 benchmark performance improves from +1% to +13% depending on the >>>> CPU generation, except of machines affected by Intel Erratum (JDK-8234160) >>>> issue. Maximum decrease observed is -%11. It does not look like a problem >>>> with the proposed benchmark though, but rather like an issue with >>>> Erratum mitigation. >>>> >>>> On PowerPC result of the micro-benchmark is also positive. I changed the >>>> micro-benchmark to make it a little bulkier so that we don't hit the >>>> limitations of architectures with a less elaborate branch prediction >>>> mechanism. The original application performance does not change on PowerPC. >>> >>> Fantastic work, thanks! You've done a remarkably thorough job. It's >>> slightly unfortunate that one of the targets regresses. If there had >>> been no regressions, I'd approve this straight away. >>> >>> Forwarding to hotspot-compiler-dev for more comments. >>> >>> VladimirK, what do you think? I guess we could turn this off on the >>> machines affected by JDK-8234160. Should we? >>> > From felix.yang at huawei.com Tue Jun 23 00:42:54 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 23 Jun 2020 00:42:54 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg Message-ID: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8247979 Webrev: http://cr.openjdk.java.net/~fyang/8247979/webrev.00 For clearArray_reg_reg in aarch64.ad, we call function: MacroAssembler::zero words(Register ptr, Register cnt). This function modifies the flags register by doing a cmp instruction at entry. But this is not reflected on the side effect of clearArray_reg_reg. We didn't see this is triggering problems. But this may pose similar risk as bug: 8224828: aarch64: rflags is not correct after safepoint poll. Tier1-3 tested on aarch64-linux-gnu. OK? diff -r 2342d5af52b7 src/hotspot/cpu/aarch64/aarch64.ad --- a/src/hotspot/cpu/aarch64/aarch64.ad Mon Jun 22 08:09:23 2020 +0200 +++ b/src/hotspot/cpu/aarch64/aarch64.ad Mon Jun 22 15:58:05 2020 +0800 @@ -13845,7 +13845,7 @@ instruct clearArray_reg_reg(iRegL_R11 cnt, iRegP_R10 base, Universe dummy, rFlagsReg cr) %{ match(Set dummy (ClearArray cnt base)); - effect(USE_KILL cnt, USE_KILL base); + effect(USE_KILL cnt, USE_KILL base, KILL cr); ins_cost(4 * INSN_COST); format %{ "ClearArray $cnt, $base" %} BTW: clearArray_imm_reg does not have the issue since it calls a different function: MacroAssembler::zero_words(Register base, u_int64_t cnt) 13843 // clearing of an array 13844 13845 instruct clearArray_reg_reg(iRegL_R11 cnt, iRegP_R10 base, Universe dummy, rFlagsReg cr) 13846 %{ 13847 match(Set dummy (ClearArray cnt base)); 13848 effect(USE_KILL cnt, USE_KILL base); 13849 13850 ins_cost(4 * INSN_COST); 13851 format %{ "ClearArray $cnt, $base" %} 13852 13853 ins_encode %{ 13854 __ zero_words($base$$Register, $cnt$$Register); 13855 %} 13856 13857 ins_pipe(pipe_class_memory); 13858 %} 4771 void MacroAssembler::zero_words(Register ptr, Register cnt) 4772 { 4773 assert(is_power_of_2(zero_words_block_size), "adjust this"); 4774 assert(ptr == r10 && cnt == r11, "mismatch in register usage"); 4775 4776 BLOCK_COMMENT("zero_words {"); 4777 cmp(cnt, (u1)zero_words_block_size); <================= From adinn at redhat.com Tue Jun 23 09:37:13 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 23 Jun 2020 10:37:13 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg In-Reply-To: References: Message-ID: On 23/06/2020 01:42, Yangfei (Felix) wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8247979 > Webrev: http://cr.openjdk.java.net/~fyang/8247979/webrev.00 > > For clearArray_reg_reg in aarch64.ad, we call function: MacroAssembler::zero words(Register ptr, Register cnt). > This function modifies the flags register by doing a cmp instruction at entry. But this is not reflected on the side effect of clearArray_reg_reg. > We didn't see this is triggering problems. But this may pose similar risk as bug: 8224828: aarch64: rflags is not correct after safepoint poll. > Tier1-3 tested on aarch64-linux-gnu. OK? Nice catch, Felix. The patch looks good to me. regards, Andrew Dinn ----------- From felix.yang at huawei.com Wed Jun 24 00:18:37 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 24 Jun 2020 00:18:37 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg In-Reply-To: References: Message-ID: Hi Andrew, > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Tuesday, June 23, 2020 5:37 PM > To: Yangfei (Felix) ; hotspot-compiler- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: RFR(XS): 8247979: aarch64: missing side effect of killing flags for > clearArray_reg_reg > > On 23/06/2020 01:42, Yangfei (Felix) wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8247979 > > Webrev: http://cr.openjdk.java.net/~fyang/8247979/webrev.00 > > > > For clearArray_reg_reg in aarch64.ad, we call function: > MacroAssembler::zero words(Register ptr, Register cnt). > > This function modifies the flags register by doing a cmp instruction at > entry. But this is not reflected on the side effect of clearArray_reg_reg. > > We didn't see this is triggering problems. But this may pose similar risk as > bug: 8224828: aarch64: rflags is not correct after safepoint poll. > > Tier1-3 tested on aarch64-linux-gnu. OK? > Nice catch, Felix. The patch looks good to me. Thanks for the fast review. Pushed as: http://hg.openjdk.java.net/jdk/jdk/rev/9fce19fdda7e Felix From felix.yang at huawei.com Wed Jun 24 09:38:49 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 24 Jun 2020 09:38:49 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield Message-ID: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8248219 We were witnessing random JVM crash that triggers about 2 or 3 times each day in one of our production environment. Debugging show this is triggered after patching bytecode. Normal template interpreter sequence: TemplateTable::putfield_or_static -> TemplateTable::resolve_cache_and_index -> InterpreterRuntime::resolve_from_cache -> InterpreterRuntime::resolve_get_put cpCache entry is updated after that. Then we do bytecode patching in TemplateTable::putfield_or_static and dispatch to the next bytecode through InterpreterMacroAssembler::dispatch_next. 510 void InterpreterMacroAssembler::dispatch_next(TosState state, int step, bool generate_poll) { 511 // load next bytecode 512 ldrb(rscratch1, Address(pre(rbcp, step))); 513 dispatch_base(state, Interpreter::dispatch_table(state), generate_poll); 514 } After that we switch to the fast path: TemplateTable::fast_storefield. This will read the cpCache entry. But we may have invalid cpCache entry values as the memory barrier is missing. The bytecode load may be scheduled before the bytecode load and even before the setting of the cpCache entry. Reference: armv8 architecture reference manual K11.6.1 This restriction applies only when the data value returned by a read is used as a data value to calculate the address of a subsequent read or write. It does not apply if the data value returned by a read determines the condition flags values, and the values of the flags are used for condition code evaluation to determine the address of a subsequent read, either through conditional execution or the evaluation of a branch. This is called a control dependency. One fix adding explicit memory barriers looks like: diff -r abdc7ca79bdf src/hotspot/cpu/aarch64/templateTable_aarch64.cpp --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Tue Jun 23 13:41:55 2020 +0300 +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Wed Jun 24 15:01:21 2020 +0800 @@ -2975,6 +2975,9 @@ // access constant pool cache __ get_cache_and_index_at_bcp(r2, r1, 1); + // Must prevent reordering of the following cp cache loads with bytecode load + __ membar(MacroAssembler::LoadLoad); + // test for volatile with r3 __ ldrw(r3, Address(r2, in_bytes(base + ConstantPoolCacheEntry::flags_offset()))); @@ -3067,6 +3070,10 @@ // access constant pool cache __ get_cache_and_index_at_bcp(r2, r1, 1); + + // Must prevent reordering of the following cp cache loads with bytecode load + __ membar(MacroAssembler::LoadLoad); + __ ldr(r1, Address(r2, in_bytes(ConstantPoolCache::base_offset() + ConstantPoolCacheEntry::f2_offset()))); __ ldrw(r3, Address(r2, in_bytes(ConstantPoolCache::base_offset() + Another approach avoids the memory barrier by introducing artificial true dependency: --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Tue Jun 23 13:41:55 2020 +0300 +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Wed Jun 24 15:43:49 2020 +0800 @@ -2975,6 +2975,11 @@ // access constant pool cache __ get_cache_and_index_at_bcp(r2, r1, 1); + // use artificial data dependency from the bytecode load to the following + // cp cache loads to avoid a load-load barrier + __ eor(rscratch2, rscratch1, rscratch1); + __ orr(r2, r2, rscratch2); + // test for volatile with r3 __ ldrw(r3, Address(r2, in_bytes(base + ConstantPoolCacheEntry::flags_offset()))); @@ -3067,6 +3072,12 @@ // access constant pool cache __ get_cache_and_index_at_bcp(r2, r1, 1); + + // use artificial data dependency from the bytecode load to the following + // cp cache loads to avoid a load-load barrier + __ eor(rscratch2, rscratch1, rscratch1); + __ orr(r2, r2, rscratch2); + __ ldr(r1, Address(r2, in_bytes(ConstantPoolCache::base_offset() + ConstantPoolCacheEntry::f2_offset()))); __ ldrw(r3, Address(r2, in_bytes(ConstantPoolCache::base_offset() + Suggenstions? Thanks, Felix From aph at redhat.com Wed Jun 24 10:44:52 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 24 Jun 2020 11:44:52 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: References: Message-ID: On 24/06/2020 10:38, Yangfei (Felix) wrote: > Suggestions? Great catch! Thanks for that, I completely agree. Please benchmark the two and unless there is an advantage for the address dependency we'll go with LoadLoad. It looks like all of the ConstantPoolCacheEntry::set methods use Atomic::release_store, so everything should be fine there. Did you also look to see if we need similar memory barriers elsewhere? We're going to need backports for all extant OpenJDK versions. Please let us know if you can handle that too. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Wed Jun 24 20:44:27 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 24 Jun 2020 20:44:27 +0000 (UTC) Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: Message-ID: <7148d08d-9510-9ad4-6b65-f833f6bacd37@oracle.com> Hi Monica, All build system changes must be sent to build-dev for review by the build team, and you are doing quite a lot of build changes. (I'm cc:ing build-dev now.) I did a quick scan and found some changes that looked odd enough to draw my attention. I will need some time to fully understand what you are trying to accomplish here, before I can give a full review. /Magnus On 2020-06-24 18:40, Monica Beckwith wrote: > Hello OpenJDK community, > > As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. > > Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) > Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) > Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. > Umbrella Bug ID: https://bugs.openjdk.java.net/browse/JDK-8248238 > Webrevs: > `Webrev P1`: http://cr.openjdk.java.net/~burban/winarm64_p1_llp64/ & > `Webrev P2`: http://cr.openjdk.java.net/~burban/winarm64_p2_new-target/ > > The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 > The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: > * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, > * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 > * `os/windows` in `threadCritical_windows.cpp`, > * Windbg support > * `globalDefinitions_visCPP.hpp` in `share/utilities` > * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). > Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. > > I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. > > As a part of this project, we have also worked on two additional patches: > * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://bugs.openjdk.java.net/browse/JDK-8247941 > * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. > > We welcome any feedback and comments from the community and are looking forward to working together. > > Regards, > Monica > > [1] https://github.com/microsoft/openjdk-aarch64/blob/master/wkload-status-on-Win%2BArm64.md > [2] https://github.com/microsoft/openjdk-aarch64/blob/master/JTRegtests.md > [3] https://github.com/microsoft/openjdk-aarch64/blob/master/SPECJBB2015-test-matrices.md > [4] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#integer-registers From luhenry at microsoft.com Wed Jun 24 21:33:53 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Wed, 24 Jun 2020 21:33:53 +0000 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <7148d08d-9510-9ad4-6b65-f833f6bacd37@oracle.com> References: , <7148d08d-9510-9ad4-6b65-f833f6bacd37@oracle.com> Message-ID: Hi Magnus, Happy to answer any question you have on the build system changes. A lot of the changes were due to the build system not supporting cross-compilation well when targetting the microsoft toolchain (it just never really had to support it). We had to go through a few hoops to remove as many of our own quick hacks, initially there just to get things building - like hardcoding the target being windows-aarch64 for example. Thank you for your review, -- Ludovic ________________________________________ From: Magnus Ihse Bursie Sent: Wednesday, June 24, 2020 13:44 To: Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev Cc: openjdk-aarch64 Subject: Re: OpenJDK extension to AArch64 and Windows Hi Monica, All build system changes must be sent to build-dev for review by the build team, and you are doing quite a lot of build changes. (I'm cc:ing build-dev now.) I did a quick scan and found some changes that looked odd enough to draw my attention. I will need some time to fully understand what you are trying to accomplish here, before I can give a full review. /Magnus On 2020-06-24 18:40, Monica Beckwith wrote: > Hello OpenJDK community, > > As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. > > Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) > Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) > Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. > Umbrella Bug ID: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088&sdata=QXhd0zUDi2tqCLKiY%2F%2BKZzOzQNLirhq9WdxVAvogkqo%3D&reserved=0 > Webrevs: > `Webrev P1`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2F&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088&sdata=I4NuehXTkw1U6pChqT7Po0e4m8CvPTgucp0BtMN%2FFGk%3D&reserved=0 & > `Webrev P2`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p2_new-target%2F&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088&sdata=UKxXrBjXUOM7Yw7qQ02TOujYnNp0W439FclIqoVs7mk%3D&reserved=0 > > The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 > The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: > * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, > * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 > * `os/windows` in `threadCritical_windows.cpp`, > * Windbg support > * `globalDefinitions_visCPP.hpp` in `share/utilities` > * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). > Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. > > I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. > > As a part of this project, we have also worked on two additional patches: > * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247941&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=cH8q0LmaYoV%2BZfiunRHJYTyHz3kfm2RpnC5phc9Th8c%3D&reserved=0 > * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. > > We welcome any feedback and comments from the community and are looking forward to working together. > > Regards, > Monica > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2Fwkload-status-on-Win%252BArm64.md&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=eeZ80gPlXEgqSDrpeL3WR%2FtzVPUr6nSBG%2FN3wqX4Lcc%3D&reserved=0 > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FJTRegtests.md&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=jpSyNBfEvDpvw8AJvBqg8nGj4rb54xqW1YtJA07K2mI%3D&reserved=0 > [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FSPECJBB2015-test-matrices.md&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=QKYnn7jIwZGxeEdAjsMeUXY%2BvZBvZlLQSkP9s8vY8Cg%3D&reserved=0 > [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Farm64-windows-abi-conventions%3Fview%3Dvs-2019%23integer-registers&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=iy6RcczW2ipXYU%2B%2FD6mRRagLQxFjhZdCTqWcojeuqj0%3D&reserved=0 From david.holmes at oracle.com Wed Jun 24 22:34:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Jun 2020 08:34:19 +1000 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: Message-ID: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> Hi Monica, Are you proposing a new project to introduce this new port into the OpenJDK some time in the future? Thanks, David ----- On 25/06/2020 2:40 am, Monica Beckwith wrote: > Hello OpenJDK community, > > As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. > > Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) > Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) > Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. > Umbrella Bug ID: https://bugs.openjdk.java.net/browse/JDK-8248238 > Webrevs: > `Webrev P1`: http://cr.openjdk.java.net/~burban/winarm64_p1_llp64/ & > `Webrev P2`: http://cr.openjdk.java.net/~burban/winarm64_p2_new-target/ > > The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 > The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: > * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, > * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 > * `os/windows` in `threadCritical_windows.cpp`, > * Windbg support > * `globalDefinitions_visCPP.hpp` in `share/utilities` > * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). > Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. > > I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. > > As a part of this project, we have also worked on two additional patches: > * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://bugs.openjdk.java.net/browse/JDK-8247941 > * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. > > We welcome any feedback and comments from the community and are looking forward to working together. > > Regards, > Monica > > [1] https://github.com/microsoft/openjdk-aarch64/blob/master/wkload-status-on-Win%2BArm64.md > [2] https://github.com/microsoft/openjdk-aarch64/blob/master/JTRegtests.md > [3] https://github.com/microsoft/openjdk-aarch64/blob/master/SPECJBB2015-test-matrices.md > [4] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#integer-registers > From sandhya.viswanathan at intel.com Wed Jun 24 19:03:52 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Wed, 24 Jun 2020 19:03:52 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> Message-ID: Hi Andrew/Yang, We couldn?t propose Vector API to target in time for JDK 15 and hoping to do so early in JDK 16 timeframe. The implementation reviews on other components have made good progress. We have so far ok to PPT from (runtime, shared compiler changes, x86 backend). Java API implementation review is in progress. I wanted to check with you both if we have a go ahead from aarch64 backed point of view. Best Regards, Sandhya -----Original Message----- From: hotspot-compiler-dev On Behalf Of Yang Zhang Sent: Tuesday, May 26, 2020 7:59 PM To: Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes > But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? The new instructions can be classified as: 1. Instructions that can be matched with NEON instructions directly. MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is in review [1]. 2. Instructions that Jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. May I have a new patch for these? 3. Panama/Vector API specific instructions Such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. Regards Yang [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html -----Original Message----- From: Andrew Haley Sent: Tuesday, May 26, 2020 4:25 PM To: Yang Zhang ; Paul Sandoz Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 25/05/2020 09:26, Yang Zhang wrote: > In jdk master, what we need to do is that writing m4 file for existing > vector instructions and placed them to a new file aarch64_neon.ad. > If no question, I will do it right away. I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement. But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? It'd help if this was possible. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From javajiva at amazon.com Thu Jun 11 00:47:50 2020 From: javajiva at amazon.com (Jiva, Azeem) Date: Thu, 11 Jun 2020 00:47:50 +0000 Subject: [aarch64-port-dev ] [15] RFR(XS) 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: <612fcc45-0886-eb21-ef25-723d934a358b@oracle.com> References: <612fcc45-0886-eb21-ef25-723d934a358b@oracle.com> Message-ID: <4E8B20A3-F150-45E6-9CF5-95D4CD8DA905@amazon.com> Looks good to me. -- Azeem Jiva ?On 6/10/20, 5:42 PM, "hotspot-compiler-dev on behalf of Vladimir Kozlov" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. https://bugs.openjdk.java.net/browse/JDK-8247350 https://cr.openjdk.java.net/~kvn/8247350/webrev.00/ Code size for decodeHeapOop is different in scratch buffer with -XX:+VerifyOops flag on. The difference comes from MacroAssembler::mov_immediate64() which generates different code if distance to message string 'b' in mov(rscratch1, (address)b) is different. Use movptr() instead of mov() in verify_oop() method to generate consistent code for loading C string address. Added debug dump code in case of mismatching code generation. Tested with failing test case. Thanks, Vladimir From Monica.Beckwith at microsoft.com Wed Jun 24 16:40:24 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Wed, 24 Jun 2020 16:40:24 +0000 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows Message-ID: Hello OpenJDK community, As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. Umbrella Bug ID: https://bugs.openjdk.java.net/browse/JDK-8248238 Webrevs: `Webrev P1`: http://cr.openjdk.java.net/~burban/winarm64_p1_llp64/ & `Webrev P2`: http://cr.openjdk.java.net/~burban/winarm64_p2_new-target/ The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 * `os/windows` in `threadCritical_windows.cpp`, * Windbg support * `globalDefinitions_visCPP.hpp` in `share/utilities` * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. As a part of this project, we have also worked on two additional patches: * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://bugs.openjdk.java.net/browse/JDK-8247941 * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. We welcome any feedback and comments from the community and are looking forward to working together. Regards, Monica [1] https://github.com/microsoft/openjdk-aarch64/blob/master/wkload-status-on-Win%2BArm64.md [2] https://github.com/microsoft/openjdk-aarch64/blob/master/JTRegtests.md [3] https://github.com/microsoft/openjdk-aarch64/blob/master/SPECJBB2015-test-matrices.md [4] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#integer-registers From Alan.Bateman at oracle.com Thu Jun 25 07:39:57 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Jun 2020 08:39:57 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> References: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> Message-ID: On 24/06/2020 23:34, David Holmes wrote: > Hi Monica, > > Are you proposing a new project to introduce this new port into the > OpenJDK some time in the future? I think it will need a JEP at least. I could imagine doing some cleanup in advance, maybe also improvements to support cross building on Windows, to eliminate some of the noise from the patch. -Alan. From patric.hedlin at oracle.com Mon Jun 15 10:22:08 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Mon, 15 Jun 2020 12:22:08 +0200 Subject: [aarch64-port-dev ] RFR(S): 8247200: [aarch64] assert((unsigned)fpargs < 32) In-Reply-To: <61acad9c-98a1-46b2-8e24-d3cb84fa2628@redhat.com> References: <40b781a4-5a1f-bd83-0dab-00dc2890e06d@oracle.com> <61acad9c-98a1-46b2-8e24-d3cb84fa2628@redhat.com> Message-ID: Thanks for reviewing Andrew. /Patric On 2020-06-15 11:17, Andrew Haley wrote: > On 11/06/2020 17:56, Vladimir Kozlov wrote: >> On 6/11/20 1:24 AM, Patric Hedlin wrote: >>> Dear all, >>> >>> I would like to ask for help to review the following change/update: >>> >>> Issue:? https://bugs.openjdk.java.net/browse/JDK-8247200 >>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8247200/ >>> >>> >>> Removing assert and some associated dead code. > Looks good. > From aph at redhat.com Thu Jun 25 08:26:15 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jun 2020 09:26:15 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: Message-ID: On 24/06/2020 17:40, Monica Beckwith wrote: > Hello OpenJDK community, > > As the project lead here @Microsoft, I am pleased to share that we > have been working towards a Windows addition to the OpenJDK AArch64 > port. We are very thankful to all that have contributed to the > Linux+aarch64 and Windows+x86-64. Both these codebases came to our > rescue on numerous occasions. > > Support status: We have successfully ported C2 and can build the > server release (cross-compiled environment) > Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) > Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. > Umbrella Bug ID: https://bugs.openjdk.java.net/browse/JDK-8248238 > Webrevs: > `Webrev P1`: http://cr.openjdk.java.net/~burban/winarm64_p1_llp64/ & This looks basically OK, but the use of uint64_t doesn't read well in aarch64.ad. (For what it's worth, the type used internally in HotSpot for $$constant is actually intptr_t.) 3130 enc_class aarch64_enc_mov_imm(iRegL dst, immL src) %{ 3131 C2_MacroAssembler _masm(&cbuf); 3132 Register dst_reg = as_Register($dst$$reg); 3133 uint64_t con = (uint64_t)$src$$constant; Here, the type of the register is iRegL, so con could be a julong, not a uint64_t. In general the easiest way to fix aarch64.ad is probably long -> jlong unsigned long -> julong u_int64_t -> uint64_t But not always everywhere. Here, the arg is an address offset: -void Assembler::adrp(Register reg1, const Address &dest, unsigned long &byte_offset) { +void Assembler::adrp(Register reg1, const Address &dest, uint64_t &byte_offset) { ShouldNotReachHere(); } uintptr_t would do here. The coments in aarch64.ad like this one: - format %{ "mov $dst, $src\t# long" %} + format %{ "mov $dst, $src\t# int64_t" %} refer to a *Java type*. It shouldn't be changed. Rather than keep bouncing this back and forth until I'm statisfied, which would be boring for both of us, if you like I'll replace all of the bare "long" and "unsigned long" with the appropriate portable types. Do you want me to do that? Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Jun 25 08:28:32 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jun 2020 09:28:32 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> Message-ID: <7399bb11-ba06-aadd-eb9d-a5b970e63d0d@redhat.com> On 25/06/2020 08:39, Alan Bateman wrote: > On 24/06/2020 23:34, David Holmes wrote: >> >> Are you proposing a new project to introduce this new port into the >> OpenJDK some time in the future? > > I think it will need a JEP at least. I could imagine doing some cleanup > in advance, maybe also improvements to support cross building on > Windows, to eliminate some of the noise from the patch. If someone want to do the JEP bureaucracy that's fine by me, but in the meantime we'll try to get the AArch64 parts in shape so that the Windows import is simpler. In particular, we can get all of the register and integer type changes done. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From beurba at microsoft.com Thu Jun 25 11:46:19 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Thu, 25 Jun 2020 11:46:19 +0000 Subject: [aarch64-port-dev ] [EXTERNAL] Re: OpenJDK extension to AArch64 and Windows In-Reply-To: References: Message-ID: Thank you for your review Andrew. > Rather than keep bouncing this back and forth until I'm statisfied, > which would be boring for both of us, if you like I'll replace all of > the bare "long" and "unsigned long" with the appropriate > portable types. Do you want me to do that? This would be great! Once I have your updated patch, I can test it on win+aarch64. Thank you, -Bernhard -----Original Message----- From: Andrew Haley Sent: Thursday, 25 June 2020 10:26 To: Monica Beckwith ; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: [EXTERNAL] Re: OpenJDK extension to AArch64 and Windows On 24/06/2020 17:40, Monica Beckwith wrote: > Hello OpenJDK community, > > As the project lead here @Microsoft, I am pleased to share that we > have been working towards a Windows addition to the OpenJDK AArch64 > port. We are very thankful to all that have contributed to the > Linux+aarch64 and Windows+x86-64. Both these codebases came to our > rescue on numerous occasions. > > Support status: We have successfully ported C2 and can build the > server release (cross-compiled environment) > Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, > G1GC) Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. > Umbrella Bug ID: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7Cbeurba%40m > icrosoft.com%7Cfa1bff53ed8e4341186308d818e172f9%7C72f988bf86f141af91ab > 2d7cd011db47%7C1%7C0%7C637286703863799643&sdata=o%2FRsqlEGUcInzggB > MdjB0Ixi0cwKPUzaTyfJuUPEazU%3D&reserved=0 > Webrevs: > `Webrev P1`: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > jdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2F&data=02%7C01%7Cbeurb > a%40microsoft.com%7Cfa1bff53ed8e4341186308d818e172f9%7C72f988bf86f141a > f91ab2d7cd011db47%7C1%7C0%7C637286703863799643&sdata=ruv1ypJO74RlD > tMlfwK%2BBpqn5AtFi4sG90bDYmss5Go%3D&reserved=0 & This looks basically OK, but the use of uint64_t doesn't read well in aarch64.ad. (For what it's worth, the type used internally in HotSpot for $$constant is actually intptr_t.) 3130 enc_class aarch64_enc_mov_imm(iRegL dst, immL src) %{ 3131 C2_MacroAssembler _masm(&cbuf); 3132 Register dst_reg = as_Register($dst$$reg); 3133 uint64_t con = (uint64_t)$src$$constant; Here, the type of the register is iRegL, so con could be a julong, not a uint64_t. In general the easiest way to fix aarch64.ad is probably long -> jlong unsigned long -> julong u_int64_t -> uint64_t But not always everywhere. Here, the arg is an address offset: -void Assembler::adrp(Register reg1, const Address &dest, unsigned long &byte_offset) { +void Assembler::adrp(Register reg1, const Address &dest, uint64_t +&byte_offset) { ShouldNotReachHere(); } uintptr_t would do here. The coments in aarch64.ad like this one: - format %{ "mov $dst, $src\t# long" %} + format %{ "mov $dst, $src\t# int64_t" %} refer to a *Java type*. It shouldn't be changed. Rather than keep bouncing this back and forth until I'm statisfied, which would be boring for both of us, if you like I'll replace all of the bare "long" and "unsigned long" with the appropriate portable types. Do you want me to do that? Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cbeurba%40microsoft.com%7Cfa1bff53ed8e4341186308d818e172f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286703863799643&sdata=EshTj31BKzA%2FYw8LvHQ2cuvW9gitwQfBhFXoPMuuCyk%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Monica.Beckwith at microsoft.com Thu Jun 25 12:07:56 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Thu, 25 Jun 2020 12:07:56 +0000 Subject: [aarch64-port-dev ] [EXTERNAL] Re: OpenJDK extension to AArch64 and Windows In-Reply-To: References: Message-ID: Hey all - >Thank you for your review Andrew. +1 >> Rather than keep bouncing this back and forth until I'm statisfied, >> which would be boring for both of us, if you like I'll replace all of >> the bare "long" and "unsigned long" with the appropriate portable >> types. Do you want me to do that? >This would be great! Once I have your updated patch, I can test it on win+aarch64. Thanks both. Since both of you are in the same time zone it will be great for you to work together on it. The test platform for P1 would be 'linux-aarch64'. Just ping me once you are ready to test. Thanks. >Thank you, >-Bernhard -----Original Message----- From: Andrew Haley Sent: Thursday, 25 June 2020 10:26 To: Monica Beckwith ; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: [EXTERNAL] Re: OpenJDK extension to AArch64 and Windows On 24/06/2020 17:40, Monica Beckwith wrote: > Hello OpenJDK community, > > As the project lead here @Microsoft, I am pleased to share that we > have been working towards a Windows addition to the OpenJDK AArch64 > port. We are very thankful to all that have contributed to the > Linux+aarch64 and Windows+x86-64. Both these codebases came to our > rescue on numerous occasions. > > Support status: We have successfully ported C2 and can build the > server release (cross-compiled environment) > Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, > G1GC) Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. > Umbrella Bug ID: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7Cbeurba%40m > icrosoft.com%7Cfa1bff53ed8e4341186308d818e172f9%7C72f988bf86f141af91ab > 2d7cd011db47%7C1%7C0%7C637286703863799643&sdata=o%2FRsqlEGUcInzggB > MdjB0Ixi0cwKPUzaTyfJuUPEazU%3D&reserved=0 > Webrevs: > `Webrev P1`: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > jdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2F&data=02%7C01%7Cbeurb > a%40microsoft.com%7Cfa1bff53ed8e4341186308d818e172f9%7C72f988bf86f141a > f91ab2d7cd011db47%7C1%7C0%7C637286703863799643&sdata=ruv1ypJO74RlD > tMlfwK%2BBpqn5AtFi4sG90bDYmss5Go%3D&reserved=0 & This looks basically OK, but the use of uint64_t doesn't read well in aarch64.ad. (For what it's worth, the type used internally in HotSpot for $$constant is actually intptr_t.) 3130 enc_class aarch64_enc_mov_imm(iRegL dst, immL src) %{ 3131 C2_MacroAssembler _masm(&cbuf); 3132 Register dst_reg = as_Register($dst$$reg); 3133 uint64_t con = (uint64_t)$src$$constant; Here, the type of the register is iRegL, so con could be a julong, not a uint64_t. In general the easiest way to fix aarch64.ad is probably long -> jlong unsigned long -> julong u_int64_t -> uint64_t But not always everywhere. Here, the arg is an address offset: -void Assembler::adrp(Register reg1, const Address &dest, unsigned long &byte_offset) { +void Assembler::adrp(Register reg1, const Address &dest, uint64_t +&byte_offset) { ShouldNotReachHere(); } uintptr_t would do here. The coments in aarch64.ad like this one: - format %{ "mov $dst, $src\t# long" %} + format %{ "mov $dst, $src\t# int64_t" %} refer to a *Java type*. It shouldn't be changed. Rather than keep bouncing this back and forth until I'm statisfied, which would be boring for both of us, if you like I'll replace all of the bare "long" and "unsigned long" with the appropriate portable types. Do you want me to do that? Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7Cc9742e0dd9784f37557e08d818fd6032%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286823800279523&sdata=r1KgFWMNc6DFP0wqTDukX5AbMW%2BgjgPkmKEWzWmf%2FOs%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Monica.Beckwith at microsoft.com Thu Jun 25 12:16:51 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Thu, 25 Jun 2020 12:16:51 +0000 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: , <7148d08d-9510-9ad4-6b65-f833f6bacd37@oracle.com> Message-ID: Hey Magnus, Thank you so much for adding build-dev. I have subscribed to it now. It will be great if Ludovic can work with you in solving questions/concerns. If most of them are build system related, please feel free to drop the other aliases (except the cc one ??). I appreciate you working with / guiding us. -Monica -----Original Message----- From: Ludovic Henry Sent: Wednesday, June 24, 2020 4:34 PM To: Magnus Ihse Bursie ; Monica Beckwith ; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev Cc: openjdk-aarch64 Subject: Re: OpenJDK extension to AArch64 and Windows Hi Magnus, Happy to answer any question you have on the build system changes. A lot of the changes were due to the build system not supporting cross-compilation well when targetting the microsoft toolchain (it just never really had to support it). We had to go through a few hoops to remove as many of our own quick hacks, initially there just to get things building - like hardcoding the target being windows-aarch64 for example. Thank you for your review, -- Ludovic ________________________________________ From: Magnus Ihse Bursie Sent: Wednesday, June 24, 2020 13:44 To: Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev Cc: openjdk-aarch64 Subject: Re: OpenJDK extension to AArch64 and Windows Hi Monica, All build system changes must be sent to build-dev for review by the build team, and you are doing quite a lot of build changes. (I'm cc:ing build-dev now.) I did a quick scan and found some changes that looked odd enough to draw my attention. I will need some time to fully understand what you are trying to accomplish here, before I can give a full review. /Magnus On 2020-06-24 18:40, Monica Beckwith wrote: > Hello OpenJDK community, > > As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. > > Support status: We have successfully ported C2 and can build the > server release (cross-compiled environment) Test coverage: C2 + > ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. > Umbrella Bug ID: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs > .openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7CMonica.Bec > kwith%40microsoft.com%7C120c1eb9f5a7460546b608d818864aec%7C72f988bf86f > 141af91ab2d7cd011db47%7C1%7C0%7C637286312353215308&sdata=nkoPhKNfc > GMjMoW8ZHlWFEunv72LJr8WbGYGAcjeVbs%3D&reserved=0 > Webrevs: > `Webrev P1`: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > jdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2F&data=02%7C01%7CMonic > a.Beckwith%40microsoft.com%7C120c1eb9f5a7460546b608d818864aec%7C72f988 > bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286312353220284&sdata=wWVm > AxaJ90jIoGd%2FFKn1ikVO17iFk9s6tDp9Eoaxemk%3D&reserved=0 & `Webrev > P2`: > https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.open > jdk.java.net%2F~burban%2Fwinarm64_p2_new-target%2F&data=02%7C01%7C > Monica.Beckwith%40microsoft.com%7C120c1eb9f5a7460546b608d818864aec%7C7 > 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286312353220284&sdata > =3jvwY%2B9rZkpBZBbh7c%2FeKsigh5Y5L%2BbdnAVlCF0yFcA%3D&reserved=0 > > The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps > integrate support for Windows (LLP64) on Linux + AArch64 The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: > * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, > * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 > * `os/windows` in `threadCritical_windows.cpp`, > * Windbg support > * `globalDefinitions_visCPP.hpp` in `share/utilities` > * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). > Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. > > I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. > > As a part of this project, we have also worked on two additional patches: > * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247941&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C120c1eb9f5a7460546b608d818864aec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286312353220284&sdata=4HyuDEB%2FVPRWJ3Ls7V8WXKLp51Mn9%2F9lecTN4jTiYsU%3D&reserved=0 > * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. > > We welcome any feedback and comments from the community and are looking forward to working together. > > Regards, > Monica > > [1] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2Fwkload-status-o > n-Win%252BArm64.md&data=02%7C01%7CMonica.Beckwith%40microsoft.com% > 7C120c1eb9f5a7460546b608d818864aec%7C72f988bf86f141af91ab2d7cd011db47% > 7C1%7C0%7C637286312353220284&sdata=sq3mgeQIvl%2FJgbGz6xAlkV%2FJrZ5 > 5%2F6v0PqQG%2FhQvosw%3D&reserved=0 > [2] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FJTRegtests.md&a > mp;data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C120c1eb9f5a7460546 > b608d818864aec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372863123 > 53220284&sdata=DeDluHaDNU4bgXEaqlbF3ZugPJEWZhb%2B9QcoQZGXnBo%3D&am > p;reserved=0 [3] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FSPECJBB2015-tes > t-matrices.md&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C120 > c1eb9f5a7460546b608d818864aec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7 > C0%7C637286312353220284&sdata=KDyb6Q%2B85RbakKpLJaWWVSP3QXKOuYl%2B > uesUmKLkcsg%3D&reserved=0 [4] > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > .microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Farm64-windows-abi-conventions%3 > Fview%3Dvs-2019%23integer-registers&data=02%7C01%7CMonica.Beckwith > %40microsoft.com%7C120c1eb9f5a7460546b608d818864aec%7C72f988bf86f141af > 91ab2d7cd011db47%7C1%7C0%7C637286312353225263&sdata=lxuqpXdoQbvNDY > KE4JCKCtwzmWtpmw7sHBFBVp0Mwlo%3D&reserved=0 From rkennke at redhat.com Thu Jun 25 13:13:04 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 25 Jun 2020 15:13:04 +0200 Subject: [aarch64-port-dev ] RFR: Shenandoah integration 2020-06-25 Message-ID: I'd like to integrate 2 important backports from shenandoah/jdk8 to aarch64-port/jdk8u-shenandoah: http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2020-06-25/webrev.00/ It only touches Shenandoah code. Testing: several nightly runs of our CI, including hotspot_gc_shenandoah, specjvm, CTW tests and jcstress. Can I please get a review? Thanks, Roman From Monica.Beckwith at microsoft.com Thu Jun 25 14:46:50 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Thu, 25 Jun 2020 14:46:50 +0000 Subject: [aarch64-port-dev ] [EXTERNAL] Re: OpenJDK extension to AArch64 and Windows In-Reply-To: <7399bb11-ba06-aadd-eb9d-a5b970e63d0d@redhat.com> References: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> <7399bb11-ba06-aadd-eb9d-a5b970e63d0d@redhat.com> Message-ID: Hello all, Here's my reasoning for this not to warrant a JEP: ? We are extending the `AArch64 Port Project` [1] while keeping its essence: "It is hoped that this project will eventually be able to support operating systems other than GNU/Linux, and welcomes contributors with the necessary expertise." And we hope to be contributors to `aarch64-port.` ? The OpenJDK team at Microsoft understands that this extension is building on the fantastic work of giants. ? The new platform code by itself is confined to 15 (+4) files (1222 lines (+322)). To us, this is a small, clean enough footprint to not stir up the JEP process on size/complexity grounds. ? All the other files are bridging/building support in existing files. We have tried to minimize our ripple, and you will probably notice that some shared files have a single line change to them. ? Nonetheless, they have to be reviewed, and we appreciate the time folks will be spending on this. ? We sent the initial patches to `aarch64-port-dev` and `hotspot-runtime-dev.` And we were thankfully and rightfully guided to `build-dev.` We will continue to work with all to support changes to the all of the patches [2]. ? The OpenJDK team at Microsoft is fully invested in maintaining the patches in the long term. We are happy to work through any improvements to them, splitting them up further if needed, etc. ? I also envision that our support and maintenance will spread beyond the windows+aarch64 combo into linux+aarch64 and windows+x86-64 ? As you can tell from the patches, we touch all those platforms, since our goal was/is not only to push out the new platform support but also to support/cleanup/coalesce all that we touch. As mentioned in my initial email, our P2 patch will need some reworking with respect to R18 and we have been working together with AndrewH and AndrewD to deliver a fix. As you all know, AndrewH is also the lead for the `aarch64-port` project. Given the above, our preference is to continue working with the reviewers (as AndrewH has stated). I am positive that in the future, we will have many opportunities to collaborate via JEPs/projects. Regards, Monica [1] https://openjdk.java.net/projects/aarch64-port/ [2] The team is aware + invested in the amount of testing that is needed to support all the platforms with the CI pipeline. With the initial patches/webrevs, we have provided the info and our coverage on those. I am happy to expand that as needed. -----Original Message----- From: Andrew Haley Sent: Thursday, June 25, 2020 3:29 AM To: Alan Bateman ; David Holmes ; Monica Beckwith ; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: [EXTERNAL] Re: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows On 25/06/2020 08:39, Alan Bateman wrote: > On 24/06/2020 23:34, David Holmes wrote: >> >> Are you proposing a new project to introduce this new port into the >> OpenJDK some time in the future? > > I think it will need a JEP at least. I could imagine doing some > cleanup in advance, maybe also improvements to support cross building > on Windows, to eliminate some of the noise from the patch. If someone want to do the JEP bureaucracy that's fine by me, but in the meantime we'll try to get the AArch64 parts in shape so that the Windows import is simpler. In particular, we can get all of the register and integer type changes done. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C707b458cc15f4e5c99a008d818e1c23d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286705193417733&sdata=e5bM%2B%2BkSPuCHmje65EZUGDbMjNNVvwpbP%2Bd1Ga%2BZYpk%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Thu Jun 25 14:49:37 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 25 Jun 2020 16:49:37 +0200 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: Message-ID: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> Hi Monica, it sounds as if you're making good progress on porting OpenJDK to a new opertaing system/cpu architecture combination. Typically such efforts would become with a porting Project of their own, just as the aarch64-linux port did back in 2013 [1], as that allows a community of developers across organizations to start to collaborate around a shared repository, mailing list, etc. on a specific porting task. It also makes it easier to do so, by allowing the initial set of developers on the port to become committers on the new project from the start, without having to work their way up to 8 or more significant sponsored changes first [0]. So that's what I (with my Porting Group Lead hat on) would usually recommend that course for new ports. If you'd like to propose a new porting Project, you can find the instructions on how to do so here: https://openjdk.java.net/projects/#new-project Once you have porting a Project, you can start/continue working on the port at your own pace. You'll probably accumulate both changes that are specific to your port, as as well as more general changes, in the process of doing that. A good idea is to try to push changes that are not specific to your port, but instead may be of more general value to mainline, through individual patches. That makes it easier to regularly sync with mainline, and makes your life easier when it comes to merging a port into mainline eventually. For that to happen, there ultimately would need to be a JEP accompanying the feature, and of course the port would have to be complete, maintained, and last but not least pass the latest JCK for the Java SE Platform. But considering that you're just starting out, that's still somewhere down the road, so first things first: welcome (back), and good luck with the port! cheers, dalibor topic [0] https://openjdk.java.net/projects/#project-committer [1] http://mail.openjdk.java.net/pipermail/announce/2013-January/000142.html On 24.06.2020 18:40, Monica Beckwith wrote: > Hello OpenJDK community, > > As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. > > Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) > Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) > Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. > Umbrella Bug ID: https://bugs.openjdk.java.net/browse/JDK-8248238 > Webrevs: > `Webrev P1`: http://cr.openjdk.java.net/~burban/winarm64_p1_llp64/ & > `Webrev P2`: http://cr.openjdk.java.net/~burban/winarm64_p2_new-target/ > > The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 > The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: > * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, > * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 > * `os/windows` in `threadCritical_windows.cpp`, > * Windbg support > * `globalDefinitions_visCPP.hpp` in `share/utilities` > * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). > Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. > > I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. > > As a part of this project, we have also worked on two additional patches: > * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://bugs.openjdk.java.net/browse/JDK-8247941 > * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. > > We welcome any feedback and comments from the community and are looking forward to working together. > > Regards, > Monica > > [1] https://github.com/microsoft/openjdk-aarch64/blob/master/wkload-status-on-Win%2BArm64.md > [2] https://github.com/microsoft/openjdk-aarch64/blob/master/JTRegtests.md > [3] https://github.com/microsoft/openjdk-aarch64/blob/master/SPECJBB2015-test-matrices.md > [4] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#integer-registers > -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From aph at redhat.com Thu Jun 25 15:05:45 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jun 2020 16:05:45 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> Message-ID: <421a1d12-9e36-c8ea-8849-8d15ca6625bb@redhat.com> On 25/06/2020 15:49, Dalibor Topic wrote: > Typically such efforts would become with a porting Project of their own, > just as the aarch64-linux port did back in 2013 [1], as that allows a > community of developers across organizations to start to collaborate > around a shared repository, mailing list, etc. on a specific porting task. > > It also makes it easier to do so, by allowing the initial set of > developers on the port to become committers on the new project from the > start, without having to work their way up to 8 or more significant > sponsored changes first [0]. So that's what I (with my Porting Group > Lead hat on) would usually recommend that course for new ports. That would be madness. The Windows port to AArch64 is vastly simpler than the aarch64-linux port by more than an order of magnitude, because the AArch64 back end barely changes at all and the Windows (x86) part doesn't change very much because it's mostly C++ code and the Windows APIs are pretty stable. The code as submitted by Microsoft is almost ready to go. Introducing a whole lot of process at this stage would be entirely inappropriate and greatly increase the work for both HotSpot developers and the Microsoft porters. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neugens at redhat.com Thu Jun 25 15:02:09 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 25 Jun 2020 17:02:09 +0200 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> Message-ID: On Thu, Jun 25, 2020 at 4:52 PM Dalibor Topic wrote: > > Hi Monica, > > it sounds as if you're making good progress on porting OpenJDK to a new > opertaing system/cpu architecture combination. > > Typically such efforts would become with a porting Project of their own, > just as the aarch64-linux port did back in 2013 [1], as that allows a > community of developers across organizations to start to collaborate > around a shared repository, mailing list, etc. on a specific porting task. Wouldn't it be easier to just consider this part of aarch64? I don't think there's an aarch64-linux, just an aarch64-port/ that is "cross" platform (although started as Linux for obvious reasons)? http://openjdk.java.net/projects/aarch64-port/ I didn't read the patch yet so I'm sure you have a point, but just saying, Microsoft could be joining the effort with the other developers in the same codebase, which would be more useful (and eventually anyway needs to be merged), unless this is so experimental that we see a chance of breaking the mainline. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Thu Jun 25 16:04:09 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 25 Jun 2020 17:04:09 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> Message-ID: <57c7073d-3e72-243c-e2a5-9123aef4d999@redhat.com> On 25/06/2020 08:39, Alan Bateman wrote: > On 24/06/2020 23:34, David Holmes wrote: >> Hi Monica, >> >> Are you proposing a new project to introduce this new port into the >> OpenJDK some time in the future? > I think it will need a JEP at least. I could imagine doing some cleanup > in advance, maybe also improvements to support cross building on > Windows, to eliminate some of the noise from the patch. > > -Alan. > As I've commented on the bug [0], I don't think a new project is necessary to provide OS support for an architecture port, when the port already has its own project (aarch64-port), and the developers involved in adding support are already working with the people involved in said project. After all, the ppc-aix-port project seems to have branched out quite happily beyond AIX ;-) A JEP does seem appropriate though, so the work is listed in the release notes of the next JDK release. [0] https://bugs.openjdk.java.net/browse/JDK-8248238 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Thu Jun 25 16:11:13 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 25 Jun 2020 17:11:13 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <421a1d12-9e36-c8ea-8849-8d15ca6625bb@redhat.com> References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> <421a1d12-9e36-c8ea-8849-8d15ca6625bb@redhat.com> Message-ID: <73e84bd7-910d-b36f-a00a-7ec1e2e982a1@redhat.com> On 25/06/2020 16:05, Andrew Haley wrote: > On 25/06/2020 15:49, Dalibor Topic wrote: >> Typically such efforts would become with a porting Project of their own, >> just as the aarch64-linux port did back in 2013 [1], as that allows a >> community of developers across organizations to start to collaborate >> around a shared repository, mailing list, etc. on a specific porting task. >> >> It also makes it easier to do so, by allowing the initial set of >> developers on the port to become committers on the new project from the >> start, without having to work their way up to 8 or more significant >> sponsored changes first [0]. So that's what I (with my Porting Group >> Lead hat on) would usually recommend that course for new ports. > > That would be madness. > > The Windows port to AArch64 is vastly simpler than the aarch64-linux > port by more than an order of magnitude, because the AArch64 back end > barely changes at all and the Windows (x86) part doesn't change very > much because it's mostly C++ code and the Windows APIs are pretty > stable. > > The code as submitted by Microsoft is almost ready to go. Introducing > a whole lot of process at this stage would be entirely inappropriate > and greatly increase the work for both HotSpot developers and the > Microsoft porters. I agree entirely with Andrew. If you look at the webrevs provided by Microsoft they are smaller than a great number of patches that have only been covered by a JIRA issue. The amount of code touched and the significance of the changes is far too small to merit a whole project (or, I would say, a JEP). To me this contribution is a relatively small extension of the work covered by the existing AArch64 port. I cannot see any reason to smother it in a bureaucratic process that is very unlikely to improve the outcome and, indeed, much more likely to achieve the opposite. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From neugens at redhat.com Thu Jun 25 16:18:51 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 25 Jun 2020 18:18:51 +0200 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <73e84bd7-910d-b36f-a00a-7ec1e2e982a1@redhat.com> References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> <421a1d12-9e36-c8ea-8849-8d15ca6625bb@redhat.com> <73e84bd7-910d-b36f-a00a-7ec1e2e982a1@redhat.com> Message-ID: On Thu, Jun 25, 2020 at 6:14 PM Andrew Dinn wrote: > > On 25/06/2020 16:05, Andrew Haley wrote: > > On 25/06/2020 15:49, Dalibor Topic wrote: > >> Typically such efforts would become with a porting Project of their own, > >> just as the aarch64-linux port did back in 2013 [1], as that allows a > >> community of developers across organizations to start to collaborate > >> around a shared repository, mailing list, etc. on a specific porting task. > >> > >> It also makes it easier to do so, by allowing the initial set of > >> developers on the port to become committers on the new project from the > >> start, without having to work their way up to 8 or more significant > >> sponsored changes first [0]. So that's what I (with my Porting Group > >> Lead hat on) would usually recommend that course for new ports. > > > > That would be madness. > > > > The Windows port to AArch64 is vastly simpler than the aarch64-linux > > port by more than an order of magnitude, because the AArch64 back end > > barely changes at all and the Windows (x86) part doesn't change very > > much because it's mostly C++ code and the Windows APIs are pretty > > stable. > > > > The code as submitted by Microsoft is almost ready to go. Introducing > > a whole lot of process at this stage would be entirely inappropriate > > and greatly increase the work for both HotSpot developers and the > > Microsoft porters. > I agree entirely with Andrew. If you look at the webrevs provided by > Microsoft they are smaller than a great number of patches that have only > been covered by a JIRA issue. The amount of code touched and the > significance of the changes is far too small to merit a whole project > (or, I would say, a JEP). > > To me this contribution is a relatively small extension of the work > covered by the existing AArch64 port. I cannot see any reason to smother > it in a bureaucratic process that is very unlikely to improve the > outcome and, indeed, much more likely to achieve the opposite. Yeah, I don't have a strong opinion on the JEP, but regarding the project home also the AArch64 port webpage strongly hints that this is the natural home for such ports (and I may say, if Apple really wants to contribute an Arm port this is where they should be looking at too as first option!): "It is hoped that this project will eventually be able to support operating systems other than GNU/Linux, and welcomes contributors with the necessary expertise." Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From Alan.Bateman at oracle.com Thu Jun 25 16:29:54 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Jun 2020 17:29:54 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <57c7073d-3e72-243c-e2a5-9123aef4d999@redhat.com> References: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> <57c7073d-3e72-243c-e2a5-9123aef4d999@redhat.com> Message-ID: <46d66f15-3adf-46eb-9322-cd6e47bb4379@oracle.com> On 25/06/2020 17:04, Andrew Hughes wrote: > As I've commented on the bug [0], I don't think a new project is > necessary to provide OS support for an architecture port, when the port > already has its own project (aarch64-port), and the developers involved > in adding support are already working with the people involved in said > project. After all, the ppc-aix-port project seems to have branched out > quite happily beyond AIX ;-) > > A JEP does seem appropriate though, so the work is listed in the release > notes of the next JDK release. > Yes, I think a JEP would be good to have so that this port gets onto the technical roadmap. I can't imagine it being more than one page to describe the "feature" and maybe the testing. There are several other JEPs for ports so some of the text can be re-used. JEPs are great for capturing decisions and other information that might be useful to maintainers down the road. Also helps to get a bit of exposure as many developers and bloggers only pick up on the JEPs in a release (and ignore the hundreds of other features). -Alan From vladimir.kozlov at oracle.com Thu Jun 25 16:54:38 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jun 2020 09:54:38 -0700 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <46d66f15-3adf-46eb-9322-cd6e47bb4379@oracle.com> References: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> <57c7073d-3e72-243c-e2a5-9123aef4d999@redhat.com> <46d66f15-3adf-46eb-9322-cd6e47bb4379@oracle.com> Message-ID: <9a40005b-800c-faab-67d2-833bcc77f659@oracle.com> I also think you should use JEP and aarch64 project for this work. 8248238 [1] already looks like a JEP. Just convert it into formal. You can use Linux/s390x Port JEP [2] as example except FC Extension request ;) and corresponding 'Summary' (please, don't reference any particular JDK version). Regards, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8248238 [2] https://bugs.openjdk.java.net/browse/JDK-8166730 On 6/25/20 9:29 AM, Alan Bateman wrote: > On 25/06/2020 17:04, Andrew Hughes wrote: >> As I've commented on the bug [0], I don't think a new project is >> necessary to provide OS support for an architecture port, when the port >> already has its own project (aarch64-port), and the developers involved >> in adding support are already working with the people involved in said >> project. After all, the ppc-aix-port project seems to have branched out >> quite happily beyond AIX ;-) >> >> A JEP does seem appropriate though, so the work is listed in the release >> notes of the next JDK release. >> > Yes, I think a JEP would be good to have so that this port gets onto the technical roadmap. I can't imagine it being > more than one page to describe the "feature" and maybe the testing. There are several other JEPs for ports so some of > the text can be re-used. JEPs are great for capturing decisions and other information that might be useful to > maintainers down the road. Also helps to get a bit of exposure as many developers and bloggers only pick up on the JEPs > in a release (and ignore the hundreds of other features). > > -Alan From aph at redhat.com Thu Jun 25 17:11:46 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jun 2020 18:11:46 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <9a40005b-800c-faab-67d2-833bcc77f659@oracle.com> References: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> <57c7073d-3e72-243c-e2a5-9123aef4d999@redhat.com> <46d66f15-3adf-46eb-9322-cd6e47bb4379@oracle.com> <9a40005b-800c-faab-67d2-833bcc77f659@oracle.com> Message-ID: <736e45bf-e576-a788-da3a-618d8d29bbe1@redhat.com> On 25/06/2020 17:54, Vladimir Kozlov wrote: > I also think you should use JEP and aarch64 project for this work. The existing aarch64-port project, I take it? Not a new one? Good. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mark.reinhold at oracle.com Thu Jun 25 17:13:05 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 25 Jun 2020 10:13:05 -0700 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <73e84bd7-910d-b36f-a00a-7ec1e2e982a1@redhat.com> References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> <421a1d12-9e36-c8ea-8849-8d15ca6625bb@redhat.com> <73e84bd7-910d-b36f-a00a-7ec1e2e982a1@redhat.com> Message-ID: <20200625101305.787597055@eggemoggin.niobe.net> 2020/6/25 9:11:13 -0700, Andrew Dinn : > On 25/06/2020 16:05, Andrew Haley wrote: >> ... >> >> The code as submitted by Microsoft is almost ready to go. Introducing >> a whole lot of process at this stage would be entirely inappropriate >> and greatly increase the work for both HotSpot developers and the >> Microsoft porters. > > I agree entirely with Andrew. If you look at the webrevs provided by > Microsoft they are smaller than a great number of patches that have only > been covered by a JIRA issue. The amount of code touched and the > significance of the changes is far too small to merit a whole project > (or, I would say, a JEP). I agree that an entire project would be overkill. I do, however, think that a JEP is more than justified. Porting the JDK to a new platform is a significant change, even if the change is a essentially a remix of existing code. JEPs are our established process for documenting and communicating significant changes. It needn?t be a long JEP, as others have already pointed out. - Mark From vladimir.kozlov at oracle.com Thu Jun 25 17:15:47 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 25 Jun 2020 10:15:47 -0700 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <736e45bf-e576-a788-da3a-618d8d29bbe1@redhat.com> References: <32a1fc35-0c1a-efe5-c96b-45f44d03717f@oracle.com> <57c7073d-3e72-243c-e2a5-9123aef4d999@redhat.com> <46d66f15-3adf-46eb-9322-cd6e47bb4379@oracle.com> <9a40005b-800c-faab-67d2-833bcc77f659@oracle.com> <736e45bf-e576-a788-da3a-618d8d29bbe1@redhat.com> Message-ID: Yes, the existing aarch64-port project. On 6/25/20 10:11 AM, Andrew Haley wrote: > On 25/06/2020 17:54, Vladimir Kozlov wrote: >> I also think you should use JEP and aarch64 project for this work. > > The existing aarch64-port project, I take it? Not a new one? Good. > From aph at redhat.com Thu Jun 25 17:18:25 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jun 2020 18:18:25 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: <20200625101305.787597055@eggemoggin.niobe.net> References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> <421a1d12-9e36-c8ea-8849-8d15ca6625bb@redhat.com> <73e84bd7-910d-b36f-a00a-7ec1e2e982a1@redhat.com> <20200625101305.787597055@eggemoggin.niobe.net> Message-ID: <5f671ab7-1a55-937f-8fc8-6383e598bac3@redhat.com> On 25/06/2020 18:13, mark.reinhold at oracle.com wrote: > I agree that an entire project would be overkill. > > I do, however, think that a JEP is more than justified. Porting the > JDK to a new platform is a significant change, even if the change is > a essentially a remix of existing code. JEPs are our established > process for documenting and communicating significant changes. > > It needn?t be a long JEP, as others have already pointed out. OK. Especially, as Vladimir has pointed out, it needn't be much more than the contents of https://bugs.openjdk.java.net/browse/JDK-8248238 -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From boris.ulasevich at bell-sw.com Thu Jun 25 17:34:33 2020 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Thu, 25 Jun 2020 20:34:33 +0300 Subject: [aarch64-port-dev ] RFR: C2: Canonicalize (x & 16 == 16) [Was: AARCH64 optimization: using TBZ instruction for bit check] In-Reply-To: <709f87e9-9c4f-b9ad-5246-90c9c92c5e6b@oracle.com> References: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> <14d3f034-b637-f74a-7567-d4e589260887@redhat.com> <709f87e9-9c4f-b9ad-5246-90c9c92c5e6b@oracle.com> Message-ID: <76f3f585-feaf-e606-a35a-8b7d85d2ec9f@bell-sw.com> Vladimir, thank you! I think I need one more review. Can I ask someone else to have a look? Thanks, Boris On 22.06.2020 18:48, Vladimir Kozlov wrote: > On 6/22/20 7:45 AM, Boris Ulasevich wrote: >> Hi Vladimir, >> >> ?> Would be nice to know if any Java benchmark is affected. >> >> With the change we have got 5% performance boost on lucene tokenizer >> method on ARM64. Same time on x86 there is no visible improvement on >> lucene tokenizer. > > Good. > > I ran our benchmarks (mostly jvm2008) on x86 and don't see any effects > too. > > Thanks, > Vladimir > >> >> thanks, >> Boris >> >> import org.apache.lucene.analysis.standard.StandardTokenizerImpl; >> import java.nio.file.Files; >> import java.io.*; >> >> class Test { >> ?? public static void main(String args[]) { >> ???? long count = 0; >> ???? try { >> ?????? byte[] content = Files.readAllBytes(new >> File("aarch64.ad").toPath()); >> ?????? for (int i=0; i < 1000; i++) { >> ???????? Reader reader = new InputStreamReader(new >> ByteArrayInputStream(content)); >> ???????? StandardTokenizerImpl sti = new StandardTokenizerImpl(reader); >> ???????? while (sti.getNextToken() != -1) { >> ?????????? count ++; >> ???????? } >> ?????? } >> ???? } catch (Exception ex) { System.out.println(ex); } >> ???? System.out.println(count); >> ?? } >> } >> >> >> On 19.06.2020 21:36, Vladimir Kozlov wrote: >>> Nice optimization. >>> >>> I don't think we should turn it off on any machine. In real >>> application you will not see such tight loops only with such branch. >>> On other hand reducing code size should help in all cases. >>> >>> Would be nice to know if any Java benchmark is affected. >>> >>> I will try to run our set of benchmarks with these changes. >>> >>> Regards, >>> Vladimir K >>> >>> On 6/19/20 10:07 AM, Andrew Haley wrote: >>>> Hi, >>>> >>>> On 19/06/2020 17:49, Boris Ulasevich wrote: >>>>> I added the expression canonicalization in the BoolNode::Ideal >>>>> method: >>>>> http://cr.openjdk.java.net/~bulasevich/8247408/webrev.02b >>>>> >>>>> The change reduces a number of generated machine instructions on all >>>>> ARM/x86/PPC architectures. Benchmark shows positive results on >>>>> ARM64 and >>>>> ARM32 with the given change. >>>>> >>>>> On x86 benchmark performance improves from +1% to +13% depending >>>>> on the >>>>> CPU generation, except of machines affected by Intel Erratum >>>>> (JDK-8234160) >>>>> issue. Maximum decrease observed is -%11. It does not look like a >>>>> problem >>>>> with the proposed benchmark though, but rather like an issue with >>>>> Erratum mitigation. >>>>> >>>>> On PowerPC result of the micro-benchmark is also positive. I >>>>> changed the >>>>> micro-benchmark to make it a little bulkier so that we don't hit the >>>>> limitations of architectures with a less elaborate branch prediction >>>>> mechanism. The original application performance does not change on >>>>> PowerPC. >>>> >>>> Fantastic work, thanks! You've done a remarkably thorough job. It's >>>> slightly unfortunate that one of the targets regresses. If there had >>>> been no regressions, I'd approve this straight away. >>>> >>>> Forwarding to hotspot-compiler-dev for more comments. >>>> >>>> VladimirK, what do you think? I guess we could turn this off on the >>>> machines affected by JDK-8234160. Should we? >>>> >> From ci_notify at linaro.org Thu Jun 25 20:53:29 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 25 Jun 2020 20:53:29 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64 Message-ID: <466963615.5340.1593118409557.JavaMail.javamailuser@localhost> 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/jdk14/openjdk-jtreg-nightly-tests/summary/2020/175/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 Build 6: aarch64/2020/may/07 pass: 5,763; fail: 44 Build 7: aarch64/2020/may/12 pass: 5,761; fail: 46 Build 8: aarch64/2020/may/15 pass: 5,784; fail: 46 Build 9: aarch64/2020/may/28 pass: 5,785; fail: 45 Build 10: aarch64/2020/jun/01 pass: 5,784; fail: 47 Build 11: aarch64/2020/jun/04 pass: 5,787; fail: 45 Build 12: aarch64/2020/jun/13 pass: 5,786; fail: 46 Build 13: aarch64/2020/jun/23 pass: 5,786; fail: 46 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 Build 6: aarch64/2020/may/07 pass: 8,835; fail: 517; error: 20 Build 7: aarch64/2020/may/12 pass: 8,836; fail: 517; error: 19 Build 8: aarch64/2020/may/15 pass: 8,845; fail: 509; error: 18 Build 9: aarch64/2020/may/28 pass: 8,838; fail: 516; error: 18 Build 10: aarch64/2020/jun/01 pass: 8,847; fail: 509; error: 16 Build 11: aarch64/2020/jun/04 pass: 8,838; fail: 517; error: 17 Build 12: aarch64/2020/jun/13 pass: 8,846; fail: 510; error: 17 Build 13: aarch64/2020/jun/23 pass: 8,846; fail: 508; error: 19 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Build 7: aarch64/2020/may/07 pass: 4,031 Build 8: aarch64/2020/may/12 pass: 4,031 Build 9: aarch64/2020/may/15 pass: 4,031 Build 10: aarch64/2020/may/28 pass: 4,031 Build 11: aarch64/2020/jun/01 pass: 4,031 Build 12: aarch64/2020/jun/04 pass: 4,031 Build 13: aarch64/2020/jun/13 pass: 4,031 Build 14: aarch64/2020/jun/23 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/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): 9.48x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/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: 213.86 Server 213.86 / Server 2014-04-01 (71.00): 3.01x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/128/results/ 2020-05-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/133/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/136/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/149/results/ 2020-06-02 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/153/results/ 2020-06-07 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/156/results/ 2020-06-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/165/results/ 2020-06-25 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/175/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/ From ci_notify at linaro.org Thu Jun 25 20:56:56 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 25 Jun 2020 20:56:56 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <1145952751.5342.1593118617184.JavaMail.javamailuser@localhost> 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/jdk13/openjdk-jtreg-nightly-tests/summary/2020/175/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 1: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 2: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 3: aarch64/2019/nov/12 pass: 5,652 Build 4: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 5: aarch64/2019/nov/16 pass: 5,652 Build 6: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 7: aarch64/2019/dec/14 pass: 5,652 Build 8: aarch64/2020/jan/16 pass: 5,652 Build 9: aarch64/2020/may/28 pass: 5,669 Build 10: aarch64/2020/jun/02 pass: 5,677 Build 11: aarch64/2020/jun/09 pass: 5,691 Build 12: aarch64/2020/jun/18 pass: 5,696 Build 13: aarch64/2020/jun/20 pass: 5,695; fail: 1 Build 14: aarch64/2020/jun/23 pass: 5,695; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 1: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 2: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 3: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 4: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 5: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 6: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 7: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 8: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 9: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 Build 10: aarch64/2020/jun/02 pass: 8,686; fail: 509; error: 17 Build 11: aarch64/2020/jun/09 pass: 8,698; fail: 505; error: 16 Build 12: aarch64/2020/jun/18 pass: 8,712; fail: 495; error: 15 Build 13: aarch64/2020/jun/20 pass: 8,701; fail: 506; error: 16 Build 14: aarch64/2020/jun/23 pass: 8,691; fail: 517; error: 16 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/06 pass: 3,964 Build 1: aarch64/2019/aug/08 pass: 3,964 Build 2: aarch64/2019/aug/10 pass: 3,964 Build 3: aarch64/2019/nov/12 pass: 3,964 Build 4: aarch64/2019/nov/14 pass: 3,964 Build 5: aarch64/2019/nov/16 pass: 3,964 Build 6: aarch64/2019/dec/03 pass: 3,964 Build 7: aarch64/2019/dec/14 pass: 3,964 Build 8: aarch64/2020/jan/16 pass: 3,964 Build 9: aarch64/2020/may/28 pass: 3,964 Build 10: aarch64/2020/jun/02 pass: 3,964 Build 11: aarch64/2020/jun/09 pass: 3,965 Build 12: aarch64/2020/jun/18 pass: 3,965 Build 13: aarch64/2020/jun/20 pass: 3,965 Build 14: aarch64/2020/jun/23 pass: 3,965 Previous results can be found here: http://openjdk.linaro.org/jdk13/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.54x Relative performance: Server critical-jOPS (nc): 8.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/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/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/154/results/ 2020-06-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/161/results/ 2020-06-20 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/170/results/ 2020-06-21 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/172/results/ 2020-06-25 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/175/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From Monica.Beckwith at microsoft.com Thu Jun 25 21:20:51 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Thu, 25 Jun 2020 21:20:51 +0000 Subject: [aarch64-port-dev ] [EXTERNAL] Re: OpenJDK extension to AArch64 and Windows In-Reply-To: <5f671ab7-1a55-937f-8fc8-6383e598bac3@redhat.com> References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> <421a1d12-9e36-c8ea-8849-8d15ca6625bb@redhat.com> <73e84bd7-910d-b36f-a00a-7ec1e2e982a1@redhat.com> <20200625101305.787597055@eggemoggin.niobe.net> <5f671ab7-1a55-937f-8fc8-6383e598bac3@redhat.com> Message-ID: That's awesome to hear. I will work on the JEP proposal and reach out to Andrew as needed - thanks, Vladimir, for the pointer ??. Let's continue the reviews for the patches. Thanks all for your support. -Monica -----Original Message----- From: Andrew Haley Sent: Thursday, June 25, 2020 12:18 PM To: mark.reinhold at oracle.com; Andrew Dinn ; Monica Beckwith Cc: dalibor.topic at oracle.com; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 Subject: [EXTERNAL] Re: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows On 25/06/2020 18:13, mark.reinhold at oracle.com wrote: > I agree that an entire project would be overkill. > > I do, however, think that a JEP is more than justified. Porting the > JDK to a new platform is a significant change, even if the change is a > essentially a remix of existing code. JEPs are our established > process for documenting and communicating significant changes. > > It needn?t be a long JEP, as others have already pointed out. OK. Especially, as Vladimir has pointed out, it needn't be much more than the contents of https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C91529d47a2b74be4af4308d8192bcb16%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637287023173918774&sdata=cM%2Ft1xSs%2BJaeNecUg0Y0W7j6CgTW9KdAvOKivwQimds%3D&reserved=0 -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C91529d47a2b74be4af4308d8192bcb16%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637287023173918774&sdata=yMFnkT%2Bvx%2B3nBsRMAM3WrJOdaAODgXb4tZNyAcv744o%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Thu Jun 25 23:06:44 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2020 09:06:44 +1000 Subject: [aarch64-port-dev ] [EXTERNAL] Re: OpenJDK extension to AArch64 and Windows In-Reply-To: References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> <421a1d12-9e36-c8ea-8849-8d15ca6625bb@redhat.com> <73e84bd7-910d-b36f-a00a-7ec1e2e982a1@redhat.com> <20200625101305.787597055@eggemoggin.niobe.net> <5f671ab7-1a55-937f-8fc8-6383e598bac3@redhat.com> Message-ID: On 26/06/2020 7:20 am, Monica Beckwith wrote: > That's awesome to hear. I will work on the JEP proposal and reach out to Andrew as needed - thanks, Vladimir, for the pointer ??. > Let's continue the reviews for the patches. May I suggest that the review process restart with traditional RFR emails to the appropriate lists, using the JDK-8248238 bug id and synopsis. Thanks, David > Thanks all for your support. > -Monica > > -----Original Message----- > From: Andrew Haley > Sent: Thursday, June 25, 2020 12:18 PM > To: mark.reinhold at oracle.com; Andrew Dinn ; Monica Beckwith > Cc: dalibor.topic at oracle.com; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 > Subject: [EXTERNAL] Re: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows > > On 25/06/2020 18:13, mark.reinhold at oracle.com wrote: >> I agree that an entire project would be overkill. >> >> I do, however, think that a JEP is more than justified. Porting the >> JDK to a new platform is a significant change, even if the change is a >> essentially a remix of existing code. JEPs are our established >> process for documenting and communicating significant changes. >> >> It needn?t be a long JEP, as others have already pointed out. > > OK. Especially, as Vladimir has pointed out, it needn't be much more than the contents of https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C91529d47a2b74be4af4308d8192bcb16%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637287023173918774&sdata=cM%2Ft1xSs%2BJaeNecUg0Y0W7j6CgTW9KdAvOKivwQimds%3D&reserved=0 > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7CMonica.Beckwith%40microsoft.com%7C91529d47a2b74be4af4308d8192bcb16%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637287023173918774&sdata=yMFnkT%2Bvx%2B3nBsRMAM3WrJOdaAODgXb4tZNyAcv744o%3D&reserved=0 > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From adinn at redhat.com Fri Jun 26 08:25:29 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 26 Jun 2020 09:25:29 +0100 Subject: [aarch64-port-dev ] RFR: C2: Canonicalize (x & 16 == 16) [Was: AARCH64 optimization: using TBZ instruction for bit check] In-Reply-To: <76f3f585-feaf-e606-a35a-8b7d85d2ec9f@bell-sw.com> References: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> <14d3f034-b637-f74a-7567-d4e589260887@redhat.com> <709f87e9-9c4f-b9ad-5246-90c9c92c5e6b@oracle.com> <76f3f585-feaf-e606-a35a-8b7d85d2ec9f@bell-sw.com> Message-ID: <94b49d5e-ee73-64e6-289f-ccb90ef2a47b@redhat.com> Hi Boris, On 25/06/2020 18:34, Boris Ulasevich wrote: > Vladimir, thank you! > > I think I need one more review. Can I ask someone else to have a look? Yes, that looks good. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From boris.ulasevich at bell-sw.com Fri Jun 26 08:34:33 2020 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 26 Jun 2020 11:34:33 +0300 Subject: [aarch64-port-dev ] RFR: C2: Canonicalize (x & 16 == 16) [Was: AARCH64 optimization: using TBZ instruction for bit check] In-Reply-To: <94b49d5e-ee73-64e6-289f-ccb90ef2a47b@redhat.com> References: <9b399c9f-cfc1-7fc4-70ee-536a83e5afa7@redhat.com> <7bea8a5c-312b-b4f3-d545-f83652b73150@bell-sw.com> <14d3f034-b637-f74a-7567-d4e589260887@redhat.com> <709f87e9-9c4f-b9ad-5246-90c9c92c5e6b@oracle.com> <76f3f585-feaf-e606-a35a-8b7d85d2ec9f@bell-sw.com> <94b49d5e-ee73-64e6-289f-ccb90ef2a47b@redhat.com> Message-ID: Hi Andrew, Thanks for the review. Boris On 26.06.2020 11:25, Andrew Dinn wrote: > Hi Boris, > > On 25/06/2020 18:34, Boris Ulasevich wrote: >> Vladimir, thank you! >> >> I think I need one more review. Can I ask someone else to have a look? > Yes, that looks good. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From stefan.karlsson at oracle.com Fri Jun 26 08:50:53 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 26 Jun 2020 10:50:53 +0200 Subject: [aarch64-port-dev ] [15] RFR: 8248048: ZGC: AArch64: SIGILL in load barrier register spilling Message-ID: Hi all, Please review this patch to fix a ZGC load barrier register spilling bug. https://cr.openjdk.java.net/~stefank/8248048/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8248048 The JVM crashed with an ILL_ILLOPC when executing this instruction in our load barrier stub: ? ldp q31, q31, [sp, #224] The entire load barrier stub: ?? 0x0000ffff998ab964:??? stp??? x10, x13, [sp, #-32]! ?? 0x0000ffff998ab968:??? stp??? x14, x17, [sp, #16] ?? 0x0000ffff998ab96c:??? stp??? q1, q2, [sp, #-256]! ?? 0x0000ffff998ab970:??? stp??? q3, q19, [sp, #32] ?? 0x0000ffff998ab974:??? stp??? q20, q21, [sp, #64] ?? 0x0000ffff998ab978:??? stp??? q22, q23, [sp, #96] ?? 0x0000ffff998ab97c:??? stp??? q24, q25, [sp, #128] ?? 0x0000ffff998ab980:??? stp??? q26, q28, [sp, #160] ?? 0x0000ffff998ab984:??? stp??? q29, q30, [sp, #192] ?? 0x0000ffff998ab988:??? stp??? q31, q31, [sp, #224] ?? 0x0000ffff998ab98c:??? sub??? x1, x10, #0x0 ?? 0x0000ffff998ab990:??? mov??? x0, x11 ?? 0x0000ffff998ab994:??? mov??? x8, #0xfc28??????????????? ??? // #64552 ?? 0x0000ffff998ab998:??? movk??? x8, #0xaf11, lsl #16 ?? 0x0000ffff998ab99c:??? movk??? x8, #0xffff, lsl #32 ?? 0x0000ffff998ab9a0:??? blr??? x8 ; branch into the JVM ?? 0x0000ffff998ab9a4:??? mov??? x11, x0 ?? 0x0000ffff998ab9a8:??? ldp??? q3, q19, [sp, #32] ?? 0x0000ffff998ab9ac:??? ldp??? q20, q21, [sp, #64] ?? 0x0000ffff998ab9b0:??? ldp??? q22, q23, [sp, #96] ?? 0x0000ffff998ab9b4:??? ldp??? q24, q25, [sp, #128] ?? 0x0000ffff998ab9b8:??? ldp??? q26, q28, [sp, #160] ?? 0x0000ffff998ab9bc:??? ldp??? q29, q30, [sp, #192] => 0x0000ffff998ab9c0:??? ldp??? q31, q31, [sp, #224] ?? 0x0000ffff998ab9c4:??? ldp??? q1, q2, [sp], #256 ?? 0x0000ffff998ab9c8:??? ldp??? x14, x17, [sp, #16] ?? 0x0000ffff998ab9cc:??? ldp??? x10, x13, [sp], #32 ?? 0x0000ffff998ab9d0:??? b??? 0xffff998aa718 It seems to be illegal to use the same register twice when loading into a pair of registers. I verified that that was the problem, and not the usage of zr (see below) that caused some weird encoding, by changing the code to always generate stp/ldp with the same register: => 0x0000ffff757d22fc:??? ldp??? q20, q20, [sp, #32] ; Crash here as well ?? 0x0000ffff757d2300:??? ldp??? q21, q21, [sp, #48] ?? 0x0000ffff757d2304:??? ldp??? q22, q22, [sp, #64] The code that generates this instruction is MacroAssembler::push_fp, which spills the necessary registers in pairs with stp/ldp calls. If the number of registers to spill is odd it needs to deal with one of the registers separately. This is done by adding a dummy register here: 2136 regs[count++] = zr->encoding_nocheck(); 2137 count &= ~1; // Only push an even number of regs This scheme seems to work for the normal registers (MacroAssembler::push), but the usage of zr seems dubious when we're dealing with the fp/simd version of stp/ldp. My proposed patch replaces the stp/ldp for the odd numbered register with the single-register versions: str/ldr. I make sure to keep the stack 16 bytes aligned by still bumping 16 bytes, but skipping the store/load to the second 8 bytes half. Note that right now MacroAssembler::push_fp is only used by ZGC. This fixes the crash. I've run this code through jtreg groups :tier1, tier2, tier3, and an Oracle-internal stress suite without any new problems. The smallest reproducer I have is: make -C ../build/fastdebug test TEST=test/jdk/java/util/concurrent/ JTREG="JAVA_OPTIONS=-XX:+UseZGC" Does this look OK? Thanks, StefanK From adinn at redhat.com Fri Jun 26 10:05:35 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 26 Jun 2020 11:05:35 +0100 Subject: [aarch64-port-dev ] [15] RFR: 8248048: ZGC: AArch64: SIGILL in load barrier register spilling In-Reply-To: References: Message-ID: <5261f83d-46bf-e469-0e40-7b8b534d86c6@redhat.com> Hi Stefan, Yes, nice catch. zr is clearly the wrong choice here. In the context of an FP register it ends up being interpreted as q31 which, as you show, clashes when r31 is the last register in an odd register set. Your fix looks ok to me (so count it as reviewed). Just for your interest, another alternative would be to continue to use stpq instructions but replace zr with an fp register that is a) in the save set but b) guaranteed to differ from the last register,-- the obvious choice being regs[0]. That will work in all cases where count >= 2 (well 3 actually since the problem only arises in odd cases). So, you would still need to special case count == 0/1 and only add regs[0] to the set after handling those cases. I'm agnostic over which of these two is better as I don't think either a stpq or a strq pre/post is preferable to the other. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 26/06/2020 09:50, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix a ZGC load barrier register spilling bug. > > https://cr.openjdk.java.net/~stefank/8248048/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8248048 > > The JVM crashed with an ILL_ILLOPC when executing this instruction in > our load barrier stub: > > ? ldp q31, q31, [sp, #224] > > The entire load barrier stub: > > ?? 0x0000ffff998ab964:??? stp??? x10, x13, [sp, #-32]! > ?? 0x0000ffff998ab968:??? stp??? x14, x17, [sp, #16] > ?? 0x0000ffff998ab96c:??? stp??? q1, q2, [sp, #-256]! > ?? 0x0000ffff998ab970:??? stp??? q3, q19, [sp, #32] > ?? 0x0000ffff998ab974:??? stp??? q20, q21, [sp, #64] > ?? 0x0000ffff998ab978:??? stp??? q22, q23, [sp, #96] > ?? 0x0000ffff998ab97c:??? stp??? q24, q25, [sp, #128] > ?? 0x0000ffff998ab980:??? stp??? q26, q28, [sp, #160] > ?? 0x0000ffff998ab984:??? stp??? q29, q30, [sp, #192] > ?? 0x0000ffff998ab988:??? stp??? q31, q31, [sp, #224] > ?? 0x0000ffff998ab98c:??? sub??? x1, x10, #0x0 > ?? 0x0000ffff998ab990:??? mov??? x0, x11 > ?? 0x0000ffff998ab994:??? mov??? x8, #0xfc28??????????????? ??? // #64552 > ?? 0x0000ffff998ab998:??? movk??? x8, #0xaf11, lsl #16 > ?? 0x0000ffff998ab99c:??? movk??? x8, #0xffff, lsl #32 > ?? 0x0000ffff998ab9a0:??? blr??? x8 ; branch into the JVM > ?? 0x0000ffff998ab9a4:??? mov??? x11, x0 > ?? 0x0000ffff998ab9a8:??? ldp??? q3, q19, [sp, #32] > ?? 0x0000ffff998ab9ac:??? ldp??? q20, q21, [sp, #64] > ?? 0x0000ffff998ab9b0:??? ldp??? q22, q23, [sp, #96] > ?? 0x0000ffff998ab9b4:??? ldp??? q24, q25, [sp, #128] > ?? 0x0000ffff998ab9b8:??? ldp??? q26, q28, [sp, #160] > ?? 0x0000ffff998ab9bc:??? ldp??? q29, q30, [sp, #192] > => 0x0000ffff998ab9c0:??? ldp??? q31, q31, [sp, #224] > ?? 0x0000ffff998ab9c4:??? ldp??? q1, q2, [sp], #256 > ?? 0x0000ffff998ab9c8:??? ldp??? x14, x17, [sp, #16] > ?? 0x0000ffff998ab9cc:??? ldp??? x10, x13, [sp], #32 > ?? 0x0000ffff998ab9d0:??? b??? 0xffff998aa718 > > It seems to be illegal to use the same register twice when loading into > a pair of registers. I verified that that was the problem, and not the > usage of zr (see below) that caused some weird encoding, by changing the > code to always generate stp/ldp with the same register: > > => 0x0000ffff757d22fc:??? ldp??? q20, q20, [sp, #32] ; Crash here as well > ?? 0x0000ffff757d2300:??? ldp??? q21, q21, [sp, #48] > ?? 0x0000ffff757d2304:??? ldp??? q22, q22, [sp, #64] > > The code that generates this instruction is MacroAssembler::push_fp, > which spills the necessary registers in pairs with stp/ldp calls. If the > number of registers to spill is odd it needs to deal with one of the > registers separately. This is done by adding a dummy register here: > > 2136 regs[count++] = zr->encoding_nocheck(); > 2137 count &= ~1; // Only push an even number of regs > > This scheme seems to work for the normal registers > (MacroAssembler::push), but the usage of zr seems dubious when we're > dealing with the fp/simd version of stp/ldp. > > My proposed patch replaces the stp/ldp for the odd numbered register > with the single-register versions: str/ldr. I make sure to keep the > stack 16 bytes aligned by still bumping 16 bytes, but skipping the > store/load to the second 8 bytes half. > > Note that right now MacroAssembler::push_fp is only used by ZGC. > > This fixes the crash. I've run this code through jtreg groups :tier1, > tier2, tier3, and an Oracle-internal stress suite without any new problems. > > The smallest reproducer I have is: > make -C ../build/fastdebug test TEST=test/jdk/java/util/concurrent/ > JTREG="JAVA_OPTIONS=-XX:+UseZGC" > > Does this look OK? > > Thanks, > StefanK > From aph at redhat.com Fri Jun 26 10:43:55 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Jun 2020 11:43:55 +0100 Subject: [aarch64-port-dev ] [15] RFR: 8248048: ZGC: AArch64: SIGILL in load barrier register spilling In-Reply-To: <5261f83d-46bf-e469-0e40-7b8b534d86c6@redhat.com> References: <5261f83d-46bf-e469-0e40-7b8b534d86c6@redhat.com> Message-ID: On 26/06/2020 11:05, Andrew Dinn wrote: > Yes, nice catch. zr is clearly the wrong choice here. In the context of > an FP register it ends up being interpreted as q31 which, as you show, > clashes when r31 is the last register in an odd register set. OK. I'm sure we've seen this bug years ago and fixed it. maybe the fix was never pushed, or maybe it was another instance of the same error. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stefan.karlsson at oracle.com Fri Jun 26 11:35:50 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 26 Jun 2020 13:35:50 +0200 Subject: [aarch64-port-dev ] [15] RFR: 8248048: ZGC: AArch64: SIGILL in load barrier register spilling In-Reply-To: <5261f83d-46bf-e469-0e40-7b8b534d86c6@redhat.com> References: <5261f83d-46bf-e469-0e40-7b8b534d86c6@redhat.com> Message-ID: <39e71fba-1b24-1c16-3747-49fad78842b0@oracle.com> Hi Andrew, On 2020-06-26 12:05, Andrew Dinn wrote: > Hi Stefan, > > Yes, nice catch. zr is clearly the wrong choice here. In the context of > an FP register it ends up being interpreted as q31 which, as you show, > clashes when r31 is the last register in an odd register set. > > Your fix looks ok to me (so count it as reviewed). Thanks for reviewing! > > Just for your interest, another alternative would be to continue to use > stpq instructions but replace zr with an fp register that is a) in the > save set but b) guaranteed to differ from the last register,-- the > obvious choice being regs[0]. That will work in all cases where count >= > 2 (well 3 actually since the problem only arises in odd cases). So, you > would still need to special case count == 0/1 and only add regs[0] to > the set after handling those cases. I was thinking along the same lines first. The problem with the count == 1 case made me look for another solution. > > I'm agnostic over which of these two is better as I don't think either a > stpq or a strq pre/post is preferable to the other. OK. Again, thanks for taking the time to think about the different ways to fix this. StefanK > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > > On 26/06/2020 09:50, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix a ZGC load barrier register spilling bug. >> >> https://cr.openjdk.java.net/~stefank/8248048/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8248048 >> >> The JVM crashed with an ILL_ILLOPC when executing this instruction in >> our load barrier stub: >> >> ? ldp q31, q31, [sp, #224] >> >> The entire load barrier stub: >> >> ?? 0x0000ffff998ab964:??? stp??? x10, x13, [sp, #-32]! >> ?? 0x0000ffff998ab968:??? stp??? x14, x17, [sp, #16] >> ?? 0x0000ffff998ab96c:??? stp??? q1, q2, [sp, #-256]! >> ?? 0x0000ffff998ab970:??? stp??? q3, q19, [sp, #32] >> ?? 0x0000ffff998ab974:??? stp??? q20, q21, [sp, #64] >> ?? 0x0000ffff998ab978:??? stp??? q22, q23, [sp, #96] >> ?? 0x0000ffff998ab97c:??? stp??? q24, q25, [sp, #128] >> ?? 0x0000ffff998ab980:??? stp??? q26, q28, [sp, #160] >> ?? 0x0000ffff998ab984:??? stp??? q29, q30, [sp, #192] >> ?? 0x0000ffff998ab988:??? stp??? q31, q31, [sp, #224] >> ?? 0x0000ffff998ab98c:??? sub??? x1, x10, #0x0 >> ?? 0x0000ffff998ab990:??? mov??? x0, x11 >> ?? 0x0000ffff998ab994:??? mov??? x8, #0xfc28??????????????? ??? // #64552 >> ?? 0x0000ffff998ab998:??? movk??? x8, #0xaf11, lsl #16 >> ?? 0x0000ffff998ab99c:??? movk??? x8, #0xffff, lsl #32 >> ?? 0x0000ffff998ab9a0:??? blr??? x8 ; branch into the JVM >> ?? 0x0000ffff998ab9a4:??? mov??? x11, x0 >> ?? 0x0000ffff998ab9a8:??? ldp??? q3, q19, [sp, #32] >> ?? 0x0000ffff998ab9ac:??? ldp??? q20, q21, [sp, #64] >> ?? 0x0000ffff998ab9b0:??? ldp??? q22, q23, [sp, #96] >> ?? 0x0000ffff998ab9b4:??? ldp??? q24, q25, [sp, #128] >> ?? 0x0000ffff998ab9b8:??? ldp??? q26, q28, [sp, #160] >> ?? 0x0000ffff998ab9bc:??? ldp??? q29, q30, [sp, #192] >> => 0x0000ffff998ab9c0:??? ldp??? q31, q31, [sp, #224] >> ?? 0x0000ffff998ab9c4:??? ldp??? q1, q2, [sp], #256 >> ?? 0x0000ffff998ab9c8:??? ldp??? x14, x17, [sp, #16] >> ?? 0x0000ffff998ab9cc:??? ldp??? x10, x13, [sp], #32 >> ?? 0x0000ffff998ab9d0:??? b??? 0xffff998aa718 >> >> It seems to be illegal to use the same register twice when loading into >> a pair of registers. I verified that that was the problem, and not the >> usage of zr (see below) that caused some weird encoding, by changing the >> code to always generate stp/ldp with the same register: >> >> => 0x0000ffff757d22fc:??? ldp??? q20, q20, [sp, #32] ; Crash here as well >> ?? 0x0000ffff757d2300:??? ldp??? q21, q21, [sp, #48] >> ?? 0x0000ffff757d2304:??? ldp??? q22, q22, [sp, #64] >> >> The code that generates this instruction is MacroAssembler::push_fp, >> which spills the necessary registers in pairs with stp/ldp calls. If the >> number of registers to spill is odd it needs to deal with one of the >> registers separately. This is done by adding a dummy register here: >> >> 2136 regs[count++] = zr->encoding_nocheck(); >> 2137 count &= ~1; // Only push an even number of regs >> >> This scheme seems to work for the normal registers >> (MacroAssembler::push), but the usage of zr seems dubious when we're >> dealing with the fp/simd version of stp/ldp. >> >> My proposed patch replaces the stp/ldp for the odd numbered register >> with the single-register versions: str/ldr. I make sure to keep the >> stack 16 bytes aligned by still bumping 16 bytes, but skipping the >> store/load to the second 8 bytes half. >> >> Note that right now MacroAssembler::push_fp is only used by ZGC. >> >> This fixes the crash. I've run this code through jtreg groups :tier1, >> tier2, tier3, and an Oracle-internal stress suite without any new problems. >> >> The smallest reproducer I have is: >> make -C ../build/fastdebug test TEST=test/jdk/java/util/concurrent/ >> JTREG="JAVA_OPTIONS=-XX:+UseZGC" >> >> Does this look OK? >> >> Thanks, >> StefanK >> > From stefan.karlsson at oracle.com Fri Jun 26 11:36:41 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 26 Jun 2020 13:36:41 +0200 Subject: [aarch64-port-dev ] [15] RFR: 8248048: ZGC: AArch64: SIGILL in load barrier register spilling In-Reply-To: References: <5261f83d-46bf-e469-0e40-7b8b534d86c6@redhat.com> Message-ID: <33b5349f-a4f0-01cb-855d-c00646a83c05@oracle.com> Thanks for looking at this. StefanK On 2020-06-26 12:43, Andrew Haley wrote: > On 26/06/2020 11:05, Andrew Dinn wrote: >> Yes, nice catch. zr is clearly the wrong choice here. In the context of >> an FP register it ends up being interpreted as q31 which, as you show, >> clashes when r31 is the last register in an odd register set. > > OK. > > I'm sure we've seen this bug years ago and fixed it. maybe the fix was > never pushed, or maybe it was another instance of the same error. > From dalibor.topic at oracle.com Fri Jun 26 12:18:25 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Jun 2020 14:18:25 +0200 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> Message-ID: On 25.06.2020 17:02, Mario Torre wrote: > On Thu, Jun 25, 2020 at 4:52 PM Dalibor Topic wrote: >> >> Hi Monica, >> >> it sounds as if you're making good progress on porting OpenJDK to a new >> opertaing system/cpu architecture combination. >> >> Typically such efforts would become with a porting Project of their own, >> just as the aarch64-linux port did back in 2013 [1], as that allows a >> community of developers across organizations to start to collaborate >> around a shared repository, mailing list, etc. on a specific porting task. > > Wouldn't it be easier to just consider this part of aarch64? Sure, if Monica prefers to work on her port within the mailing list, repositories etc. of the AArch64 Project, then that would work too, as long as the Project Lead is happy with that. Since there is no aarch64-port repository tracking jdk/jdk yet to host the port's changes in development (and stage it for a later merge into mainline once it's ready), I assume that's going to be the first step in that case. cheers, dalibor topic -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From aph at redhat.com Fri Jun 26 12:32:20 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Jun 2020 13:32:20 +0100 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> Message-ID: On 26/06/2020 13:18, Dalibor Topic wrote: > Since there is no aarch64-port repository tracking jdk/jdk yet to host > the port's changes in development (and stage it for a later merge into > mainline once it's ready), I assume that's going to be the first step in > that case. Given that the patches are simpler and smaller than many changes that just go into mainline, is there an actual reason for a new repo? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Fri Jun 26 13:07:19 2020 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 26 Jun 2020 15:07:19 +0200 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: <808bb99b-8792-ac4f-b439-6933092de96c@oracle.com> Message-ID: On 26.06.2020 14:32, Andrew Haley wrote: > On 26/06/2020 13:18, Dalibor Topic wrote: >> Since there is no aarch64-port repository tracking jdk/jdk yet to host >> the port's changes in development (and stage it for a later merge into >> mainline once it's ready), I assume that's going to be the first step in >> that case. > > Given that the patches are simpler and smaller than many changes that > just go into mainline, is there an actual reason for a new repo? I assume that there would be some work remaining to be done on the port, since it's not quite done yet. For example, the UI layer has not been ported, according to Microsoft, which means that the port is not really fully functional in its current state. [0] If that's just a matter of days, then sure, I fully understand that you may not want to add a new aarch64-port repo just for that. On the other hand, if there is a question mark over whether the port would become fully functional in the coming weeks or months, then trying to integrate the port-specific parts of it piecemeal into mainline before that the case ... would seem a bit premature to me. In that case, an aarch64-port specific jdk/jdk staging repo might be more useful. cheers, dalibor topic [0] https://www.reddit.com/r/java/comments/hf4ofr/announcing_openjdk_for_windows_10_on_arm/fvvmi8g/ -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From ci_notify at linaro.org Sun Jun 28 04:21:13 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 28 Jun 2020 04:21:13 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <502491578.5555.1593318074058.JavaMail.javamailuser@localhost> 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/jdk13/openjdk-jtreg-nightly-tests/summary/2020/179/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 1: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 2: aarch64/2019/nov/12 pass: 5,652 Build 3: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 4: aarch64/2019/nov/16 pass: 5,652 Build 5: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 6: aarch64/2019/dec/14 pass: 5,652 Build 7: aarch64/2020/jan/16 pass: 5,652 Build 8: aarch64/2020/may/28 pass: 5,669 Build 9: aarch64/2020/jun/02 pass: 5,677 Build 10: aarch64/2020/jun/09 pass: 5,691 Build 11: aarch64/2020/jun/18 pass: 5,696 Build 12: aarch64/2020/jun/20 pass: 5,695; fail: 1 Build 13: aarch64/2020/jun/23 pass: 5,695; fail: 1 Build 14: aarch64/2020/jun/27 pass: 5,696 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 1: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 2: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 3: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 4: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 5: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 6: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 7: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 8: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 Build 9: aarch64/2020/jun/02 pass: 8,686; fail: 509; error: 17 Build 10: aarch64/2020/jun/09 pass: 8,698; fail: 505; error: 16 Build 11: aarch64/2020/jun/18 pass: 8,712; fail: 495; error: 15 Build 12: aarch64/2020/jun/20 pass: 8,701; fail: 506; error: 16 Build 13: aarch64/2020/jun/23 pass: 8,691; fail: 517; error: 16 Build 14: aarch64/2020/jun/27 pass: 8,694; fail: 516; error: 16 6 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/08 pass: 3,964 Build 1: aarch64/2019/aug/10 pass: 3,964 Build 2: aarch64/2019/nov/12 pass: 3,964 Build 3: aarch64/2019/nov/14 pass: 3,964 Build 4: aarch64/2019/nov/16 pass: 3,964 Build 5: aarch64/2019/dec/03 pass: 3,964 Build 6: aarch64/2019/dec/14 pass: 3,964 Build 7: aarch64/2020/jan/16 pass: 3,964 Build 8: aarch64/2020/may/28 pass: 3,964 Build 9: aarch64/2020/jun/02 pass: 3,964 Build 10: aarch64/2020/jun/09 pass: 3,965 Build 11: aarch64/2020/jun/18 pass: 3,965 Build 12: aarch64/2020/jun/20 pass: 3,965 Build 13: aarch64/2020/jun/23 pass: 3,965 Build 14: aarch64/2020/jun/27 pass: 3,965 Previous results can be found here: http://openjdk.linaro.org/jdk13/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.54x Relative performance: Server critical-jOPS (nc): 8.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/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/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ 2020-06-04 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/154/results/ 2020-06-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/161/results/ 2020-06-20 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/170/results/ 2020-06-21 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/172/results/ 2020-06-25 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/175/results/ 2020-06-28 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/179/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From felix.yang at huawei.com Sun Jun 28 12:32:23 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sun, 28 Jun 2020 12:32:23 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield In-Reply-To: References: Message-ID: Hi Andrew, Sorry for the late reply. It's Dragon Boat Festival here in China. > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Wednesday, June 24, 2020 6:45 PM > To: Yangfei (Felix) ; hotspot-runtime- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: RFR(XS): 8248219: aarch64: missing memory barrier in > fast_storefield and fast_accessfield > > On 24/06/2020 10:38, Yangfei (Felix) wrote: > > Suggestions? > > Great catch! Thanks for the quick review :-) > Thanks for that, I completely agree. Please benchmark the two and unless > there is an advantage for the address dependency we'll go with LoadLoad. It I use a simple test [1] to exercise the read & write object field operation and run it in -Xint mode. Test result on our aarch64 platform show no advantage for the address dependency way. So I think I am OK to go with the LoadLoad way. Webrev: http://cr.openjdk.java.net/~fyang/8248219/webrev.00/ > looks like all of the ConstantPoolCacheEntry::set methods use > Atomic::release_store, so everything should be fine there. > > Did you also look to see if we need similar memory barriers elsewhere? Yes, I checked and only saw these two places. > We're going to need backports for all extant OpenJDK versions. Please let us > know if you can handle that too. Well, I think at least I can handle jdk8u-shenandoah, jdk11u and jdk/jdk. Felix [1] class TestCP { public int num; void run(int reps) { for (int i = 0; i < reps; i++) { num += i; } } public static void main(String[] args) throws Exception { int reps = Integer.parseInt(System.getProperty("repos")); TestCP t = new TestCP(); Long startTime = System.nanoTime(); t.run(reps); Long endTime = System.nanoTime(); System.out.println(endTime - startTime); } } From Yang.Zhang at arm.com Mon Jun 29 07:48:30 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Mon, 29 Jun 2020 07:48:30 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> Message-ID: Hi Andrew, 1. Instructions that can be matched with NEON instructions directly. MulVB, SqrtVF and AbsV have been merged into jdk master already. 2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. 3. Panama/Vector API specific instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again. Hi Sandhya, Could you please help to manual merge panama vectorIntrinsics/vector-unstable to jdk master? So that I can update this patch based on latest jdk master. Regards Yang -----Original Message----- From: Viswanathan, Sandhya Sent: Thursday, June 25, 2020 3:04 AM To: Yang Zhang ; Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes Hi Andrew/Yang, We couldn?t propose Vector API to target in time for JDK 15 and hoping to do so early in JDK 16 timeframe. The implementation reviews on other components have made good progress. We have so far ok to PPT from (runtime, shared compiler changes, x86 backend). Java API implementation review is in progress. I wanted to check with you both if we have a go ahead from aarch64 backed point of view. Best Regards, Sandhya -----Original Message----- From: hotspot-compiler-dev On Behalf Of Yang Zhang Sent: Tuesday, May 26, 2020 7:59 PM To: Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes > But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? The new instructions can be classified as: 1. Instructions that can be matched with NEON instructions directly. MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is in review [1]. 2. Instructions that Jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. May I have a new patch for these? 3. Panama/Vector API specific instructions Such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. Regards Yang [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html -----Original Message----- From: Andrew Haley Sent: Tuesday, May 26, 2020 4:25 PM To: Yang Zhang ; Paul Sandoz Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 25/05/2020 09:26, Yang Zhang wrote: > In jdk master, what we need to do is that writing m4 file for existing > vector instructions and placed them to a new file aarch64_neon.ad. > If no question, I will do it right away. I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement. But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? It'd help if this was possible. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Mon Jun 29 14:12:12 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 29 Jun 2020 16:12:12 +0200 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: <7148d08d-9510-9ad4-6b65-f833f6bacd37@oracle.com> Message-ID: I have now looked a bit more closely at the code. This is what I have found so far that attracted my eye. Please note that this is not a complete review. When you have a JEP and a test plan for how to verify these changes and make sure you do not break existing platforms, you can post a new RFR and I'll do a full review. * In flags-cflags.m4: You don't have to set? $1_CFLAGS_CPU_JVM="", an empty value is default for unspecified variables. * In flags-ldflags.m4: The stack size seems dependent on CPU_BITS, not the CPU arch. Please break out the -stack argument setting. Also, have you verified if -machine is really needed? The comment says that it's probably not; if it's just an old, unnecessary, precaution, we should probably remove it instead, to simplify the logic. * In platform.m4: These changes worries me. Neither of them were necessary for the linux-aarch64 port. But now you are changing the values for all aarch64 builds, not just windows-aarch64. Have you discovered a bug for linux-aarch64? Otherwise, these changes looks like they are going to break linux-aarch64. If you believe you need to modify these legacy values (which we'd rather move away from), please see if you have made changes elsewhere that can be resolved without resorting to adding new identifiers to the legacy values. * In basic.m4: Please move BASIC_EVAL_BUILD_DEVKIT_VARIABLE to be positioned next to BASIC_EVAL_DEVKIT_VARIABLE. * In toolchain_windows.m4: ?In TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL, if you know about the upcoming changes to file, why don't you add both the old and the new pattern to the test? ?In TOOLCHAIN_SETUP_MSVC_DLL, when it was just two instances, the code duplication could be accepted, but with three instances you need to generalize this and refactor out the changing platform part of the path only to the if statement. This applies, with some variation, to all four changed places. ?In the new TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS, you are doing ? AC_SUBST($1SYSROOT_CFLAGS) ? AC_SUBST($1SYSROOT_LDFLAGS) However, that seems superfluous, since it is already done by FLAGS_SETUP_SYSROOT_FLAGS in flags.m4. In fact, now that I checked this, I spotted that we *already* do an unnecessary AC_SUBST in FLAGS_POST_TOOLCHAIN for the build sysroot flags! :-o * In GensrcMisc,gmk: You are changing this for all users of the microsoft toolchain. I don't recall seeing any problems with this on x64. What version of Visual Studio are you using? Is this a limitation in the aarch64 version of CL.EXE, or does it apply to other platforms as well? Finally, if we do need to keep it, please use "-" as prefix for options (even though the microsoft tooling normally suggests the non-standard "/" -- this can all too easily be confused with path names.) * In GensrcAdlc.gmk: You are adding -D_WIN64=1 for all 64-bit platforms, i.e. also for x64, which has apparently worked fine until now without that define. What does the define do, and what is the rationale for not only adding it on your platform? * In jib-profiles.js: I appreciate the effort, but this file is basically just for Oracle-internal usage. If and when we will add support for building on windows-aarch64, we can update the file to work properly with the JIB tool. I am impressed that you manage to get cross-compilation working for Windows with that small amount of changes, though! If you had asked med beforehand, I'd have guessed that it would require more substantial changes. As you say, this is not something we have done before. /Magnus On 2020-06-24 23:33, Ludovic Henry wrote: > Hi Magnus, > > Happy to answer any question you have on the build system changes. > > A lot of the changes were due to the build system not supporting cross-compilation well when targetting the microsoft toolchain (it just never really had to support it). We had to go through a few hoops to remove as many of our own quick hacks, initially there just to get things building - like hardcoding the target being windows-aarch64 for example. > > Thank you for your review, > > -- > Ludovic > > ________________________________________ > From: Magnus Ihse Bursie > Sent: Wednesday, June 24, 2020 13:44 > To: Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev > Cc: openjdk-aarch64 > Subject: Re: OpenJDK extension to AArch64 and Windows > > Hi Monica, > > All build system changes must be sent to build-dev for review by the > build team, and you are doing quite a lot of build changes. (I'm cc:ing > build-dev now.) > > I did a quick scan and found some changes that looked odd enough to draw > my attention. > > I will need some time to fully understand what you are trying to > accomplish here, before I can give a full review. > > /Magnus > > > On 2020-06-24 18:40, Monica Beckwith wrote: >> Hello OpenJDK community, >> >> As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. >> >> Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) >> Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) >> Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. >> Umbrella Bug ID: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088&sdata=QXhd0zUDi2tqCLKiY%2F%2BKZzOzQNLirhq9WdxVAvogkqo%3D&reserved=0 >> Webrevs: >> `Webrev P1`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2F&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088&sdata=I4NuehXTkw1U6pChqT7Po0e4m8CvPTgucp0BtMN%2FFGk%3D&reserved=0 & >> `Webrev P2`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p2_new-target%2F&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002619088&sdata=UKxXrBjXUOM7Yw7qQ02TOujYnNp0W439FclIqoVs7mk%3D&reserved=0 >> >> The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 >> The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: >> * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, >> * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 >> * `os/windows` in `threadCritical_windows.cpp`, >> * Windbg support >> * `globalDefinitions_visCPP.hpp` in `share/utilities` >> * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). >> Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. >> >> I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. >> >> As a part of this project, we have also worked on two additional patches: >> * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247941&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=cH8q0LmaYoV%2BZfiunRHJYTyHz3kfm2RpnC5phc9Th8c%3D&reserved=0 >> * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. >> >> We welcome any feedback and comments from the community and are looking forward to working together. >> >> Regards, >> Monica >> >> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2Fwkload-status-on-Win%252BArm64.md&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=eeZ80gPlXEgqSDrpeL3WR%2FtzVPUr6nSBG%2FN3wqX4Lcc%3D&reserved=0 >> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FJTRegtests.md&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=jpSyNBfEvDpvw8AJvBqg8nGj4rb54xqW1YtJA07K2mI%3D&reserved=0 >> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FSPECJBB2015-test-matrices.md&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=QKYnn7jIwZGxeEdAjsMeUXY%2BvZBvZlLQSkP9s8vY8Cg%3D&reserved=0 >> [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Farm64-windows-abi-conventions%3Fview%3Dvs-2019%23integer-registers&data=02%7C01%7Cluhenry%40microsoft.com%7Ce9de9dbe05294132270c08d8187f7608%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637286283002629036&sdata=iy6RcczW2ipXYU%2B%2FD6mRRagLQxFjhZdCTqWcojeuqj0%3D&reserved=0 From aph at redhat.com Mon Jun 29 16:10:06 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 29 Jun 2020 17:10:06 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> Message-ID: <2acbcc99-8dd4-b8f1-5982-1d439953c416@redhat.com> The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- On 29/06/2020 08:48, Yang Zhang wrote: > 1. Instructions that can be matched with NEON instructions directly. > MulVB, SqrtVF and AbsV have been merged into jdk master already. > > 2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly. > Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. > > 3. Panama/Vector API specific instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. > These instructions cannot be moved into jdk master first because there isn't middle-end support. > > I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again. Thank you *very* much for your hard work. Appreciated! -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From luhenry at microsoft.com Mon Jun 29 23:20:46 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Mon, 29 Jun 2020 23:20:46 +0000 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: <7148d08d-9510-9ad4-6b65-f833f6bacd37@oracle.com> , Message-ID: The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. ---------------------------------------------------------------------- Hi Magnus, > I have now looked a bit more closely at the code. This is what I have > found so far that attracted my eye. Please note that this is not a > complete review. When you have a JEP and a test plan for how to verify > these changes and make sure you do not break existing platforms, you can > post a new RFR and I'll do a full review. Understood. I'll answer some of your remarks here, taking into account that Monica is currently working on the JEP. > * In flags-cflags.m4: You don't have to set $1_CFLAGS_CPU_JVM="", an > empty value is default for unspecified variables. I'll revert that. > * In flags-ldflags.m4: The stack size seems dependent on CPU_BITS, not > the CPU arch. Please break out the -stack argument setting. Also, have > you verified if -machine is really needed? The comment says that it's > probably not; if it's just an old, unnecessary, precaution, we should > probably remove it instead, to simplify the logic. I've verified that it works without the `-machine` bit for ARM64, I'll revert it. I'll also split the `-stack` arguments into 32 and 64 bits checks. > * In platform.m4: These changes worries me. Neither of them were > necessary for the linux-aarch64 port. But now you are changing the > values for all aarch64 builds, not just windows-aarch64. Have you > discovered a bug for linux-aarch64? Otherwise, these changes looks like > they are going to break linux-aarch64. If you believe you need to modify > these legacy values (which we'd rather move away from), please see if > you have made changes elsewhere that can be resolved without resorting > to adding new identifiers to the legacy values. It seems to have been a mistake in the early stage of our port, I'll revert it. > * In basic.m4: Please move BASIC_EVAL_BUILD_DEVKIT_VARIABLE to be > positioned next to BASIC_EVAL_DEVKIT_VARIABLE. Ok > * In toolchain_windows.m4: > In TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL, if you know about the upcoming > changes to file, why don't you add both the old and the new pattern to > the test? The comment is slightly inaccurate as it won't break, it is just not going to be as precise as it could be. The future version of file(1) will still return `PE32+ executable` (like it does for x86_64 executables), but it will also return something specifically for aarch64. > In TOOLCHAIN_SETUP_MSVC_DLL, when it was just two instances, the code > duplication could be accepted, but with three instances you need to > generalize this and refactor out the changing platform part of the path > only to the if statement. This applies, with some variation, to all four > changed places. Ok, I'll refactor by adding a variable containing x86, x64 or arm64. > In the new TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS, you are doing > AC_SUBST($1SYSROOT_CFLAGS) > AC_SUBST($1SYSROOT_LDFLAGS) > > However, that seems superfluous, since it is already done by > FLAGS_SETUP_SYSROOT_FLAGS in flags.m4. In fact, now that I checked this, > I spotted that we *already* do an unnecessary AC_SUBST in > FLAGS_POST_TOOLCHAIN for the build sysroot flags! :-o This part is what caused the most problems in getting cross-compilation with MSVC working, and the current solution is the simplest changeset I could come up with. I've to admit that this part stretched my understanding of the build system, and thus I'm not even sure what I propose as good as it can be. FLAGS_SETUP_SYSROOT_FLAGS for example, only sets $1SYSROOT_CFLAGS and $1SYSROOT_LDLAGS to a valid value on non-"microsoft" toolchain. That is because at the time FLAGS_PRE_TOOLCHAIN is called, the "microsoft" toolchain has not been initialized yet. It only gets properly initialized once TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is called. > * In GensrcMisc,gmk: You are changing this for all users of the > microsoft toolchain. I don't recall seeing any problems with this on > x64. What version of Visual Studio are you using? Is this a limitation > in the aarch64 version of CL.EXE, or does it apply to other platforms as > well? Finally, if we do need to keep it, please use "-" as prefix for > options (even though the microsoft tooling normally suggests the > non-standard "/" -- this can all too easily be confused with path names.) Ok. > * In GensrcAdlc.gmk: You are adding -D_WIN64=1 for all 64-bit platforms, > i.e. also for x64, which has apparently worked fine until now without > that define. What does the define do, and what is the rationale for not > only adding it on your platform? It is the default define used on Windows-compatible codebases to specify whether it's targetting a 64-bit platform or not. We need to define it to have Windows-specific code in the existing aarch64 code of the OpenJDK. It makes sense to define it for x64 as well as arm64, but I agree it's not a requirement. > * In jib-profiles.js: I appreciate the effort, but this file is > basically just for Oracle-internal usage. If and when we will add > support for building on windows-aarch64, we can update the file to work > properly with the JIB tool. Ok. > I am impressed that you manage to get cross-compilation working for > Windows with that small amount of changes, though! If you had asked med > beforehand, I'd have guessed that it would require more substantial > changes. As you say, this is not something we have done before. The meat of the change is in `toolchain.m4` with the support functions in `toolchain_windows.m4`. It is where I iterated the most to find the right encapsulation across the different components relying on it - and I've to say it wasn't straightforward to understand how all the pieces fit together. I'd be happy to work out with you a better way to do the foundational work of supporting cross-compilation with the Microsoft toolchain, just le me know how you'd like to proceed. Thank you, -- Ludovic ________________________________________ From: Magnus Ihse Bursie Sent: Monday, June 29, 2020 07:12 To: Ludovic Henry; Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev Cc: openjdk-aarch64 Subject: Re: OpenJDK extension to AArch64 and Windows I have now looked a bit more closely at the code. This is what I have found so far that attracted my eye. Please note that this is not a complete review. When you have a JEP and a test plan for how to verify these changes and make sure you do not break existing platforms, you can post a new RFR and I'll do a full review. * In flags-cflags.m4: You don't have to set $1_CFLAGS_CPU_JVM="", an empty value is default for unspecified variables. * In flags-ldflags.m4: The stack size seems dependent on CPU_BITS, not the CPU arch. Please break out the -stack argument setting. Also, have you verified if -machine is really needed? The comment says that it's probably not; if it's just an old, unnecessary, precaution, we should probably remove it instead, to simplify the logic. * In platform.m4: These changes worries me. Neither of them were necessary for the linux-aarch64 port. But now you are changing the values for all aarch64 builds, not just windows-aarch64. Have you discovered a bug for linux-aarch64? Otherwise, these changes looks like they are going to break linux-aarch64. If you believe you need to modify these legacy values (which we'd rather move away from), please see if you have made changes elsewhere that can be resolved without resorting to adding new identifiers to the legacy values. * In basic.m4: Please move BASIC_EVAL_BUILD_DEVKIT_VARIABLE to be positioned next to BASIC_EVAL_DEVKIT_VARIABLE. * In toolchain_windows.m4: In TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL, if you know about the upcoming changes to file, why don't you add both the old and the new pattern to the test? In TOOLCHAIN_SETUP_MSVC_DLL, when it was just two instances, the code duplication could be accepted, but with three instances you need to generalize this and refactor out the changing platform part of the path only to the if statement. This applies, with some variation, to all four changed places. In the new TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS, you are doing AC_SUBST($1SYSROOT_CFLAGS) AC_SUBST($1SYSROOT_LDFLAGS) However, that seems superfluous, since it is already done by FLAGS_SETUP_SYSROOT_FLAGS in flags.m4. In fact, now that I checked this, I spotted that we *already* do an unnecessary AC_SUBST in FLAGS_POST_TOOLCHAIN for the build sysroot flags! :-o * In GensrcMisc,gmk: You are changing this for all users of the microsoft toolchain. I don't recall seeing any problems with this on x64. What version of Visual Studio are you using? Is this a limitation in the aarch64 version of CL.EXE, or does it apply to other platforms as well? Finally, if we do need to keep it, please use "-" as prefix for options (even though the microsoft tooling normally suggests the non-standard "/" -- this can all too easily be confused with path names.) * In GensrcAdlc.gmk: You are adding -D_WIN64=1 for all 64-bit platforms, i.e. also for x64, which has apparently worked fine until now without that define. What does the define do, and what is the rationale for not only adding it on your platform? * In jib-profiles.js: I appreciate the effort, but this file is basically just for Oracle-internal usage. If and when we will add support for building on windows-aarch64, we can update the file to work properly with the JIB tool. I am impressed that you manage to get cross-compilation working for Windows with that small amount of changes, though! If you had asked med beforehand, I'd have guessed that it would require more substantial changes. As you say, this is not something we have done before. /Magnus On 2020-06-24 23:33, Ludovic Henry wrote: > Hi Magnus, > > Happy to answer any question you have on the build system changes. > > A lot of the changes were due to the build system not supporting cross-compilation well when targetting the microsoft toolchain (it just never really had to support it). We had to go through a few hoops to remove as many of our own quick hacks, initially there just to get things building - like hardcoding the target being windows-aarch64 for example. > > Thank you for your review, > > -- > Ludovic > > ________________________________________ > From: Magnus Ihse Bursie > Sent: Wednesday, June 24, 2020 13:44 > To: Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev > Cc: openjdk-aarch64 > Subject: Re: OpenJDK extension to AArch64 and Windows > > Hi Monica, > > All build system changes must be sent to build-dev for review by the > build team, and you are doing quite a lot of build changes. (I'm cc:ing > build-dev now.) > > I did a quick scan and found some changes that looked odd enough to draw > my attention. > > I will need some time to fully understand what you are trying to > accomplish here, before I can give a full review. > > /Magnus > > > On 2020-06-24 18:40, Monica Beckwith wrote: >> Hello OpenJDK community, >> >> As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. >> >> Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) >> Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) >> Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. >> Umbrella Bug ID: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978180090&sdata=ntF3w0wtSa2%2BbN9ikZeJc3OZTYgWsjbvQxqudBSa%2B4I%3D&reserved=0 >> Webrevs: >> `Webrev P1`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2F&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978180090&sdata=PG7oj%2FDCporqoF96ocIxidkAlTOJYs6gZwfGRWDnhYE%3D&reserved=0 & >> `Webrev P2`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p2_new-target%2F&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=Br9TkpMvgiQyN1xop6IE2CA%2BZCqIVDpEzw%2Bx6XnZrmg%3D&reserved=0 >> >> The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 >> The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: >> * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, >> * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 >> * `os/windows` in `threadCritical_windows.cpp`, >> * Windbg support >> * `globalDefinitions_visCPP.hpp` in `share/utilities` >> * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). >> Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. >> >> I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. >> >> As a part of this project, we have also worked on two additional patches: >> * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247941&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=95tmUIxEmDJP0AZ2GpxhCkII7SefU4%2BRRkkae0fRdRA%3D&reserved=0 >> * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. >> >> We welcome any feedback and comments from the community and are looking forward to working together. >> >> Regards, >> Monica >> >> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2Fwkload-status-on-Win%252BArm64.md&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=RSeWSplQ%2F7t%2Fq8aaZwjVolXBCWsp0dNfebeDddjBvUM%3D&reserved=0 >> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FJTRegtests.md&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=6q37AVqwlxpXl%2BV0nTLp6h24n3AuuEmbQod5tKnwrhs%3D&reserved=0 >> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FSPECJBB2015-test-matrices.md&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=AXkooXGVJMqzeBn29ZUeabrW8mzfFfJrFcoHkfRSVMQ%3D&reserved=0 >> [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Farm64-windows-abi-conventions%3Fview%3Dvs-2019%23integer-registers&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=aJN9ocV4DF0d3bKP74E%2FkoNgq336BTXd8%2BQPgJzKDaU%3D&reserved=0 From magnus.ihse.bursie at oracle.com Tue Jun 30 09:39:30 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 30 Jun 2020 11:39:30 +0200 Subject: [aarch64-port-dev ] OpenJDK extension to AArch64 and Windows In-Reply-To: References: <7148d08d-9510-9ad4-6b65-f833f6bacd37@oracle.com> < Message-ID: <3c43d27c-e3dd-63f3-46ac-86efa015a0ac@oracle.com> On 2020-06-30 01:20, Ludovic Henry wrote: > Hi Magnus, > >> I have now looked a bit more closely at the code. This is what I have >> found so far that attracted my eye. Please note that this is not a >> complete review. When you have a JEP and a test plan for how to verify >> these changes and make sure you do not break existing platforms, you can >> post a new RFR and I'll do a full review. > Understood. I'll answer some of your remarks here, taking into account that Monica is currently working on the JEP. > >> * In flags-cflags.m4: You don't have to set $1_CFLAGS_CPU_JVM="", an >> empty value is default for unspecified variables. > I'll revert that. > >> * In flags-ldflags.m4: The stack size seems dependent on CPU_BITS, not >> the CPU arch. Please break out the -stack argument setting. Also, have >> you verified if -machine is really needed? The comment says that it's >> probably not; if it's just an old, unnecessary, precaution, we should >> probably remove it instead, to simplify the logic. > I've verified that it works without the `-machine` bit for ARM64, I'll revert it. I'll also split the `-stack` arguments into 32 and 64 bits checks. Great! If you can test if -machine can be removed for the other platforms as well, I'd be grateful. Old code which adds special cases, and besides that is flagged as "probably not needed", should really be cleaned away. > >> * In platform.m4: These changes worries me. Neither of them were >> necessary for the linux-aarch64 port. But now you are changing the >> values for all aarch64 builds, not just windows-aarch64. Have you >> discovered a bug for linux-aarch64? Otherwise, these changes looks like >> they are going to break linux-aarch64. If you believe you need to modify >> these legacy values (which we'd rather move away from), please see if >> you have made changes elsewhere that can be resolved without resorting >> to adding new identifiers to the legacy values. > It seems to have been a mistake in the early stage of our port, I'll revert it. I see. Good. > >> * In basic.m4: Please move BASIC_EVAL_BUILD_DEVKIT_VARIABLE to be >> positioned next to BASIC_EVAL_DEVKIT_VARIABLE. > Ok > >> * In toolchain_windows.m4: >> In TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL, if you know about the upcoming >> changes to file, why don't you add both the old and the new pattern to >> the test? > The comment is slightly inaccurate as it won't break, it is just not going to be as precise as it could be. The future version of file(1) will still return `PE32+ executable` (like it does for x86_64 executables), but it will also return something specifically for aarch64. I see. Since we will need to support old versions of file for a long time to come, the upcoming fix is really not relevant for us then. We'll just have to accept the fact that the check is not really useful for aarch64. Perhaps you can adjust the wording of the comment, so it's clear that it's irrelevant if the bug fix is present or not in the version of file that the user has. > >> In TOOLCHAIN_SETUP_MSVC_DLL, when it was just two instances, the code >> duplication could be accepted, but with three instances you need to >> generalize this and refactor out the changing platform part of the path >> only to the if statement. This applies, with some variation, to all four >> changed places. > Ok, I'll refactor by adding a variable containing x86, x64 or arm64. Perfect! > >> In the new TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS, you are doing >> AC_SUBST($1SYSROOT_CFLAGS) >> AC_SUBST($1SYSROOT_LDFLAGS) >> >> However, that seems superfluous, since it is already done by >> FLAGS_SETUP_SYSROOT_FLAGS in flags.m4. In fact, now that I checked this, >> I spotted that we *already* do an unnecessary AC_SUBST in >> FLAGS_POST_TOOLCHAIN for the build sysroot flags! :-o > This part is what caused the most problems in getting cross-compilation with MSVC working, and the current solution is the simplest changeset I could come up with. I've to admit that this part stretched my understanding of the build system, and thus I'm not even sure what I propose as good as it can be. > > FLAGS_SETUP_SYSROOT_FLAGS for example, only sets $1SYSROOT_CFLAGS and $1SYSROOT_LDLAGS to a valid value on non-"microsoft" toolchain. That is because at the time FLAGS_PRE_TOOLCHAIN is called, the "microsoft" toolchain has not been initialized yet. It only gets properly initialized once TOOLCHAIN_SETUP_VISUAL_STUDIO_ENV is called. I understand if it's confusing. Autoconf is a beast to work with; I've done that for more years than I want to think about, and I still don't understand it fully. However, in this case, it's "easy". The call to AC_SUBST only flags a variable for export. The actual exportation to spec.gmk is done at the end of the configure script, with the call to AC_OUTPUT, and the value exported is the value the variables has at that point. So the order of execution does not matter here. This also means that it is not an error to call AC_SUBST multiple times, but it is a style issue. On the other hand, we try to follow the pattern of "create variable, call AC_SUBST" for our own sanity. Conceptually, the microsoft toolchain setup is almost equivalent to FLAGS_PRE_TOOLCHAIN. That is, the result should be that we have a set of "sysroot" (think "global") flags that should always be added. I have a patch in the works that changes this somewhat, and makes the dependencies clearer. > >> * In GensrcMisc,gmk: You are changing this for all users of the >> microsoft toolchain. I don't recall seeing any problems with this on >> x64. What version of Visual Studio are you using? Is this a limitation >> in the aarch64 version of CL.EXE, or does it apply to other platforms as >> well? Finally, if we do need to keep it, please use "-" as prefix for >> options (even though the microsoft tooling normally suggests the >> non-standard "/" -- this can all too easily be confused with path names.) > Ok. > >> * In GensrcAdlc.gmk: You are adding -D_WIN64=1 for all 64-bit platforms, >> i.e. also for x64, which has apparently worked fine until now without >> that define. What does the define do, and what is the rationale for not >> only adding it on your platform? > It is the default define used on Windows-compatible codebases to specify whether it's targetting a 64-bit platform or not. We need to define it to have Windows-specific code in the existing aarch64 code of the OpenJDK. It makes sense to define it for x64 as well as arm64, but I agree it's not a requirement. Ok, sounds good. Keep it as it is then. > >> * In jib-profiles.js: I appreciate the effort, but this file is >> basically just for Oracle-internal usage. If and when we will add >> support for building on windows-aarch64, we can update the file to work >> properly with the JIB tool. > Ok. > >> I am impressed that you manage to get cross-compilation working for >> Windows with that small amount of changes, though! If you had asked med >> beforehand, I'd have guessed that it would require more substantial >> changes. As you say, this is not something we have done before. > The meat of the change is in `toolchain.m4` with the support functions in `toolchain_windows.m4`. It is where I iterated the most to find the right encapsulation across the different components relying on it - and I've to say it wasn't straightforward to understand how all the pieces fit together. I'd be happy to work out with you a better way to do the foundational work of supporting cross-compilation with the Microsoft toolchain, just le me know how you'd like to proceed. I think you have found more or less exactly the right spots to inject the support for cross-compilation. I think I'd ended up with something similar if I was tasked with getting cross-compilation work on Windows. Maybe there's room for more generalisations, but it's a bit hard to say at this moment. I think things might clear up a bit more when I get the "unified winenv" patch in. It makes the sysroot cflag handling a bit more transparent. /Magnus > > Thank you, > > -- > Ludovic > > ________________________________________ > From: Magnus Ihse Bursie > Sent: Monday, June 29, 2020 07:12 > To: Ludovic Henry; Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev > Cc: openjdk-aarch64 > Subject: Re: OpenJDK extension to AArch64 and Windows > > I have now looked a bit more closely at the code. This is what I have > found so far that attracted my eye. Please note that this is not a > complete review. When you have a JEP and a test plan for how to verify > these changes and make sure you do not break existing platforms, you can > post a new RFR and I'll do a full review. > > * In flags-cflags.m4: You don't have to set $1_CFLAGS_CPU_JVM="", an > empty value is default for unspecified variables. > > * In flags-ldflags.m4: The stack size seems dependent on CPU_BITS, not > the CPU arch. Please break out the -stack argument setting. Also, have > you verified if -machine is really needed? The comment says that it's > probably not; if it's just an old, unnecessary, precaution, we should > probably remove it instead, to simplify the logic. > > * In platform.m4: These changes worries me. Neither of them were > necessary for the linux-aarch64 port. But now you are changing the > values for all aarch64 builds, not just windows-aarch64. Have you > discovered a bug for linux-aarch64? Otherwise, these changes looks like > they are going to break linux-aarch64. If you believe you need to modify > these legacy values (which we'd rather move away from), please see if > you have made changes elsewhere that can be resolved without resorting > to adding new identifiers to the legacy values. > > * In basic.m4: Please move BASIC_EVAL_BUILD_DEVKIT_VARIABLE to be > positioned next to BASIC_EVAL_DEVKIT_VARIABLE. > > * In toolchain_windows.m4: > In TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL, if you know about the upcoming > changes to file, why don't you add both the old and the new pattern to > the test? > > In TOOLCHAIN_SETUP_MSVC_DLL, when it was just two instances, the code > duplication could be accepted, but with three instances you need to > generalize this and refactor out the changing platform part of the path > only to the if statement. This applies, with some variation, to all four > changed places. > > In the new TOOLCHAIN_SETUP_VISUAL_STUDIO_SYSROOT_FLAGS, you are doing > AC_SUBST($1SYSROOT_CFLAGS) > AC_SUBST($1SYSROOT_LDFLAGS) > > However, that seems superfluous, since it is already done by > FLAGS_SETUP_SYSROOT_FLAGS in flags.m4. In fact, now that I checked this, > I spotted that we *already* do an unnecessary AC_SUBST in > FLAGS_POST_TOOLCHAIN for the build sysroot flags! :-o > > * In GensrcMisc,gmk: You are changing this for all users of the > microsoft toolchain. I don't recall seeing any problems with this on > x64. What version of Visual Studio are you using? Is this a limitation > in the aarch64 version of CL.EXE, or does it apply to other platforms as > well? Finally, if we do need to keep it, please use "-" as prefix for > options (even though the microsoft tooling normally suggests the > non-standard "/" -- this can all too easily be confused with path names.) > > * In GensrcAdlc.gmk: You are adding -D_WIN64=1 for all 64-bit platforms, > i.e. also for x64, which has apparently worked fine until now without > that define. What does the define do, and what is the rationale for not > only adding it on your platform? > > * In jib-profiles.js: I appreciate the effort, but this file is > basically just for Oracle-internal usage. If and when we will add > support for building on windows-aarch64, we can update the file to work > properly with the JIB tool. > > I am impressed that you manage to get cross-compilation working for > Windows with that small amount of changes, though! If you had asked med > beforehand, I'd have guessed that it would require more substantial > changes. As you say, this is not something we have done before. > > /Magnus > > > > On 2020-06-24 23:33, Ludovic Henry wrote: >> Hi Magnus, >> >> Happy to answer any question you have on the build system changes. >> >> A lot of the changes were due to the build system not supporting cross-compilation well when targetting the microsoft toolchain (it just never really had to support it). We had to go through a few hoops to remove as many of our own quick hacks, initially there just to get things building - like hardcoding the target being windows-aarch64 for example. >> >> Thank you for your review, >> >> -- >> Ludovic >> >> ________________________________________ >> From: Magnus Ihse Bursie >> Sent: Wednesday, June 24, 2020 13:44 >> To: Monica Beckwith; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; build-dev >> Cc: openjdk-aarch64 >> Subject: Re: OpenJDK extension to AArch64 and Windows >> >> Hi Monica, >> >> All build system changes must be sent to build-dev for review by the >> build team, and you are doing quite a lot of build changes. (I'm cc:ing >> build-dev now.) >> >> I did a quick scan and found some changes that looked odd enough to draw >> my attention. >> >> I will need some time to fully understand what you are trying to >> accomplish here, before I can give a full review. >> >> /Magnus >> >> >> On 2020-06-24 18:40, Monica Beckwith wrote: >>> Hello OpenJDK community, >>> >>> As the project lead here @Microsoft, I am pleased to share that we have been working towards a Windows addition to the OpenJDK AArch64 port. We are very thankful to all that have contributed to the Linux+aarch64 and Windows+x86-64. Both these codebases came to our rescue on numerous occasions. >>> >>> Support status: We have successfully ported C2 and can build the server release (cross-compiled environment) >>> Test coverage: C2 + ParallelGC (No AOT, JVMCI, ZGC, ShenandoahGC, G1GC) >>> Tests and benchmarks covered [1]: JTReg [2], JCStress, jmh-jdk-microbenchmarks, SPEC SERT, SPECJBB2015 [3], SPEC JVM2008, Scimark2, SPEC JBB2005. >>> Umbrella Bug ID: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978180090&sdata=ntF3w0wtSa2%2BbN9ikZeJc3OZTYgWsjbvQxqudBSa%2B4I%3D&reserved=0 >>> Webrevs: >>> `Webrev P1`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p1_llp64%2F&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978180090&sdata=PG7oj%2FDCporqoF96ocIxidkAlTOJYs6gZwfGRWDnhYE%3D&reserved=0 & >>> `Webrev P2`: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2Fwinarm64_p2_new-target%2F&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=Br9TkpMvgiQyN1xop6IE2CA%2BZCqIVDpEzw%2Bx6XnZrmg%3D&reserved=0 >>> >>> The first patch `Webrev P1` (patch 1 aka P1 in our tests) helps integrate support for Windows (LLP64) on Linux + AArch64 >>> The second patch `Webrev P2` (patch 2 aka P2 in our tests) adds the 'windows-aarch64' support in `os_cpu`. We also had to modify shared code, and I am highlighting a few details here: >>> * In windows_x86 such as the `get_frame_at_stack_banging_point` in `os_windows_x86.cpp`, >>> * In `os/windows os_windows.cpp` to make it aware of Windows + Arm64 >>> * `os/windows` in `threadCritical_windows.cpp`, >>> * Windbg support >>> * `globalDefinitions_visCPP.hpp` in `share/utilities` >>> * We also added Vectored Exception Handling (VEH) to P2, as it is a requirement on Windows + Arm64 (due to ABI specifications). >>> Also, in `Webrev P2`, you will find that we have made some significant changes to `cpu/aarch64` around register usage since on Windows + Arm64, register R18 points to TEB [4]. We have discussed this with Andrew Haley and Andrew Dinn, and they are helping us with a cleaner implementation of the same. Their constant support and guidance have humbled me. >>> >>> I'd also like to recognize the great work done by Ludovic Henry (our resident runtime expert) in driving the C2 support and by Bernhard Urban-Forster, (who recently joined our team) in helping expand the coverage to G1 GC. >>> >>> As a part of this project, we have also worked on two additional patches: >>> * Expanding VEH on Windows to x86-64 (patch 3 aka P3 in our tests). Details here: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8247941&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=95tmUIxEmDJP0AZ2GpxhCkII7SefU4%2BRRkkae0fRdRA%3D&reserved=0 >>> * Improvements in the shared cross-platform code on Windows (patch 4 aka P4 in our tests) - We will send out a separate patch soon. >>> >>> We welcome any feedback and comments from the community and are looking forward to working together. >>> >>> Regards, >>> Monica >>> >>> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2Fwkload-status-on-Win%252BArm64.md&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=RSeWSplQ%2F7t%2Fq8aaZwjVolXBCWsp0dNfebeDddjBvUM%3D&reserved=0 >>> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FJTRegtests.md&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=6q37AVqwlxpXl%2BV0nTLp6h24n3AuuEmbQod5tKnwrhs%3D&reserved=0 >>> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fopenjdk-aarch64%2Fblob%2Fmaster%2FSPECJBB2015-test-matrices.md&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=AXkooXGVJMqzeBn29ZUeabrW8mzfFfJrFcoHkfRSVMQ%3D&reserved=0 >>> [4] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fcpp%2Fbuild%2Farm64-windows-abi-conventions%3Fview%3Dvs-2019%23integer-registers&data=02%7C01%7Cluhenry%40microsoft.com%7Cebbae1ef103e4cb5b2cf08d81c36ccca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290368978190084&sdata=aJN9ocV4DF0d3bKP74E%2FkoNgq336BTXd8%2BQPgJzKDaU%3D&reserved=0 From gnu.andrew at redhat.com Tue Jun 30 17:38:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 30 Jun 2020 18:38:16 +0100 Subject: [aarch64-port-dev ] RFR: Shenandoah integration 2020-06-25 In-Reply-To: References: Message-ID: On 25/06/2020 14:13, Roman Kennke wrote: > I'd like to integrate 2 important backports from shenandoah/jdk8 to > aarch64-port/jdk8u-shenandoah: > > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2020-06-25/webrev.00/ > > It only touches Shenandoah code. > > Testing: several nightly runs of our CI, including > hotspot_gc_shenandoah, specjvm, CTW tests and jcstress. > > Can I please get a review? > > Thanks, > Roman > I don't see a problem with the changes, but it is very late for 8u262 now (it froze upstream at the end of last week). Let me push the b08 & b09 merges first and then I'm ok with this being pushed on top and tagged. That has to be the last for 8u262 though, as I'll be moving to work on the repos in private over the next few days. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rkennke at redhat.com Tue Jun 30 18:07:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 30 Jun 2020 20:07:31 +0200 Subject: [aarch64-port-dev ] RFR: Shenandoah integration 2020-06-25 In-Reply-To: References: Message-ID: <1b5c7f92372eb9f93b73b049682cb8982a6ddb67.camel@redhat.com> Ping me when it's ready to accept the changes, ok? Thanks, Roman On Tue, 2020-06-30 at 18:38 +0100, Andrew Hughes wrote: > On 25/06/2020 14:13, Roman Kennke wrote: > > I'd like to integrate 2 important backports from shenandoah/jdk8 to > > aarch64-port/jdk8u-shenandoah: > > > > http://cr.openjdk.java.net/~rkennke/aarch64-shenandoah-integration-2020-06-25/webrev.00/ > > > > It only touches Shenandoah code. > > > > Testing: several nightly runs of our CI, including > > hotspot_gc_shenandoah, specjvm, CTW tests and jcstress. > > > > Can I please get a review? > > > > Thanks, > > Roman > > > > I don't see a problem with the changes, but it is very late for 8u262 > now (it froze upstream at the end of last week). > > Let me push the b08 & b09 merges first and then I'm ok with this > being > pushed on top and tagged. That has to be the last for 8u262 though, > as > I'll be moving to work on the repos in private over the next few > days. > > Thanks, From sandhya.viswanathan at intel.com Tue Jun 30 18:56:34 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Tue, 30 Jun 2020 18:56:34 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> Message-ID: Hi Yang, I have merged vectorIntrinsics with changes from panama/default. Hope this helps. Best Regards, Sandhya -----Original Message----- From: Yang Zhang Sent: Monday, June 29, 2020 12:49 AM To: Viswanathan, Sandhya ; Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes Hi Andrew, 1. Instructions that can be matched with NEON instructions directly. MulVB, SqrtVF and AbsV have been merged into jdk master already. 2. Instructions that jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. 3. Panama/Vector API specific instructions such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send it again. Hi Sandhya, Could you please help to manual merge panama vectorIntrinsics/vector-unstable to jdk master? So that I can update this patch based on latest jdk master. Regards Yang -----Original Message----- From: Viswanathan, Sandhya Sent: Thursday, June 25, 2020 3:04 AM To: Yang Zhang ; Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes Hi Andrew/Yang, We couldn?t propose Vector API to target in time for JDK 15 and hoping to do so early in JDK 16 timeframe. The implementation reviews on other components have made good progress. We have so far ok to PPT from (runtime, shared compiler changes, x86 backend). Java API implementation review is in progress. I wanted to check with you both if we have a go ahead from aarch64 backed point of view. Best Regards, Sandhya -----Original Message----- From: hotspot-compiler-dev On Behalf Of Yang Zhang Sent: Tuesday, May 26, 2020 7:59 PM To: Andrew Haley ; Paul Sandoz Cc: nd ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes > But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? The new instructions can be classified as: 1. Instructions that can be matched with NEON instructions directly. MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is in review [1]. 2. Instructions that Jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. May I have a new patch for these? 3. Panama/Vector API specific instructions Such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. Regards Yang [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html -----Original Message----- From: Andrew Haley Sent: Tuesday, May 26, 2020 4:25 PM To: Yang Zhang ; Paul Sandoz Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 25/05/2020 09:26, Yang Zhang wrote: > In jdk master, what we need to do is that writing m4 file for existing > vector instructions and placed them to a new file aarch64_neon.ad. > If no question, I will do it right away. I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement. But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? It'd help if this was possible. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671