From ci_notify at linaro.org Wed Oct 2 18:06:33 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 2 Oct 2019 18:06:33 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2087 Failure Message-ID: <433993823.4637.1570039594317.JavaMail.javamailuser@localhost> OpenJDK AArch64 jdk/jdk build status is Failure Build details - https://ci.linaro.org/job/jdkX-ci-build/2087/ Changes - erikj: 0aa2cdae73cea2bf7c91b648b1a93ce8106f4b38 - make/autoconf/version-numbers - make/conf/jib-profiles.js --"8231505: Bump required boot jdk version to 13 Reviewed-by: darcy, ihse " Build output - Creating jdk.internal.vm.ci.jmod Creating jdk.internal.opt.jmod Creating jdk.internal.vm.compiler.jmod Creating jdk.internal.vm.compiler.management.jmod Creating jdk.jartool.jmod Creating jdk.javadoc.jmod Creating jdk.jcmd.jmod Creating jdk.jconsole.jmod Creating jdk.jdeps.jmod Creating jdk.jdi.jmod Creating jdk.jdwp.agent.jmod Creating jdk.jfr.jmod Creating jdk.jsobject.jmod Creating jdk.jshell.jmod Creating jdk.jstatd.jmod Creating jdk.localedata.jmod Creating jdk.management.jmod Creating jdk.management.agent.jmod Creating jdk.management.jfr.jmod Creating jdk.naming.dns.jmod Creating jdk.naming.rmi.jmod Creating jdk.net.jmod Creating jdk.nio.mapmode.jmod Creating jdk.pack.jmod Creating jdk.rmic.jmod Creating jdk.scripting.nashorn.jmod Creating jdk.scripting.nashorn.shell.jmod Creating jdk.sctp.jmod Creating jdk.security.auth.jmod Creating jdk.security.jgss.jmod Creating jdk.unsupported.jmod Creating jdk.unsupported.desktop.jmod Creating jdk.xml.dom.jmod Creating jdk.zipfs.jmod Compiling 3 files for BUILD_DEMO_CodePointIM Creating interim jimage Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Compiling 30 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 4 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Compiling 8 files for BUILD_DEMO_TableExample Updating support/demos/image/jfc/TableExample/src.zip Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar Creating support/demos/image/jfc/Metalworks/Metalworks.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Notepad/Notepad.jar Creating support/demos/image/jfc/Stylepad/Stylepad.jar Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Compiling 1 files for CLASSLIST_JAR Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar Creating support/classlist.jar Creating jdk.jlink.jmod Creating java.base.jmod Creating jdk image Creating CDS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From ci_notify at linaro.org Thu Oct 3 21:33:43 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 3 Oct 2019 21:33:43 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2095 Fixed Message-ID: <1231597068.4914.1570138423973.JavaMail.javamailuser@localhost> OpenJDK AArch64 jdk/jdk build status is Fixed Build details - https://ci.linaro.org/job/jdkX-ci-build/2095/ Changes - jboes: e25b317d0350fe5933ffdba7ab09d154b687f4e1 - test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/CollectorExample.java - src/java.base/share/classes/java/util/stream/Collector.java --"8231161: Wrong return type in code sample in Collector API documentation Summary: Correct declaration of container from R to A and add compilation test Reviewed-by: smarks, lancea " Build output - Creating jdk.internal.opt.jmod Creating jdk.internal.vm.ci.jmod Creating jdk.internal.vm.compiler.jmod Creating jdk.internal.vm.compiler.management.jmod Creating jdk.jartool.jmod Creating jdk.javadoc.jmod Creating jdk.jcmd.jmod Creating jdk.jconsole.jmod Creating jdk.jdeps.jmod Creating jdk.jdwp.agent.jmod Creating jdk.jdi.jmod Creating jdk.jfr.jmod Creating jdk.jshell.jmod Creating jdk.jsobject.jmod Creating jdk.jstatd.jmod Creating jdk.localedata.jmod Creating jdk.management.jmod Creating jdk.management.agent.jmod Creating jdk.management.jfr.jmod Creating jdk.naming.dns.jmod Creating jdk.naming.rmi.jmod Creating jdk.net.jmod Creating jdk.nio.mapmode.jmod Creating jdk.pack.jmod Creating jdk.rmic.jmod Creating jdk.scripting.nashorn.jmod Creating jdk.scripting.nashorn.shell.jmod Creating jdk.sctp.jmod Creating jdk.security.auth.jmod Creating jdk.security.jgss.jmod Creating jdk.unsupported.jmod Creating jdk.unsupported.desktop.jmod Creating jdk.xml.dom.jmod Creating jdk.zipfs.jmod Compiling 3 files for BUILD_DEMO_CodePointIM Updating support/demos/image/jfc/CodePointIM/src.zip Creating interim jimage Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 30 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 4 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 1 files for CLASSLIST_JAR Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Creating support/classlist.jar Compiling 8 files for BUILD_DEMO_TableExample Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Updating support/demos/image/jfc/TableExample/src.zip Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Creating support/demos/image/jfc/Metalworks/Metalworks.jar Creating support/demos/image/jfc/Notepad/Notepad.jar Creating support/demos/image/jfc/Stylepad/Stylepad.jar Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating jdk.jlink.jmod Creating java.base.jmod Creating jdk image Creating CDS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From ci_notify at linaro.org Sat Oct 5 06:39:51 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 5 Oct 2019 06:39:51 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <1105253455.5253.1570257592544.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/2019/277/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/may/25 pass: 5,735; fail: 5; not run: 11,623 Build 1: aarch64/2019/jun/05 pass: 5,737; fail: 5; not run: 11,623 Build 2: aarch64/2019/jun/15 pass: 5,737; fail: 5; not run: 11,623 Build 3: aarch64/2019/jun/27 pass: 5,737; fail: 5 Build 4: aarch64/2019/jul/02 pass: 5,737; fail: 5 Build 5: aarch64/2019/aug/03 pass: 5,746; fail: 4 Build 6: aarch64/2019/aug/10 pass: 5,747; fail: 4 Build 7: aarch64/2019/aug/15 pass: 5,753; fail: 4 Build 8: aarch64/2019/aug/22 pass: 5,755; fail: 4 Build 9: aarch64/2019/sep/04 pass: 5,764; fail: 2 Build 10: aarch64/2019/sep/05 pass: 5,764; fail: 2 Build 11: aarch64/2019/sep/10 pass: 5,764; fail: 2 Build 12: aarch64/2019/sep/17 pass: 5,763; fail: 3 Build 13: aarch64/2019/sep/21 pass: 5,764; fail: 2 Build 14: aarch64/2019/oct/04 pass: 5,764; fail: 2 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/may/25 pass: 8,403; fail: 511; error: 21 Build 1: aarch64/2019/jun/05 pass: 8,427; fail: 489; error: 19 Build 2: aarch64/2019/jun/15 pass: 8,409; fail: 506; error: 20 Build 3: aarch64/2019/jun/27 pass: 8,401; fail: 512; error: 22 Build 4: aarch64/2019/jul/02 pass: 8,407; fail: 498; error: 31 Build 5: aarch64/2019/aug/03 pass: 8,429; fail: 509; error: 18 Build 6: aarch64/2019/aug/10 pass: 8,450; fail: 485; error: 16 Build 7: aarch64/2019/aug/15 pass: 8,443; fail: 496; error: 13 Build 8: aarch64/2019/aug/22 pass: 8,446; fail: 494; error: 15 Build 9: aarch64/2019/sep/04 pass: 8,483; fail: 465; error: 10 Build 10: aarch64/2019/sep/05 pass: 8,465; fail: 479; error: 14 Build 11: aarch64/2019/sep/10 pass: 8,444; fail: 500; error: 14 Build 12: aarch64/2019/sep/17 pass: 8,462; fail: 482; error: 12 Build 13: aarch64/2019/sep/21 pass: 8,467; fail: 478; error: 13 Build 14: aarch64/2019/oct/04 pass: 8,444; fail: 498; error: 16 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/may/25 pass: 3,908 Build 1: aarch64/2019/jun/05 pass: 3,908 Build 2: aarch64/2019/jun/15 pass: 3,908 Build 3: aarch64/2019/jun/27 pass: 3,908 Build 4: aarch64/2019/jul/02 pass: 3,908 Build 5: aarch64/2019/aug/03 pass: 3,908 Build 6: aarch64/2019/aug/10 pass: 3,909 Build 7: aarch64/2019/aug/15 pass: 3,909 Build 8: aarch64/2019/aug/22 pass: 3,909 Build 9: aarch64/2019/sep/04 pass: 3,910 Build 10: aarch64/2019/sep/05 pass: 3,910 Build 11: aarch64/2019/sep/10 pass: 3,910 Build 12: aarch64/2019/sep/17 pass: 3,910 Build 13: aarch64/2019/sep/21 pass: 3,910 Build 14: aarch64/2019/oct/04 pass: 3,910 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.38x Relative performance: Server critical-jOPS (nc): 8.17x 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-05-26 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/145/results/ 2019-06-05 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/156/results/ 2019-06-16 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/166/results/ 2019-06-28 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/178/results/ 2019-07-03 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/183/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/215/results/ 2019-08-11 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/222/results/ 2019-08-16 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/227/results/ 2019-08-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/234/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/247/results/ 2019-09-07 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/248/results/ 2019-09-11 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/253/results/ 2019-09-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/260/results/ 2019-09-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/264/results/ 2019-10-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/277/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 Tue Oct 8 02:11:25 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 8 Oct 2019 02:11:25 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <956133509.5712.1570500686381.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/280/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/19 pass: 5,718 Build 1: aarch64/2019/aug/21 pass: 5,718; fail: 1 Build 2: aarch64/2019/aug/23 pass: 5,716; fail: 2 Build 3: aarch64/2019/aug/26 pass: 5,718; error: 1 Build 4: aarch64/2019/aug/28 pass: 5,719; fail: 1 Build 5: aarch64/2019/sep/03 pass: 5,732 Build 6: aarch64/2019/sep/05 pass: 5,733; fail: 1 Build 7: aarch64/2019/sep/09 pass: 5,734 Build 8: aarch64/2019/sep/11 pass: 5,736 Build 9: aarch64/2019/sep/13 pass: 5,737 Build 10: aarch64/2019/sep/16 pass: 5,726 Build 11: aarch64/2019/sep/18 pass: 5,727 Build 12: aarch64/2019/sep/20 pass: 5,728 Build 13: aarch64/2019/sep/23 pass: 5,727 Build 14: aarch64/2019/oct/07 pass: 5,750 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- 5 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/19 pass: 3,972 Build 1: aarch64/2019/aug/21 pass: 3,972 Build 2: aarch64/2019/aug/23 pass: 3,972 Build 3: aarch64/2019/aug/26 pass: 3,972 Build 4: aarch64/2019/aug/28 pass: 3,972 Build 5: aarch64/2019/sep/03 pass: 3,977 Build 6: aarch64/2019/sep/05 pass: 3,978 Build 7: aarch64/2019/sep/09 pass: 3,978 Build 8: aarch64/2019/sep/11 pass: 3,978 Build 9: aarch64/2019/sep/13 pass: 3,978 Build 10: aarch64/2019/sep/16 pass: 3,978 Build 11: aarch64/2019/sep/18 pass: 3,978 Build 12: aarch64/2019/sep/20 pass: 3,979 Build 13: aarch64/2019/sep/23 pass: 3,979 Build 14: aarch64/2019/oct/07 pass: 3,979 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.92x Relative performance: Server critical-jOPS (nc): 9.39x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-17 pass rate: 10488/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/228/results/ 2019-08-20 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/231/results/ 2019-08-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/233/results/ 2019-08-24 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/235/results/ 2019-08-27 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/238/results/ 2019-09-04 pass rate: 10488/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/240/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/246/results/ 2019-09-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/252/results/ 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Tue Oct 8 18:29:10 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 8 Oct 2019 18:29:10 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2120 Failure Message-ID: <1262271069.5859.1570559350949.JavaMail.javamailuser@localhost> OpenJDK AArch64 jdk/jdk build status is Failure Build details - https://ci.linaro.org/job/jdkX-ci-build/2120/ Changes - coleenp: c16f3a24a6fc6ce4802a2b8a3348d31ea151c643 - src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp - src/hotspot/cpu/arm/compiledIC_arm.cpp - src/hotspot/cpu/ppc/compiledIC_ppc.cpp - src/hotspot/cpu/s390/compiledIC_s390.cpp - src/hotspot/cpu/sparc/compiledIC_sparc.cpp - src/hotspot/cpu/x86/compiledIC_x86.cpp - src/hotspot/share/code/compiledIC.cpp - src/hotspot/share/code/compiledIC.hpp --"8225681: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe modification of inline cache Summary: allow old methods in CompiledStaticDirectCall::set_to_interpreted Reviewed-by: sspitsyn, eosterlund " Build output - total in heap [0x0000400014735690,0x0000400014735d58] = 1736 relocation [0x0000400014735808,0x0000400014735830] = 40 main code [0x0000400014735840,0x0000400014735a00] = 448 stub code [0x0000400014735a00,0x0000400014735ad0] = 208 metadata [0x0000400014735ad0,0x0000400014735af0] = 32 scopes data [0x0000400014735af0,0x0000400014735bb0] = 192 scopes pcs [0x0000400014735bb0,0x0000400014735d40] = 400 dependencies [0x0000400014735d40,0x0000400014735d48] = 8 nul chk table [0x0000400014735d48,0x0000400014735d58] = 16 AHE at 0x0000400010248aa0: 0xb0000000 i2c: 0x00004000140c8640 c2i: 0x00004000140c8688 c2iUV: 0x00004000140c8650 c2iNCI: 0x00004000140c86c4 Compiled method (c1) 2682 6 1 java.lang.String::hashCode (60 bytes) total in heap [0x0000400014735690,0x0000400014735d58] = 1736 relocation [0x0000400014735808,0x0000400014735830] = 40 main code [0x0000400014735840,0x0000400014735a00] = 448 stub code [0x0000400014735a00,0x0000400014735ad0] = 208 metadata [0x0000400014735ad0,0x0000400014735af0] = 32 scopes data [0x0000400014735af0,0x0000400014735bb0] = 192 scopes pcs [0x0000400014735bb0,0x0000400014735d40] = 400 dependencies [0x0000400014735d40,0x0000400014735d48] = 8 nul chk table [0x0000400014735d48,0x0000400014735d58] = 16 AHE at 0x0000400010248aa0: 0xb0000000 i2c: 0x00004000140c8640 c2i: 0x00004000140c8688 c2iUV: 0x00004000140c8650 c2iNCI: 0x00004000140c86c4 Compiled method (c1) 2682 6 1 java.lang.String::hashCode (60 bytes) total in heap [0x0000400014735690,0x0000400014735d58] = 1736 relocation [0x0000400014735808,0x0000400014735830] = 40 main code [0x0000400014735840,0x0000400014735a00] = 448 stub code [0x0000400014735a00,0x0000400014735ad0] = 208 metadata [0x0000400014735ad0,0x0000400014735af0] = 32 scopes data [0x0000400014735af0,0x0000400014735bb0] = 192 scopes pcs [0x0000400014735bb0,0x0000400014735d40] = 400 dependencies [0x0000400014735d40,0x0000400014735d48] = 8 nul chk table [0x0000400014735d48,0x0000400014735d58] = 16 Compiled method (c1) 2686 6 1 java.lang.String::hashCode (60 bytes) total in heap [0x0000400014735690,0x0000400014735d58] = 1736 relocation [0x0000400014735808,0x0000400014735830] = 40 main code [0x0000400014735840,0x0000400014735a00] = 448 stub code [0x0000400014735a00,0x0000400014735ad0] = 208 metadata [0x0000400014735ad0,0x0000400014735af0] = 32 scopes data [0x0000400014735af0,0x0000400014735bb0] = 192 scopes pcs [0x0000400014735bb0,0x0000400014735d40] = 400 dependencies [0x0000400014735d40,0x0000400014735d48] = 8 nul chk table [0x0000400014735d48,0x0000400014735d58] = 16 Compiled method (c1) 2686 6 1 java.lang.String::hashCode (60 bytes) total in heap [0x0000400014735690,0x0000400014735d58] = 1736 relocation [0x0000400014735808,0x0000400014735830] = 40 main code [0x0000400014735840,0x0000400014735a00] = 448 stub code [0x0000400014735a00,0x0000400014735ad0] = 208 metadata [0x0000400014735ad0,0x0000400014735af0] = 32 scopes data [0x0000400014735af0,0x0000400014735bb0] = 192 scopes pcs [0x0000400014735bb0,0x0000400014735d40] = 400 dependencies [0x0000400014735d40,0x0000400014735d48] = 8 nul chk table [0x0000400014735d48,0x0000400014735d58] = 16 # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Current thread is 10338 Dumping core ... /bin/bash: line 1: 10333 Aborted (core dumped) /home/buildslave/workspace/jdkX-ci-build/build/jdk/bin/java -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -cp /home/buildslave/workspace/jdkX-ci-build/build/buildtools/tools_jigsaw_classes --add-exports java.base/jdk.internal.module=ALL-UNNAMED build.tools.jigsaw.AddPackagesAttribute /home/buildslave/workspace/jdkX-ci-build/build/jdk > >(/usr/bin/tee -a /home/buildslave/workspace/jdkX-ci-build/build/jdk/_optimize_image_exec.log) 2> >(/usr/bin/tee -a /home/buildslave/workspace/jdkX-ci-build/build/jdk/_optimize_image_exec.log >&2) ExplodedImageOptimize.gmk:39: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/jdk/_optimize_image_exec.marker' failed make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/jdk/_optimize_image_exec.marker] Error 1 make/Main.gmk:390: recipe for target 'exploded-image-optimize' failed make[2]: *** [exploded-image-optimize] Error 1 ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) Stopping sjavac server === Output from failing command(s) repeated here === * For target jdk__optimize_image_exec: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/compiledIC.cpp:760 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/code/compiledIC.cpp:760), pid=10333, tid=10338 # assert(destination == (address)-1 || destination == entry) failed: b) MT-unsafe modification of inline cache # # JRE version: OpenJDK Runtime Environment (14.0) (fastdebug build 14-internal+0-adhoc.buildslave.jdkX) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 14-internal+0-adhoc.buildslave.jdkX, mixed mode, tiered, compressed oops, serial gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x80e2b4] CompiledDirectStaticCall::verify_mt_safe(methodHandle const&, unsigned char*, NativeMovConstReg*, NativeJump*)+0x9c # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/buildslave/workspace/jdkX-ci-build/jdkX/make/core.10333) # ... (rest of output omitted) * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs. === End of repeated output === === Make failed targets repeated here === ExplodedImageOptimize.gmk:39: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/jdk/_optimize_image_exec.marker' failed make/Main.gmk:390: recipe for target 'exploded-image-optimize' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. Hint: See doc/building.html#troubleshooting for assistance. /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:307: recipe for target 'main' failed make[1]: *** [main] Error 1 /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed make: *** [images] Error 2 From shade at redhat.com Wed Oct 9 09:05:09 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 9 Oct 2019 11:05:09 +0200 Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2120 Failure In-Reply-To: <1262271069.5859.1570559350949.JavaMail.javamailuser@localhost> References: <1262271069.5859.1570559350949.JavaMail.javamailuser@localhost> Message-ID: <3f10a798-e6bd-f395-eab1-e87f604c166b@redhat.com> On 10/8/19 8:29 PM, ci_notify at linaro.org wrote: > === Output from failing command(s) repeated here === > * For target jdk__optimize_image_exec: > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/compiledIC.cpp:760 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/code/compiledIC.cpp:760), pid=10333, tid=10338 > # assert(destination == (address)-1 || destination == entry) failed: b) MT-unsafe modification of inline cache > # > # JRE version: OpenJDK Runtime Environment (14.0) (fastdebug build 14-internal+0-adhoc.buildslave.jdkX) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 14-internal+0-adhoc.buildslave.jdkX, mixed mode, tiered, compressed oops, serial gc, linux-aarch64) > # Problematic frame: > # V [libjvm.so+0x80e2b4] CompiledDirectStaticCall::verify_mt_safe(methodHandle const&, unsigned char*, NativeMovConstReg*, NativeJump*)+0x9c > # > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/buildslave/workspace/jdkX-ci-build/jdkX/make/core.10333) Filed: https://bugs.openjdk.java.net/browse/JDK-8232046 AArch64 hackers, please take a look. -- Thanks, -Aleksey From stuart.monteith at linaro.org Wed Oct 9 14:49:46 2019 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 9 Oct 2019 15:49:46 +0100 Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2120 Failure In-Reply-To: <3f10a798-e6bd-f395-eab1-e87f604c166b@redhat.com> References: <1262271069.5859.1570559350949.JavaMail.javamailuser@localhost> <3f10a798-e6bd-f395-eab1-e87f604c166b@redhat.com> Message-ID: Hi, I've just noticed this - currently investigating. Stuart On Wed, 9 Oct 2019 at 10:05, Aleksey Shipilev wrote: > > On 10/8/19 8:29 PM, ci_notify at linaro.org wrote: > > === Output from failing command(s) repeated here === > > * For target jdk__optimize_image_exec: > > # To suppress the following error report, specify this argument > > # after -XX: or in .hotspotrc: SuppressErrorAt=/compiledIC.cpp:760 > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error (/home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/code/compiledIC.cpp:760), pid=10333, tid=10338 > > # assert(destination == (address)-1 || destination == entry) failed: b) MT-unsafe modification of inline cache > > # > > # JRE version: OpenJDK Runtime Environment (14.0) (fastdebug build 14-internal+0-adhoc.buildslave.jdkX) > > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 14-internal+0-adhoc.buildslave.jdkX, mixed mode, tiered, compressed oops, serial gc, linux-aarch64) > > # Problematic frame: > > # V [libjvm.so+0x80e2b4] CompiledDirectStaticCall::verify_mt_safe(methodHandle const&, unsigned char*, NativeMovConstReg*, NativeJump*)+0x9c > > # > > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/buildslave/workspace/jdkX-ci-build/jdkX/make/core.10333) > Filed: > https://bugs.openjdk.java.net/browse/JDK-8232046 > > AArch64 hackers, please take a look. > > -- > Thanks, > -Aleksey > From gnu.andrew at redhat.com Wed Oct 9 15:39:20 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 9 Oct 2019 16:39:20 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u232-b08 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/root/merge.changeset Changes in aarch64-shenandoah-jdk8u232-b08: - S8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries - S8226607: Inconsistent info between pcsclite.md and MUSCLE headers - S8228469: (tz) Upgrade time-zone data to tzdata2019b - S8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina - S8231098: (tz) Upgrade time-zone data to tzdata2019c - S8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u Main issues of note: Nothing really as pretty much all changes are in the JDK repository. diffstat for root b/.hgtags | 1 + b/THIRD_PARTY_README | 15 +++++---------- 2 files changed, 6 insertions(+), 10 deletions(-) diffstat for corba b/.hgtags | 1 + b/THIRD_PARTY_README | 15 +++++---------- 2 files changed, 6 insertions(+), 10 deletions(-) diffstat for jaxp b/.hgtags | 1 + b/THIRD_PARTY_README | 15 +++++---------- 2 files changed, 6 insertions(+), 10 deletions(-) diffstat for jaxws b/.hgtags | 1 + b/THIRD_PARTY_README | 15 +++++---------- 2 files changed, 6 insertions(+), 10 deletions(-) diffstat for langtools b/.hgtags | 1 + b/THIRD_PARTY_README | 15 +++++---------- 2 files changed, 6 insertions(+), 10 deletions(-) diffstat for nashorn b/.hgtags | 1 + b/THIRD_PARTY_README | 15 +++++---------- 2 files changed, 6 insertions(+), 10 deletions(-) diffstat for jdk b/.hgtags | 1 b/THIRD_PARTY_README | 15 b/make/data/tzdata/VERSION | 2 b/make/data/tzdata/africa | 168 ++++- b/make/data/tzdata/antarctica | 14 b/make/data/tzdata/asia | 243 ++++---- b/make/data/tzdata/australasia | 154 +++-- b/make/data/tzdata/europe | 298 ++++++---- b/make/data/tzdata/factory | 2 b/make/data/tzdata/leapseconds | 41 - b/make/data/tzdata/northamerica | 291 ++++++--- b/make/data/tzdata/pacificnew | 2 b/make/data/tzdata/southamerica | 79 +- b/make/data/tzdata/systemv | 2 b/make/data/tzdata/zone.tab | 5 b/make/lib/NetworkingLibraries.gmk | 2 b/src/share/classes/sun/util/calendar/ZoneInfoFile.java | 20 b/src/solaris/classes/sun/nio/fs/BsdFileStore.java | 20 b/src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java | 16 b/src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java | 2 b/src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c | 23 b/src/solaris/native/sun/security/smartcardio/MUSCLE/COPYING | 95 +++ b/src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java | 14 b/src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthentication.c | 32 - b/test/java/util/TimeZone/TimeZoneTest.java | 7 b/test/lib/testlibrary/jdk/testlibrary/net/URIBuilder.java | 111 +++ b/test/sun/net/www/protocol/http/TestTransparentNTLM.java | 203 ++++++ 27 files changed, 1350 insertions(+), 512 deletions(-) diffstat for hotspot a/test/runtime/RedefineTests/test8178870.sh | 87 ----------------- b/.hgtags | 1 b/THIRD_PARTY_README | 15 -- b/test/runtime/RedefineTests/RedefineDoubleDelete.java | 4 4 files changed, 10 insertions(+), 97 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 https://keybase.io/gnu_andrew From stuart.monteith at linaro.org Wed Oct 9 15:48:14 2019 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 9 Oct 2019 16:48:14 +0100 Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2120 Failure In-Reply-To: <3f10a798-e6bd-f395-eab1-e87f604c166b@redhat.com> References: <1262271069.5859.1570559350949.JavaMail.javamailuser@localhost> <3f10a798-e6bd-f395-eab1-e87f604c166b@redhat.com> Message-ID: Hello, The patch causing the issue is: 8225681: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine fails due a) MT-unsafe modification of inline cache Summary: allow old methods in CompiledStaticDirectCall::set_to_interpreted BR, Stuart On Wed, 9 Oct 2019 at 10:05, Aleksey Shipilev wrote: > > On 10/8/19 8:29 PM, ci_notify at linaro.org wrote: > > === Output from failing command(s) repeated here === > > * For target jdk__optimize_image_exec: > > # To suppress the following error report, specify this argument > > # after -XX: or in .hotspotrc: SuppressErrorAt=/compiledIC.cpp:760 > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error (/home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/code/compiledIC.cpp:760), pid=10333, tid=10338 > > # assert(destination == (address)-1 || destination == entry) failed: b) MT-unsafe modification of inline cache > > # > > # JRE version: OpenJDK Runtime Environment (14.0) (fastdebug build 14-internal+0-adhoc.buildslave.jdkX) > > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 14-internal+0-adhoc.buildslave.jdkX, mixed mode, tiered, compressed oops, serial gc, linux-aarch64) > > # Problematic frame: > > # V [libjvm.so+0x80e2b4] CompiledDirectStaticCall::verify_mt_safe(methodHandle const&, unsigned char*, NativeMovConstReg*, NativeJump*)+0x9c > > # > > # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/buildslave/workspace/jdkX-ci-build/jdkX/make/core.10333) > Filed: > https://bugs.openjdk.java.net/browse/JDK-8232046 > > AArch64 hackers, please take a look. > > -- > Thanks, > -Aleksey > From shade at redhat.com Wed Oct 9 16:17:02 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 9 Oct 2019 18:17:02 +0200 Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2120 Failure In-Reply-To: References: <1262271069.5859.1570559350949.JavaMail.javamailuser@localhost> <3f10a798-e6bd-f395-eab1-e87f604c166b@redhat.com> Message-ID: <0cfbcf6c-d2b3-d4c4-0dc4-a2d6625e9879@redhat.com> On 10/9/19 5:48 PM, Stuart Monteith wrote: > Hello, > The patch causing the issue is: > 8225681: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine > fails due a) MT-unsafe modification of inline cache > Summary: allow old methods in > CompiledStaticDirectCall::set_to_interpreted Yes, we know as much, see the bug: >> Filed: >> https://bugs.openjdk.java.net/browse/JDK-8232046 -- Thanks, -Aleksey From shade at redhat.com Wed Oct 9 16:41:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 9 Oct 2019 18:41:53 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u232-b08 Upstream Sync In-Reply-To: References: Message-ID: <31bd9e3b-8123-ec70-477c-99feef568362@redhat.com> On 10/9/19 5:39 PM, Andrew John Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jaxws/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/root/merge.changeset Looks trivially good. Thumbs up, good to go. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Oct 9 20:56:41 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 09 Oct 2019 20:56:41 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 4 new changesets Message-ID: <201910092056.x99KufGF024816@aojmv0008.oracle.com> Changeset: 7aea873d47e1 Author: valeriep Date: 2019-06-26 01:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/7aea873d47e1 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Summary: Updated the info based on MUSCLE v1.8.24 Reviewed-by: ascarpino ! THIRD_PARTY_README Changeset: 6b9f309807a2 Author: andrew Date: 2019-09-26 07:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/6b9f309807a2 Added tag jdk8u232-b08 for changeset 7aea873d47e1 ! .hgtags Changeset: 2c4777a60313 Author: andrew Date: 2019-10-01 19:25 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/2c4777a60313 Merge jdk8u232-b08 ! .hgtags ! THIRD_PARTY_README Changeset: c9aba478ce37 Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/c9aba478ce37 Added tag aarch64-shenandoah-jdk8u232-b08 for changeset 2c4777a60313 ! .hgtags From gnu.andrew at redhat.com Wed Oct 9 20:56:49 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 09 Oct 2019 20:56:49 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 4 new changesets Message-ID: <201910092056.x99KunA7024952@aojmv0008.oracle.com> Changeset: def9640e5d82 Author: valeriep Date: 2019-06-26 01:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/def9640e5d82 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Summary: Updated the info based on MUSCLE v1.8.24 Reviewed-by: ascarpino ! THIRD_PARTY_README Changeset: 3cdc7d41905a Author: andrew Date: 2019-09-26 07:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/3cdc7d41905a Added tag jdk8u232-b08 for changeset def9640e5d82 ! .hgtags Changeset: 027cf666b018 Author: andrew Date: 2019-10-01 19:25 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/027cf666b018 Merge jdk8u232-b08 ! .hgtags ! THIRD_PARTY_README Changeset: e64db4c4361b Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/e64db4c4361b Added tag aarch64-shenandoah-jdk8u232-b08 for changeset 027cf666b018 ! .hgtags From gnu.andrew at redhat.com Wed Oct 9 20:57:05 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 09 Oct 2019 20:57:05 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 4 new changesets Message-ID: <201910092057.x99Kv5ZW025217@aojmv0008.oracle.com> Changeset: 65b391f0ed66 Author: valeriep Date: 2019-06-26 01:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/65b391f0ed66 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Summary: Updated the info based on MUSCLE v1.8.24 Reviewed-by: ascarpino ! THIRD_PARTY_README Changeset: 5f799cd7fe51 Author: andrew Date: 2019-09-26 07:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/5f799cd7fe51 Added tag jdk8u232-b08 for changeset 65b391f0ed66 ! .hgtags Changeset: 1c737e598b71 Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/1c737e598b71 Merge jdk8u232-b08 ! .hgtags ! THIRD_PARTY_README Changeset: 920855bfc3ec Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/920855bfc3ec Added tag aarch64-shenandoah-jdk8u232-b08 for changeset 1c737e598b71 ! .hgtags From gnu.andrew at redhat.com Wed Oct 9 20:56:57 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 09 Oct 2019 20:56:57 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 4 new changesets Message-ID: <201910092056.x99KuvvO025031@aojmv0008.oracle.com> Changeset: 764618a906e8 Author: valeriep Date: 2019-06-26 01:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/764618a906e8 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Summary: Updated the info based on MUSCLE v1.8.24 Reviewed-by: ascarpino ! THIRD_PARTY_README Changeset: e15e896e7df1 Author: andrew Date: 2019-09-26 07:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/e15e896e7df1 Added tag jdk8u232-b08 for changeset 764618a906e8 ! .hgtags Changeset: 1649d820cbad Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/1649d820cbad Merge jdk8u232-b08 ! .hgtags ! THIRD_PARTY_README Changeset: 847a7f2a57e8 Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/847a7f2a57e8 Added tag aarch64-shenandoah-jdk8u232-b08 for changeset 1649d820cbad ! .hgtags From gnu.andrew at redhat.com Wed Oct 9 20:57:00 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 9 Oct 2019 21:57:00 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u232-b08 Upstream Sync In-Reply-To: <31bd9e3b-8123-ec70-477c-99feef568362@redhat.com> References: <31bd9e3b-8123-ec70-477c-99feef568362@redhat.com> Message-ID: On 09/10/2019 17:41, Aleksey Shipilev wrote: > On 10/9/19 5:39 PM, Andrew John Hughes wrote: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jaxws/merge.changeset > > Looks trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/jdk/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/hotspot/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-b08/root/merge.changeset > > Looks trivially good. > > Thumbs up, good to go. > Thanks. Pushed. -- 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 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Oct 9 20:57:13 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 09 Oct 2019 20:57:13 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 4 new changesets Message-ID: <201910092057.x99KvDE6025336@aojmv0008.oracle.com> Changeset: 4bc16c360830 Author: valeriep Date: 2019-06-26 01:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/4bc16c360830 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Summary: Updated the info based on MUSCLE v1.8.24 Reviewed-by: ascarpino ! THIRD_PARTY_README Changeset: 090e85a30eb6 Author: andrew Date: 2019-09-26 07:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/090e85a30eb6 Added tag jdk8u232-b08 for changeset 4bc16c360830 ! .hgtags Changeset: b397a8511e28 Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/b397a8511e28 Merge jdk8u232-b08 ! .hgtags ! THIRD_PARTY_README Changeset: cd7a98b306af Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/cd7a98b306af Added tag aarch64-shenandoah-jdk8u232-b08 for changeset b397a8511e28 ! .hgtags From gnu.andrew at redhat.com Wed Oct 9 20:57:29 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 09 Oct 2019 20:57:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 9 new changesets Message-ID: <201910092057.x99KvUQp025576@aojmv0008.oracle.com> Changeset: b32eb8c2d908 Author: chegar Date: 2019-08-19 14:28 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/b32eb8c2d908 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries Reviewed-by: dfuchs, alanb, erikj ! make/lib/NetworkingLibraries.gmk ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthentication.c + test/lib/testlibrary/jdk/testlibrary/net/URIBuilder.java + test/sun/net/www/protocol/http/TestTransparentNTLM.java Changeset: 3e949378fc18 Author: andrew Date: 2019-09-24 19:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3e949378fc18 Merge Changeset: 6a822cac8f26 Author: valeriep Date: 2019-06-26 01:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/6a822cac8f26 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Summary: Updated the info based on MUSCLE v1.8.24 Reviewed-by: ascarpino ! THIRD_PARTY_README + src/solaris/native/sun/security/smartcardio/MUSCLE/COPYING Changeset: d355fd566378 Author: andrew Date: 2019-09-25 19:52 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d355fd566378 8228469: (tz) Upgrade time-zone data to tzdata2019b Reviewed-by: shade ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/antarctica ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/factory ! make/data/tzdata/northamerica ! make/data/tzdata/pacificnew ! make/data/tzdata/southamerica ! make/data/tzdata/systemv ! make/data/tzdata/zone.tab ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! test/java/util/TimeZone/TimeZoneTest.java Changeset: 8560bc534080 Author: rpatil Date: 2019-09-24 10:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/8560bc534080 8231098: (tz) Upgrade time-zone data to tzdata2019c Reviewed-by: martin, naoto ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/southamerica Changeset: 69c4f673b33e Author: bpb Date: 2019-09-13 16:03 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/69c4f673b33e 8230085: (fs) FileStore::isReadOnly is always true on macOS Catalina Reviewed-by: alanb ! src/solaris/classes/sun/nio/fs/BsdFileStore.java ! src/solaris/classes/sun/nio/fs/BsdNativeDispatcher.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java ! src/solaris/native/sun/nio/fs/BsdNativeDispatcher.c Changeset: fe03778a3862 Author: andrew Date: 2019-09-26 07:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/fe03778a3862 Added tag jdk8u232-b08 for changeset 69c4f673b33e ! .hgtags Changeset: 39818e7fd5c7 Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/39818e7fd5c7 Merge jdk8u232-b08 ! .hgtags ! THIRD_PARTY_README ! make/data/tzdata/VERSION ! make/data/tzdata/africa ! make/data/tzdata/antarctica ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/leapseconds ! make/data/tzdata/northamerica ! make/data/tzdata/southamerica ! make/data/tzdata/zone.tab ! make/lib/NetworkingLibraries.gmk ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java Changeset: 7790dc4fcc23 Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/7790dc4fcc23 Added tag aarch64-shenandoah-jdk8u232-b08 for changeset 39818e7fd5c7 ! .hgtags From gnu.andrew at redhat.com Wed Oct 9 20:57:20 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 09 Oct 2019 20:57:20 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 5 new changesets Message-ID: <201910092057.x99KvK9p025469@aojmv0008.oracle.com> Changeset: 15a65d1c8924 Author: valeriep Date: 2019-06-26 01:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/15a65d1c8924 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Summary: Updated the info based on MUSCLE v1.8.24 Reviewed-by: ascarpino ! THIRD_PARTY_README Changeset: 4170228e11e6 Author: zgu Date: 2019-09-26 06:56 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4170228e11e6 8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u Reviewed-by: andrew ! test/runtime/RedefineTests/RedefineDoubleDelete.java - test/runtime/RedefineTests/test8178870.sh Changeset: 12177d88b89c Author: andrew Date: 2019-09-26 07:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/12177d88b89c Added tag jdk8u232-b08 for changeset 4170228e11e6 ! .hgtags Changeset: da542efab010 Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/da542efab010 Merge jdk8u232-b08 ! .hgtags ! THIRD_PARTY_README - test/runtime/RedefineTests/test8178870.sh Changeset: 73a6d57f689b Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/73a6d57f689b Added tag aarch64-shenandoah-jdk8u232-b08 for changeset da542efab010 ! .hgtags From gnu.andrew at redhat.com Wed Oct 9 20:57:38 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 09 Oct 2019 20:57:38 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 4 new changesets Message-ID: <201910092057.x99Kvda2025651@aojmv0008.oracle.com> Changeset: 9fc2e50a5c2f Author: valeriep Date: 2019-06-26 01:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/9fc2e50a5c2f 8226607: Inconsistent info between pcsclite.md and MUSCLE headers Summary: Updated the info based on MUSCLE v1.8.24 Reviewed-by: ascarpino ! THIRD_PARTY_README Changeset: 468982f5d7ed Author: andrew Date: 2019-09-26 07:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/468982f5d7ed Added tag jdk8u232-b08 for changeset 9fc2e50a5c2f ! .hgtags Changeset: f3c873b9d9fc Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/f3c873b9d9fc Merge jdk8u232-b08 ! .hgtags ! THIRD_PARTY_README Changeset: dd25c215f43b Author: andrew Date: 2019-10-01 19:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/dd25c215f43b Added tag aarch64-shenandoah-jdk8u232-b08 for changeset f3c873b9d9fc ! .hgtags From ci_notify at linaro.org Thu Oct 10 01:42:28 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 10 Oct 2019 01:42:28 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <2021816979.6144.1570671749289.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/282/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/21 pass: 5,718; fail: 1 Build 1: aarch64/2019/aug/23 pass: 5,716; fail: 2 Build 2: aarch64/2019/aug/26 pass: 5,718; error: 1 Build 3: aarch64/2019/aug/28 pass: 5,719; fail: 1 Build 4: aarch64/2019/sep/03 pass: 5,732 Build 5: aarch64/2019/sep/05 pass: 5,733; fail: 1 Build 6: aarch64/2019/sep/09 pass: 5,734 Build 7: aarch64/2019/sep/11 pass: 5,736 Build 8: aarch64/2019/sep/13 pass: 5,737 Build 9: aarch64/2019/sep/16 pass: 5,726 Build 10: aarch64/2019/sep/18 pass: 5,727 Build 11: aarch64/2019/sep/20 pass: 5,728 Build 12: aarch64/2019/sep/23 pass: 5,727 Build 13: aarch64/2019/oct/07 pass: 5,750 Build 14: aarch64/2019/oct/09 pass: 5,747; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/21 pass: 3,972 Build 1: aarch64/2019/aug/23 pass: 3,972 Build 2: aarch64/2019/aug/26 pass: 3,972 Build 3: aarch64/2019/aug/28 pass: 3,972 Build 4: aarch64/2019/sep/03 pass: 3,977 Build 5: aarch64/2019/sep/05 pass: 3,978 Build 6: aarch64/2019/sep/09 pass: 3,978 Build 7: aarch64/2019/sep/11 pass: 3,978 Build 8: aarch64/2019/sep/13 pass: 3,978 Build 9: aarch64/2019/sep/16 pass: 3,978 Build 10: aarch64/2019/sep/18 pass: 3,978 Build 11: aarch64/2019/sep/20 pass: 3,979 Build 12: aarch64/2019/sep/23 pass: 3,979 Build 13: aarch64/2019/oct/07 pass: 3,979 Build 14: aarch64/2019/oct/09 pass: 3,979 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.92x Relative performance: Server critical-jOPS (nc): 9.39x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-20 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/231/results/ 2019-08-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/233/results/ 2019-08-24 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/235/results/ 2019-08-27 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/238/results/ 2019-09-04 pass rate: 10488/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/240/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/246/results/ 2019-09-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/252/results/ 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From adinn at redhat.com Thu Oct 10 12:58:31 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 10 Oct 2019 13:58:31 +0100 Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2120 Failure In-Reply-To: <0cfbcf6c-d2b3-d4c4-0dc4-a2d6625e9879@redhat.com> References: <1262271069.5859.1570559350949.JavaMail.javamailuser@localhost> <3f10a798-e6bd-f395-eab1-e87f604c166b@redhat.com> <0cfbcf6c-d2b3-d4c4-0dc4-a2d6625e9879@redhat.com> Message-ID: On 09/10/2019 17:17, Aleksey Shipilev wrote: > On 10/9/19 5:48 PM, Stuart Monteith wrote: >> Hello, >> The patch causing the issue is: >> 8225681: vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine >> fails due a) MT-unsafe modification of inline cache >> Summary: allow old methods in >> CompiledStaticDirectCall::set_to_interpreted > > Yes, we know as much, see the bug: > >>> Filed: >>> https://bugs.openjdk.java.net/browse/JDK-8232046 I have a patch which is nearly through tier1 testing. Expect an RFR shortly. regards, Andrew Dinn ----------- From adinn at redhat.com Thu Oct 10 14:43:40 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 10 Oct 2019 15:43:40 +0100 Subject: [aarch64-port-dev ] RFR: AArch64: JDK-8232046: AArch64 build failure after JDK-8225681 Message-ID: <41cfc3b9-eb1e-b445-3136-9de93eb66cb2@redhat.com> Could I please have a review of the following patch AArch64-only which fixes a build failure on AArch64 introduced by JDK-8225681: JIRA: https://bugs.openjdk.java.net/browse/JDK-8232046 webrev: http://cr.openjdk.java.net/~adinn/8232046/webrev.00/ Testing: AArch64 build completes! tier1 tests pass (modulo a few clearly unrelated errors) vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java passes (that's the one JDK-8225681 was meant to fix) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Pengfei.Li at arm.com Fri Oct 11 01:43:40 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 11 Oct 2019 01:43:40 +0000 Subject: [aarch64-port-dev ] RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> Message-ID: FW aarch64-port-dev as this is AArch64 related. -- Thanks, Pengfei > Hello, > > Please review the following small change to reserve r27 (heap base > register) on AArch64 unconditionally, i.e., regardless of whether compressed > oops is enabled or not. > > http://cr.openjdk.java.net/~yzheng/8231754/ > https://bugs.openjdk.java.net/browse/JDK-8231754 > > Many thanks, > -Yudi From felix.yang at huawei.com Fri Oct 11 03:41:07 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 11 Oct 2019 03:41:07 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> Message-ID: > On 8/28/19 11:39 AM, Yangfei (Felix) wrote: > >> Having said that, I can sort-of imagine a jcstress failure if we had a test that > was doing compareAndSwap in one thread and getAndSet in another. That > would be a seriously compelling reason for a backport! > > Can you elaborate more please? especially the possible code sequence. > > > > Currently, we have C2 JIT for getAndSet like this: > > > > 33 ;; membar_release > > 34 0x0000ffffa416ae74: dmb ish > > 35 ;; 0x40000000000 > > 36 0x0000ffffa416ae78: orr x11, xzr, #0x40000000000 > > 37 0x0000ffffa416ae7c: add x10, x1, #0x10 > > 38 0x0000ffffa416ae80: prfm pstl1strm, [x10] > > 39 0x0000ffffa416ae84: ldxr x9, [x10] > > 40 0x0000ffffa416ae88: stxr w8, x11, [x10] > > 41 0x0000ffffa416ae8c: cbnz w8, 0x0000ffffa416ae84 > > 42 0x0000ffffa416ae90: mov x10, x9 > > 43 ;; membar_acquire > > 44 0x0000ffffa416ae94: dmb ishld ;*invokevirtual > getAndSetLong > > The important thing is that there should be a StoreLoad barrier between a > volatile store and a volatile load. If we have a getAndSet followed by a > CompareAndExchange that might not happen. > Hi, Sorry for the late reply. After some searching in jcstress code, I think the following test might be the test you wanted to see. org.openjdk.jcstress.tests.atomics.longs.AtomicLongArrayPairwiseTests.GetAndSet_CAS 43 @State 44 public static class S { 45 public final int SIZE = 256; // double the maximum cache line 46 public final AtomicLongArray a = new AtomicLongArray(SIZE); 47 public final int idx = ThreadLocalRandom.current().nextInt(SIZE); 48 } 445 @JCStressTest 446 @JCStressMeta(G.class) 447 @Outcome(id = "0, 10", expect = Expect.ACCEPTABLE, desc = "T1 -> T2 execution") 448 @Outcome(id = "20, 20", expect = Expect.ACCEPTABLE, desc = "T2 -> T1 execution") 449 public static class GetAndSet_CAS { 450 @Actor public void actor1(S s, LongResult2 r) { r.r1 = s.a.getAndSet(s.idx, 5); } 451 @Actor public void actor2(S s, LongResult2 r) { r.r2 = s.a.compareAndSet(s.idx, 0, 20) ? 20 : 10; } 452 } AtomicLongArray.getAndSet calls unsafe.getAndSetLong and AtomicLongArray.compareAndSet calls compareAndSetRaw which calls unsafe.compareAndSwapLong. For this test, one thread will do actor1 method. And another thread will do actor2 method concurrently. Thanks, Felix From dean.long at oracle.com Fri Oct 11 05:47:01 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 10 Oct 2019 22:47:01 -0700 Subject: [aarch64-port-dev ] RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> Message-ID: Wouldn't it be better to make r27 callee-saved in cpu/aarch64/sharedRuntime_aarch64.cpp:RegisterSaver::save_live_registers()? dl On 10/10/19 6:43 PM, Pengfei Li (Arm Technology China) wrote: > FW aarch64-port-dev as this is AArch64 related. > > -- > Thanks, > Pengfei > >> Hello, >> >> Please review the following small change to reserve r27 (heap base >> register) on AArch64 unconditionally, i.e., regardless of whether compressed >> oops is enabled or not. >> >> http://cr.openjdk.java.net/~yzheng/8231754/ >> https://bugs.openjdk.java.net/browse/JDK-8231754 >> >> Many thanks, >> -Yudi From adinn at redhat.com Fri Oct 11 08:27:19 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Oct 2019 09:27:19 +0100 Subject: [aarch64-port-dev ] RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> Message-ID: <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> > On 11/10/2019 07:47, dean.long at oracle.com wrote: >> Wouldn't it be better to make r27 callee-saved in >> cpu/aarch64/sharedRuntime_aarch64.cpp:RegisterSaver::save_live_registers()? On 11/10/2019 08:55, Gilles Duboscq wrote: > The idea was to first bring JVMCI in line with what the other compilers > do (never allocate r27) and then investigate how we could make r27 > conditionally allocatable if there is interest. I prefer Dean's suggestion. If I understand this patch correctly it seems it was motivated by a desire to deal with the failure to mark r27 as callee-saved in save_live_registers when it has been made allocatable. Bypassing that bug by disabling the optimization seems to me to be a needless regression; why not just fix the bug? (also, see below). n.b. I guess that also answers your speculation as to whether anyone is interested in allocating conditionally -- we were interested enough some time ago to implement this. When you say 'other compilers' are you referring to the Graal JIT? Or is there also a problem with C1 and/or C2? (or maybe some other JVMCI compiler we don't yet know about? ;-). If the problem is just that Graal cannot work safely when r27 is allocatable then can we not change the condition for enabling use of r27 to include a test that JVMCI is disabled? (and fix the callee_saved issue at the same time, of course :). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Oct 11 09:41:04 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Oct 2019 10:41:04 +0100 Subject: [aarch64-port-dev ] RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> Message-ID: Hi Gilles, On 11/10/2019 09:47, Gilles Duboscq wrote: > By "other compilers" i meant C1 and C2. Neither of those compilers ever > allocates r27. Ah, my apologies. I thought Roman Kennke investigated and pushed a patch for this optimization earlier in the year. Clearly, that experiment never escaped from the lab. In which case, I'm happy for Yudi's patch to go ahead as is. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Oct 11 11:22:57 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Oct 2019 12:22:57 +0100 Subject: [aarch64-port-dev ] RFR: AArch64: JDK-8232046: AArch64 build failure after JDK-8225681 In-Reply-To: <41cfc3b9-eb1e-b445-3136-9de93eb66cb2@redhat.com> References: <41cfc3b9-eb1e-b445-3136-9de93eb66cb2@redhat.com> Message-ID: <87fd08bf-82c0-0bb8-e322-311c878b43b4@redhat.com> ping! Is anyone willing to review this or do I have to wait for Andrew Haley to get back from his US trip? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander On 10/10/2019 15:43, Andrew Dinn wrote: > Could I please have a review of the following patch AArch64-only which > fixes a build failure on AArch64 introduced by JDK-8225681: > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8232046 > webrev: http://cr.openjdk.java.net/~adinn/8232046/webrev.00/ > > Testing: > > AArch64 build completes! > > tier1 tests pass > (modulo a few clearly unrelated errors) > > > vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java > passes > (that's the one JDK-8225681 was meant to fix) From erik.osterlund at oracle.com Fri Oct 11 12:04:17 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Fri, 11 Oct 2019 14:04:17 +0200 Subject: [aarch64-port-dev ] RFR: AArch64: JDK-8232046: AArch64 build failure after JDK-8225681 In-Reply-To: <87fd08bf-82c0-0bb8-e322-311c878b43b4@redhat.com> References: <41cfc3b9-eb1e-b445-3136-9de93eb66cb2@redhat.com> <87fd08bf-82c0-0bb8-e322-311c878b43b4@redhat.com> Message-ID: Hi Andrew, Looks good to me. I feel like something is weird about the 0 is logically -1 mapping (shouldn't it have populated the generic jump with -1 in the first place instead?), but that weirdness should not hold back this fix. Ship it. Thanks, /Erik On 10/11/19 1:22 PM, Andrew Dinn wrote: > ping! > > Is anyone willing to review this or do I have to wait for Andrew Haley > to get back from his US trip? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > On 10/10/2019 15:43, Andrew Dinn wrote: >> Could I please have a review of the following patch AArch64-only which >> fixes a build failure on AArch64 introduced by JDK-8225681: >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8232046 >> webrev: http://cr.openjdk.java.net/~adinn/8232046/webrev.00/ >> >> Testing: >> >> AArch64 build completes! >> >> tier1 tests pass >> (modulo a few clearly unrelated errors) >> >> >> vmTestbase/nsk/jvmti/RedefineClasses/StressRedefine/TestDescription.java >> passes >> (that's the one JDK-8225681 was meant to fix) From adinn at redhat.com Fri Oct 11 12:51:33 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Oct 2019 13:51:33 +0100 Subject: [aarch64-port-dev ] RFR: AArch64: JDK-8232046: AArch64 build failure after JDK-8225681 In-Reply-To: References: <41cfc3b9-eb1e-b445-3136-9de93eb66cb2@redhat.com> <87fd08bf-82c0-0bb8-e322-311c878b43b4@redhat.com> Message-ID: <48557f4d-bd8c-ff22-7c3e-fe8ec3f532dd@redhat.com> Hi Erik, On 11/10/2019 13:04, erik.osterlund at oracle.com wrote: > Looks good to me. I feel like something is weird about the 0 is > logically -1 mapping (shouldn't it have populated the generic jump with > -1 in the first place instead?), but that weirdness should not hold back > this fix. Ship it. Perhaps. Although -1 is not used anywhere else in the AArch64 code -- all other sites use a self-reference (jump target address == address of jump) from the get-go as well as after a reset. They then lie consistently about that to keep the generic code happy. I am not sure there is any good reason to use that in place of -1 but I always default to the assumption that Andrew Hayley had a reason for breaking with protocol. So, I'd really have preferred to have used a self-reference as the initial value in this case too. Indeed, I tried that but it failed to relocate when the nmethod was installed. When debugging that failure I spotted a cryptic breadcrumb comment left by Andrew Haley about relocs not doing the right thing when the generate buffer was copied. So, I decided to leave well alone at that point. This may only be an artefact of Andrew Haley not understanding relocs fully when he first wrote the code. When he is back I'll talk to him and see if we can correct this to use a self-reference or event switching all jumps to use -1 a an empty marker. Even if we can only manage consistent lying about the -1 that would be an improvement. Anyway, thanks very much for the review. As this is AArhc64 only I'll push on that basis asap. regards, Andrew Dinn ----------- From ci_notify at linaro.org Fri Oct 11 13:30:34 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 11 Oct 2019 13:30:34 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 2149 Fixed Message-ID: <1213345924.6354.1570800635332.JavaMail.javamailuser@localhost> OpenJDK AArch64 jdk/jdk build status is Fixed Build details - https://ci.linaro.org/job/jdkX-ci-build/2149/ Changes - adinn: ff8716224f355d92646c11510ad5dffac2474b36 - src/hotspot/cpu/aarch64/compiledIC_aarch64.cpp - src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp --"8232046: AArch64 build failure after JDK-8225681 Reviewed-by: eosterlund " coleenp: 7252d89e3a4eabc869f5a28ead6d2fdafc8b1d15 - src/hotspot/share/classfile/javaClasses.cpp --"8231769: Test tools/javac/tree/MakeTypeTest.java fails with -Xcheck:jni Summary: Delete local jni handles in create_from_platform_dependent_str() after upcall to Java. Reviewed-by: dholmes, hseigel " Build output - Creating jdk.internal.opt.jmod Creating jdk.internal.vm.ci.jmod Creating jdk.internal.vm.compiler.jmod Creating jdk.internal.vm.compiler.management.jmod Creating jdk.jartool.jmod Creating jdk.javadoc.jmod Creating jdk.jcmd.jmod Creating jdk.jconsole.jmod Creating jdk.jdeps.jmod Creating jdk.jdi.jmod Creating jdk.jdwp.agent.jmod Creating jdk.jfr.jmod Creating jdk.jshell.jmod Creating jdk.jsobject.jmod Creating jdk.jstatd.jmod Creating jdk.localedata.jmod Creating jdk.management.jmod Creating jdk.management.agent.jmod Creating jdk.management.jfr.jmod Creating jdk.naming.dns.jmod Creating jdk.naming.rmi.jmod Creating jdk.nio.mapmode.jmod Creating jdk.net.jmod Creating jdk.pack.jmod Creating jdk.rmic.jmod Creating jdk.scripting.nashorn.jmod Creating jdk.scripting.nashorn.shell.jmod Creating jdk.security.auth.jmod Creating jdk.sctp.jmod Creating jdk.security.jgss.jmod Creating jdk.unsupported.jmod Creating jdk.unsupported.desktop.jmod Creating jdk.xml.dom.jmod Creating jdk.zipfs.jmod Creating interim jimage Compiling 3 files for BUILD_DEMO_CodePointIM Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Compiling 30 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 4 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 8 files for BUILD_DEMO_TableExample Updating support/demos/image/jfc/TableExample/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Metalworks/MetalworksPrefs.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/Stylepad/Stylepad.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar Creating support/demos/image/jfc/Metalworks/Metalworks.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/demo/share/jfc/TableExample/TableExample4.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Notepad/Notepad.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/Stylepad/Stylepad.jar Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar Compiling 1 files for CLASSLIST_JAR Creating support/classlist.jar Creating jdk.jlink.jmod Creating java.base.jmod Creating jdk image Creating CDS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From ci_notify at linaro.org Sat Oct 12 02:11:30 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 12 Oct 2019 02:11:30 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <998003586.6454.1570846291399.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/284/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/23 pass: 5,716; fail: 2 Build 1: aarch64/2019/aug/26 pass: 5,718; error: 1 Build 2: aarch64/2019/aug/28 pass: 5,719; fail: 1 Build 3: aarch64/2019/sep/03 pass: 5,732 Build 4: aarch64/2019/sep/05 pass: 5,733; fail: 1 Build 5: aarch64/2019/sep/09 pass: 5,734 Build 6: aarch64/2019/sep/11 pass: 5,736 Build 7: aarch64/2019/sep/13 pass: 5,737 Build 8: aarch64/2019/sep/16 pass: 5,726 Build 9: aarch64/2019/sep/18 pass: 5,727 Build 10: aarch64/2019/sep/20 pass: 5,728 Build 11: aarch64/2019/sep/23 pass: 5,727 Build 12: aarch64/2019/oct/07 pass: 5,750 Build 13: aarch64/2019/oct/09 pass: 5,747; fail: 1 Build 14: aarch64/2019/oct/11 pass: 5,751; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/23 pass: 3,972 Build 1: aarch64/2019/aug/26 pass: 3,972 Build 2: aarch64/2019/aug/28 pass: 3,972 Build 3: aarch64/2019/sep/03 pass: 3,977 Build 4: aarch64/2019/sep/05 pass: 3,978 Build 5: aarch64/2019/sep/09 pass: 3,978 Build 6: aarch64/2019/sep/11 pass: 3,978 Build 7: aarch64/2019/sep/13 pass: 3,978 Build 8: aarch64/2019/sep/16 pass: 3,978 Build 9: aarch64/2019/sep/18 pass: 3,978 Build 10: aarch64/2019/sep/20 pass: 3,979 Build 11: aarch64/2019/sep/23 pass: 3,979 Build 12: aarch64/2019/oct/07 pass: 3,979 Build 13: aarch64/2019/oct/09 pass: 3,979 Build 14: aarch64/2019/oct/11 pass: 3,979 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.92x Relative performance: Server critical-jOPS (nc): 9.39x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/233/results/ 2019-08-24 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/235/results/ 2019-08-27 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/238/results/ 2019-09-04 pass rate: 10488/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/240/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/246/results/ 2019-09-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/252/results/ 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ 2019-10-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/284/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From dean.long at oracle.com Sat Oct 12 04:12:57 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 11 Oct 2019 21:12:57 -0700 Subject: [aarch64-port-dev ] RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> Message-ID: <4b4fb481-541c-ad35-d247-d3f838da0f0e@oracle.com> On 10/11/19 2:41 AM, Andrew Dinn wrote: > Hi Gilles, > > On 11/10/2019 09:47, Gilles Duboscq wrote: >> By "other compilers" i meant C1 and C2. Neither of those compilers ever >> allocates r27. > Ah, my apologies. I thought Roman Kennke investigated and pushed a patch > for this optimization earlier in the year. Clearly, that experiment > never escaped from the lab. I was thinking the same, but when I checked, it was only for x64: JDK-8217909. > In which case, I'm happy for Yudi's patch to go ahead as is. Me too. dl > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From ci_notify at linaro.org Tue Oct 15 03:27:13 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 15 Oct 2019 03:27:13 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1329381683.7251.1571110033650.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/287/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/26 pass: 5,718; error: 1 Build 1: aarch64/2019/aug/28 pass: 5,719; fail: 1 Build 2: aarch64/2019/sep/03 pass: 5,732 Build 3: aarch64/2019/sep/05 pass: 5,733; fail: 1 Build 4: aarch64/2019/sep/09 pass: 5,734 Build 5: aarch64/2019/sep/11 pass: 5,736 Build 6: aarch64/2019/sep/13 pass: 5,737 Build 7: aarch64/2019/sep/16 pass: 5,726 Build 8: aarch64/2019/sep/18 pass: 5,727 Build 9: aarch64/2019/sep/20 pass: 5,728 Build 10: aarch64/2019/sep/23 pass: 5,727 Build 11: aarch64/2019/oct/07 pass: 5,750 Build 12: aarch64/2019/oct/09 pass: 5,747; fail: 1 Build 13: aarch64/2019/oct/11 pass: 5,751; fail: 1 Build 14: aarch64/2019/oct/14 pass: 5,753 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/26 pass: 3,972 Build 1: aarch64/2019/aug/28 pass: 3,972 Build 2: aarch64/2019/sep/03 pass: 3,977 Build 3: aarch64/2019/sep/05 pass: 3,978 Build 4: aarch64/2019/sep/09 pass: 3,978 Build 5: aarch64/2019/sep/11 pass: 3,978 Build 6: aarch64/2019/sep/13 pass: 3,978 Build 7: aarch64/2019/sep/16 pass: 3,978 Build 8: aarch64/2019/sep/18 pass: 3,978 Build 9: aarch64/2019/sep/20 pass: 3,979 Build 10: aarch64/2019/sep/23 pass: 3,979 Build 11: aarch64/2019/oct/07 pass: 3,979 Build 12: aarch64/2019/oct/09 pass: 3,979 Build 13: aarch64/2019/oct/11 pass: 3,979 Build 14: aarch64/2019/oct/14 pass: 3,979 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.92x Relative performance: Server critical-jOPS (nc): 9.39x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 201.64 Server 201.64 / Server 2014-04-01 (71.00): 2.84x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-24 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/235/results/ 2019-08-27 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/238/results/ 2019-09-04 pass rate: 10488/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/240/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/246/results/ 2019-09-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/252/results/ 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ 2019-10-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/284/results/ 2019-10-15 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/287/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From gnu.andrew at redhat.com Tue Oct 15 22:00:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 15 Oct 2019 23:00:36 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u232-b09 / 8u232-ga Upstream Sync Message-ID: <4e75cf70-118c-eeeb-0c87-2ea1ae240e52@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/root/merge.changeset Changes in aarch64-shenandoah-jdk8u232-b09: - S8167646: Better invalid FilePermission - S8213429, CVE-2019-2933: Windows file handling redux - S8218573, CVE-2019-2945: Better socket support - S8218877: Help transform transformers - S8220186: Improve use of font temporary files - S8220302, CVE-2019-2949: Better Kerberos ccache handling - S8221497: Optional Panes in Swing - S8221858, CVE-2019-2958: Build Better Processes - S8222684, CVE-2019-2964: Better support for patterns - S8222690, CVE-2019-2962: Better Glyph Images - S8223163: Better pattern recognition - S8223505, CVE-2019-2973: Better pattern compilation - S8223518, CVE-2019-2975: Unexpected exception in jjs - S8223892, CVE-2019-2978: Improved handling of jar files - S8224025: Fix for JDK-8220302 is not complete - S8224532, CVE-2019-2981: Better Path supports - S8224915, CVE-2019-2983: Better serial attributes - S8225286, CVE-2019-2987: Better rendering of native glyphs - S8225292, CVE-2019-2988: Better Graphics2D drawing - S8225298, CVE-2019-2989: Improve TLS connection support - S8225597, CVE-2019-2992: Enhance font glyph mapping - S8226765, CVE-2019-2999: Commentary on Javadoc comments - S8227129: Better ligature for subtables - S8227601: Better collection of references - S8228825, CVE-2019-2894: Enhance ECDSA operations Main issues of note: No real merge as there are no HotSpot changes at all. 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 b/src/com/sun/org/apache/xpath/internal/XPath.java | 10 +- b/src/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java | 6 - b/src/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java | 6 - b/src/com/sun/org/apache/xpath/internal/compiler/Compiler.java | 36 ++++++++-- b/src/com/sun/org/apache/xpath/internal/compiler/XPathParser.java | 22 ++++-- b/src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java | 14 +++ 7 files changed, 74 insertions(+), 21 deletions(-) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + b/src/jdk/nashorn/internal/runtime/regexp/JdkRegExp.java | 4 +++- b/src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java | 4 +++- 3 files changed, 7 insertions(+), 2 deletions(-) diffstat for langtools b/.hgtags | 1 b/src/share/classes/com/sun/tools/javadoc/JavaScriptScanner.java | 36 +--------- b/test/tools/javadoc/TestScriptInComment.java | 6 + 3 files changed, 11 insertions(+), 32 deletions(-) diffstat for jdk b/.hgtags | 1 b/src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java | 12 b/src/share/classes/java/awt/Font.java | 6 b/src/share/classes/java/io/FilePermission.java | 37 ++ b/src/share/classes/java/net/NetPermission.java | 11 b/src/share/classes/java/net/ServerSocket.java | 15 b/src/share/classes/java/net/Socket.java | 18 + b/src/share/classes/java/net/URL.java | 10 b/src/share/classes/java/util/regex/Pattern.java | 14 b/src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java | 10 b/src/share/classes/javax/security/auth/kerberos/KerberosTicket.java | 20 + b/src/share/classes/sun/font/CMap.java | 22 + b/src/share/classes/sun/font/FileFont.java | 2 b/src/share/classes/sun/font/FontScaler.java | 6 b/src/share/classes/sun/font/FreetypeFontScaler.java | 24 + b/src/share/classes/sun/font/GlyphList.java | 14 b/src/share/classes/sun/java2d/SunGraphics2D.java | 6 b/src/share/classes/sun/misc/Launcher.java | 3 b/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java | 4 b/src/share/classes/sun/net/www/protocol/jar/Handler.java | 15 b/src/share/classes/sun/rmi/registry/RegistryImpl_Skel.java | 20 - b/src/share/classes/sun/rmi/registry/RegistryImpl_Stub.java | 27 - b/src/share/classes/sun/rmi/transport/DGCImpl_Skel.java | 17 - b/src/share/classes/sun/rmi/transport/DGCImpl_Stub.java | 50 +-- b/src/share/classes/sun/rmi/transport/StreamRemoteCall.java | 22 + b/src/share/classes/sun/security/jgss/krb5/Krb5Context.java | 8 b/src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java | 12 b/src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java | 4 b/src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java | 4 b/src/share/classes/sun/security/jgss/krb5/Krb5ProxyCredential.java | 31 +- b/src/share/classes/sun/security/jgss/krb5/Krb5Util.java | 29 + b/src/share/classes/sun/security/krb5/Credentials.java | 36 +- b/src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java | 15 b/src/share/classes/sun/security/krb5/Realm.java | 1 b/src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java | 32 +- b/src/share/classes/sun/security/krb5/internal/ccache/CCacheOutputStream.java | 16 - b/src/share/classes/sun/security/krb5/internal/ccache/Credentials.java | 20 + b/src/share/classes/sun/security/krb5/internal/ccache/CredentialsCache.java | 65 +++- b/src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java | 105 ++++++ b/src/share/classes/sun/security/ssl/EllipticCurvesExtension.java | 19 - b/src/share/classes/sun/security/util/SecurityConstants.java | 6 b/src/share/classes/sun/security/util/SecurityProperties.java | 82 +++++ b/src/share/lib/security/java.security-aix | 29 + b/src/share/lib/security/java.security-linux | 29 + b/src/share/lib/security/java.security-macosx | 29 + b/src/share/lib/security/java.security-solaris | 29 + b/src/share/lib/security/java.security-windows | 29 + b/src/share/native/sun/font/DrawGlyphList.c | 18 + b/src/share/native/sun/font/freetypeScaler.c | 82 ++++- b/src/share/native/sun/font/layout/AlternateSubstSubtables.cpp | 4 b/src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp | 4 b/src/share/native/sun/font/layout/LigatureSubstSubtables.cpp | 4 b/src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp | 4 b/src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp | 4 b/src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp | 4 b/src/share/native/sun/font/layout/MorphTables.cpp | 6 b/src/share/native/sun/font/layout/PairPositioningSubtables.cpp | 12 b/src/share/native/sun/font/layout/SegmentArrayProcessor.cpp | 2 b/src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp | 2 b/src/share/native/sun/font/layout/SegmentSingleProcessor.cpp | 2 b/src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp | 2 b/src/share/native/sun/font/layout/SimpleArrayProcessor.cpp | 2 b/src/share/native/sun/font/layout/SinglePositioningSubtables.cpp | 12 b/src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp | 12 b/src/share/native/sun/font/layout/SingleTableProcessor.cpp | 2 b/src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h | 2 b/src/share/native/sun/java2d/loops/LoopMacros.h | 8 b/src/share/native/sun/java2d/opengl/OGLBlitLoops.c | 42 +- b/src/share/native/sun/security/krb5/nativeccache.c | 44 ++ b/src/solaris/classes/sun/font/XRGlyphCache.java | 3 b/src/solaris/classes/sun/font/XRTextRenderer.java | 3 b/src/solaris/native/sun/java2d/x11/X11FontScaler_md.c | 6 b/src/windows/classes/java/lang/ProcessImpl.java | 154 ++++++---- b/src/windows/classes/sun/security/krb5/internal/tools/Klist.java | 38 ++ b/src/windows/native/sun/java2d/d3d/D3DContext.cpp | 4 b/test/java/awt/image/DrawImage/IncorrectManagedImageSourceOffset.java | 86 ++++- b/test/java/awt/image/DrawImage/IncorrectUnmanagedImageSourceOffset.java | 65 +++- b/test/java/awt/image/DrawImage/SimpleManagedImage.java | 110 +++++-- b/test/java/awt/image/DrawImage/SimpleUnmanagedImage.java | 93 ++++-- b/test/java/io/FilePermission/Invalid.java | 67 ++++ b/test/java/rmi/testlibrary/TestSocketFactory.java | 20 + 81 files changed, 1605 insertions(+), 334 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? -- 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 https://keybase.io/gnu_andrew From shade at redhat.com Tue Oct 15 22:04:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Oct 2019 00:04:10 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u232-b09 / 8u232-ga Upstream Sync In-Reply-To: <4e75cf70-118c-eeeb-0c87-2ea1ae240e52@redhat.com> References: <4e75cf70-118c-eeeb-0c87-2ea1ae240e52@redhat.com> Message-ID: <7cdaf960-2d9b-eb59-daac-17a5a55b9b2f@redhat.com> On 10/16/19 12:00 AM, Andrew John Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/corba/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jaxp/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jaxws/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/hotspot/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/langtools/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/nashorn/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/root/merge.changeset Looks trivially good. Thumbs up! Good to go. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Oct 15 22:17:14 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 15 Oct 2019 22:17:14 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <201910152217.x9FMHEXD028395@aojmv0008.oracle.com> Changeset: fcdc51860577 Author: andrew Date: 2019-10-10 04:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/fcdc51860577 Added tag jdk8u232-b09 for changeset 6b9f309807a2 ! .hgtags Changeset: ec04e0be7de4 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/ec04e0be7de4 Merge jdk8u232-b09 ! .hgtags Changeset: 6056f713a182 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/6056f713a182 Added tag aarch64-shenandoah-jdk8u232-b09 for changeset ec04e0be7de4 ! .hgtags From gnu.andrew at redhat.com Tue Oct 15 22:17:21 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 15 Oct 2019 22:17:21 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <201910152217.x9FMHLeA028524@aojmv0008.oracle.com> Changeset: 917351883532 Author: andrew Date: 2019-10-10 04:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/917351883532 Added tag jdk8u232-b09 for changeset 3cdc7d41905a ! .hgtags Changeset: 15c82046b3d4 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/15c82046b3d4 Merge jdk8u232-b09 ! .hgtags Changeset: 8296027440de Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/8296027440de Added tag aarch64-shenandoah-jdk8u232-b09 for changeset 15c82046b3d4 ! .hgtags From gnu.andrew at redhat.com Tue Oct 15 22:17:44 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 15 Oct 2019 22:17:44 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 4 new changesets Message-ID: <201910152217.x9FMHiYk028890@aojmv0008.oracle.com> Changeset: 735048c9f2d6 Author: igerasim Date: 2019-08-12 13:24 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/735048c9f2d6 8226765: Commentary on Javadoc comments Reviewed-by: jjg, rhalade, skoivu ! src/share/classes/com/sun/tools/javadoc/JavaScriptScanner.java ! test/tools/javadoc/TestScriptInComment.java Changeset: ce7322b16382 Author: andrew Date: 2019-10-10 04:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/ce7322b16382 Added tag jdk8u232-b09 for changeset 735048c9f2d6 ! .hgtags Changeset: 7a6b2564b45f Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/7a6b2564b45f Merge jdk8u232-b09 ! .hgtags Changeset: 775c14b2c44e Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/775c14b2c44e Added tag aarch64-shenandoah-jdk8u232-b09 for changeset 7a6b2564b45f ! .hgtags From gnu.andrew at redhat.com Tue Oct 15 22:17:29 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 15 Oct 2019 22:17:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 5 new changesets Message-ID: <201910152217.x9FMHTPX028611@aojmv0008.oracle.com> Changeset: 9094c855c4b4 Author: joehw Date: 2019-05-21 13:02 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/9094c855c4b4 8223505: Better pattern compilation Reviewed-by: rriggs, lancea, dfuchs, mschoene ! src/com/sun/org/apache/xpath/internal/compiler/XPathParser.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java Changeset: 6f9c0c731ab7 Author: joehw Date: 2019-05-31 10:58 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/6f9c0c731ab7 8224532: Better Path supports Reviewed-by: rriggs, lancea, dfuchs, mschoene ! src/com/sun/org/apache/xpath/internal/XPath.java ! src/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java ! src/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java ! src/com/sun/org/apache/xpath/internal/compiler/Compiler.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java Changeset: 8b4cdef0a9f3 Author: andrew Date: 2019-10-10 04:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/8b4cdef0a9f3 Added tag jdk8u232-b09 for changeset 6f9c0c731ab7 ! .hgtags Changeset: 9ee00f537431 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/9ee00f537431 Merge jdk8u232-b09 ! .hgtags Changeset: 021801282bed Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/021801282bed Added tag aarch64-shenandoah-jdk8u232-b09 for changeset 9ee00f537431 ! .hgtags From gnu.andrew at redhat.com Tue Oct 15 22:17:36 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 15 Oct 2019 22:17:36 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 3 new changesets Message-ID: <201910152217.x9FMHa1I028689@aojmv0008.oracle.com> Changeset: 45ee864c72ac Author: andrew Date: 2019-10-10 04:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/45ee864c72ac Added tag jdk8u232-b09 for changeset 5f799cd7fe51 ! .hgtags Changeset: e7adf2360405 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/e7adf2360405 Merge jdk8u232-b09 ! .hgtags Changeset: 155c4fab9d90 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/155c4fab9d90 Added tag aarch64-shenandoah-jdk8u232-b09 for changeset e7adf2360405 ! .hgtags From gnu.andrew at redhat.com Tue Oct 15 22:17:29 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 15 Oct 2019 23:17:29 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u232-b09 / 8u232-ga Upstream Sync In-Reply-To: <7cdaf960-2d9b-eb59-daac-17a5a55b9b2f@redhat.com> References: <4e75cf70-118c-eeeb-0c87-2ea1ae240e52@redhat.com> <7cdaf960-2d9b-eb59-daac-17a5a55b9b2f@redhat.com> Message-ID: <7c8111c0-c3fb-5496-a0f0-7f17df32b54f@redhat.com> On 15/10/2019 23:04, Aleksey Shipilev wrote: > On 10/16/19 12:00 AM, Andrew John Hughes wrote: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/corba/merge.changeset > > Looks trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jaxp/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jaxws/merge.changeset > > Looks trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/jdk/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/hotspot/merge.changeset > > Looks trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/langtools/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/nashorn/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u232-ga/root/merge.changeset > > Looks trivially good. > > Thumbs up! Good to go. > Thanks. Pushed. -- 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 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Oct 15 22:17:51 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 15 Oct 2019 22:17:51 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 3 new changesets Message-ID: <201910152217.x9FMHpPS029475@aojmv0008.oracle.com> Changeset: ca96653a3059 Author: andrew Date: 2019-10-10 04:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ca96653a3059 Added tag jdk8u232-b09 for changeset 12177d88b89c ! .hgtags Changeset: 9e52f8d3b511 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9e52f8d3b511 Merge jdk8u232-b09 ! .hgtags Changeset: 309b496da750 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/309b496da750 Added tag aarch64-shenandoah-jdk8u232-b09 for changeset 9e52f8d3b511 ! .hgtags From gnu.andrew at redhat.com Tue Oct 15 22:18:00 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 15 Oct 2019 22:18:00 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 22 new changesets Message-ID: <201910152218.x9FMI1Jd029592@aojmv0008.oracle.com> Changeset: b148d99d5cc3 Author: andrew Date: 2019-10-10 02:30 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/b148d99d5cc3 8213429: Windows file handling redux 8167646: Better invalid FilePermission Reviewed-by: mbalao ! src/share/classes/java/io/FilePermission.java ! src/share/classes/sun/misc/Launcher.java + test/java/io/FilePermission/Invalid.java Changeset: dd50896e9dec Author: michaelm Date: 2019-03-25 17:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/dd50896e9dec 8218573: Better socket support Reviewed-by: alanb, ahgross, chegar, igerasim ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java ! src/share/classes/sun/security/util/SecurityConstants.java Changeset: 1f5e1d743e4b Author: alitvinov Date: 2019-05-31 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1f5e1d743e4b 8218877: Help transform transformers Reviewed-by: serb, prr, mschoene, bpb, ssahoo ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/loops/LoopMacros.h ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c ! src/windows/native/sun/java2d/d3d/D3DContext.cpp Changeset: f0bbf5b47d57 Author: prr Date: 2019-04-23 11:59 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f0bbf5b47d57 8220186: Improve use of font temporary files Reviewed-by: serb, psadhukhan, mschoene, rhalade ! src/share/classes/sun/font/FileFont.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/native/sun/font/freetypeScaler.c Changeset: 96cab194659e Author: weijun Date: 2019-04-19 10:22 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/96cab194659e 8220302: Better Kerberos ccache handling Reviewed-by: valeriep ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/javax/security/auth/kerberos/JavaxSecurityAuthKerberosAccessImpl.java ! src/share/classes/javax/security/auth/kerberos/KerberosTicket.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/jgss/krb5/Krb5ProxyCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/classes/sun/security/krb5/JavaxSecurityAuthKerberosAccess.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/ccache/CCacheInputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/CCacheOutputStream.java ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/share/classes/sun/security/krb5/internal/ccache/CredentialsCache.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java + src/share/classes/sun/security/util/SecurityProperties.java ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: 8f88a036006e Author: weijun Date: 2019-05-21 08:37 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/8f88a036006e 8224025: Fix for JDK-8220302 is not complete Reviewed-by: ahgross, mullan, valeriep ! src/share/native/sun/security/krb5/nativeccache.c Changeset: db612d10296b Author: serb Date: 2019-10-10 03:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/db612d10296b 8221497: Optional Panes in Swing Reviewed-by: prr, alitvinov, mschoene, rhalade ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c + test/java/awt/image/DrawImage/IncorrectManagedImageSourceOffset.java ! test/java/awt/image/DrawImage/IncorrectUnmanagedImageSourceOffset.java + test/java/awt/image/DrawImage/SimpleManagedImage.java + test/java/awt/image/DrawImage/SimpleUnmanagedImage.java Changeset: 9e42cbb6a9ed Author: rriggs Date: 2019-04-30 16:45 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9e42cbb6a9ed 8221858: Build Better Processes Reviewed-by: alanb, rhalade, ahgross, darcy ! src/windows/classes/java/lang/ProcessImpl.java Changeset: 643871d087e0 Author: igerasim Date: 2019-05-22 19:41 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/643871d087e0 8222684: Better support for patterns 8223163: Better pattern recognition Reviewed-by: ahgross, bchristi, jeff, rhalade, rriggs, smarks ! src/share/classes/java/util/regex/Pattern.java Changeset: eeac0c758228 Author: prr Date: 2019-05-15 12:44 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/eeac0c758228 8222690: Better Glyph Images Reviewed-by: serb, psadhukhan, mschoene, rhalade ! src/share/classes/sun/font/GlyphList.java ! src/share/native/sun/font/DrawGlyphList.c ! src/share/native/sun/font/freetypeScaler.c ! src/solaris/classes/sun/font/XRGlyphCache.java ! src/solaris/classes/sun/font/XRTextRenderer.java ! src/solaris/native/sun/java2d/x11/X11FontScaler_md.c Changeset: 1f801b99581a Author: aefimov Date: 2019-06-25 00:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1f801b99581a 8223892: Improved handling of jar files Reviewed-by: dfuchs, chegar, michaelm, rhalade, ahgross ! src/share/classes/java/net/URL.java ! src/share/classes/sun/net/www/protocol/jar/Handler.java Changeset: 5c1c0eda1459 Author: prr Date: 2019-06-14 20:33 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/5c1c0eda1459 8224915: Better serial attributes Reviewed-by: serb, psadhukhan, mschoene, rhalade ! src/share/classes/java/awt/Font.java Changeset: 2c10a7ea0c40 Author: prr Date: 2019-06-19 15:24 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2c10a7ea0c40 8225286: Better rendering of native glyphs Reviewed-by: serb, psadhukhan, mschoene, rhalade ! src/share/native/sun/font/freetypeScaler.c Changeset: c20af8b7844d Author: prr Date: 2019-06-16 13:14 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c20af8b7844d 8225292: Better Graphics2D drawing Reviewed-by: serb, psadhukhan, mschoene, rhalade ! src/share/classes/sun/java2d/SunGraphics2D.java Changeset: 932b59a0766b Author: igerasim Date: 2019-06-22 20:46 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/932b59a0766b 8225298: Improve TLS connection support Reviewed-by: dfuchs, igerasim, michaelm, rhalade, skoivu ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java Changeset: e033daba121d Author: prr Date: 2019-06-19 15:23 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e033daba121d 8225597: Enhance font glyph mapping Reviewed-by: serb, psadhukhan, mschoene, rhalade ! src/share/classes/sun/font/CMap.java Changeset: 64b55ae060e8 Author: mbalao Date: 2019-09-24 19:07 -0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/64b55ae060e8 8227129: Better ligature for subtables Reviewed-by: bae ! src/share/native/sun/font/layout/AlternateSubstSubtables.cpp ! src/share/native/sun/font/layout/CursiveAttachmentSubtables.cpp ! src/share/native/sun/font/layout/LigatureSubstSubtables.cpp ! src/share/native/sun/font/layout/MarkToBasePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToLigaturePosnSubtables.cpp ! src/share/native/sun/font/layout/MarkToMarkPosnSubtables.cpp ! src/share/native/sun/font/layout/MorphTables.cpp ! src/share/native/sun/font/layout/PairPositioningSubtables.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor.cpp ! src/share/native/sun/font/layout/SegmentArrayProcessor2.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor.cpp ! src/share/native/sun/font/layout/SegmentSingleProcessor2.cpp ! src/share/native/sun/font/layout/SimpleArrayProcessor.cpp ! src/share/native/sun/font/layout/SinglePositioningSubtables.cpp ! src/share/native/sun/font/layout/SingleSubstitutionSubtables.cpp ! src/share/native/sun/font/layout/SingleTableProcessor.cpp Changeset: 523d48606333 Author: rriggs Date: 2019-01-17 10:44 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/523d48606333 8227601: Better collection of references Reviewed-by: smarks, ahgross, skoivu, rhalade ! src/share/classes/sun/rmi/registry/RegistryImpl_Skel.java ! src/share/classes/sun/rmi/registry/RegistryImpl_Stub.java ! src/share/classes/sun/rmi/transport/DGCImpl_Skel.java ! src/share/classes/sun/rmi/transport/DGCImpl_Stub.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! test/java/rmi/testlibrary/TestSocketFactory.java Changeset: 5456f24496f4 Author: andrew Date: 2019-10-10 04:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/5456f24496f4 8228825: Enhance ECDSA operations Reviewed-by: bae, bmathiske ! src/share/classes/sun/security/ssl/EllipticCurvesExtension.java Changeset: 97c98d070451 Author: andrew Date: 2019-10-10 04:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/97c98d070451 Added tag jdk8u232-b09 for changeset 5456f24496f4 ! .hgtags Changeset: 360ffe23d1ca Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/360ffe23d1ca Merge jdk8u232-b09 ! .hgtags ! src/share/classes/com/sun/security/auth/module/Krb5LoginModule.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/Socket.java ! src/share/classes/java/net/URL.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/ssl/EllipticCurvesExtension.java ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/share/native/sun/font/freetypeScaler.c ! src/share/native/sun/java2d/opengl/OGLBlitLoops.c ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java Changeset: 7676a884c3f6 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/7676a884c3f6 Added tag aarch64-shenandoah-jdk8u232-b09 for changeset 360ffe23d1ca ! .hgtags From gnu.andrew at redhat.com Tue Oct 15 22:18:14 2019 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 15 Oct 2019 22:18:14 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 4 new changesets Message-ID: <201910152218.x9FMIEp9029731@aojmv0008.oracle.com> Changeset: fba077f48da2 Author: hannesw Date: 2019-05-24 16:53 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/fba077f48da2 8223518: Unexpected exception in jjs Reviewed-by: sundar, mschoene, rhalade, jlaskey ! src/jdk/nashorn/internal/runtime/regexp/JdkRegExp.java ! src/jdk/nashorn/internal/runtime/regexp/JoniRegExp.java Changeset: db9f5afd254e Author: andrew Date: 2019-10-10 04:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/db9f5afd254e Added tag jdk8u232-b09 for changeset fba077f48da2 ! .hgtags Changeset: cdb42cee07aa Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/cdb42cee07aa Merge jdk8u232-b09 ! .hgtags Changeset: 0dc4bc2ff507 Author: andrew Date: 2019-10-10 18:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/0dc4bc2ff507 Added tag aarch64-shenandoah-jdk8u232-b09 for changeset cdb42cee07aa ! .hgtags From ci_notify at linaro.org Thu Oct 17 01:59:02 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 17 Oct 2019 01:59:02 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <618492281.7945.1571277543100.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/289/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/28 pass: 5,719; fail: 1 Build 1: aarch64/2019/sep/03 pass: 5,732 Build 2: aarch64/2019/sep/05 pass: 5,733; fail: 1 Build 3: aarch64/2019/sep/09 pass: 5,734 Build 4: aarch64/2019/sep/11 pass: 5,736 Build 5: aarch64/2019/sep/13 pass: 5,737 Build 6: aarch64/2019/sep/16 pass: 5,726 Build 7: aarch64/2019/sep/18 pass: 5,727 Build 8: aarch64/2019/sep/20 pass: 5,728 Build 9: aarch64/2019/sep/23 pass: 5,727 Build 10: aarch64/2019/oct/07 pass: 5,750 Build 11: aarch64/2019/oct/09 pass: 5,747; fail: 1 Build 12: aarch64/2019/oct/11 pass: 5,751; fail: 1 Build 13: aarch64/2019/oct/14 pass: 5,753 Build 14: aarch64/2019/oct/16 pass: 5,753; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/28 pass: 3,972 Build 1: aarch64/2019/sep/03 pass: 3,977 Build 2: aarch64/2019/sep/05 pass: 3,978 Build 3: aarch64/2019/sep/09 pass: 3,978 Build 4: aarch64/2019/sep/11 pass: 3,978 Build 5: aarch64/2019/sep/13 pass: 3,978 Build 6: aarch64/2019/sep/16 pass: 3,978 Build 7: aarch64/2019/sep/18 pass: 3,978 Build 8: aarch64/2019/sep/20 pass: 3,979 Build 9: aarch64/2019/sep/23 pass: 3,979 Build 10: aarch64/2019/oct/07 pass: 3,979 Build 11: aarch64/2019/oct/09 pass: 3,979 Build 12: aarch64/2019/oct/11 pass: 3,979 Build 13: aarch64/2019/oct/14 pass: 3,979 Build 14: aarch64/2019/oct/16 pass: 3,979 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.92x Relative performance: Server critical-jOPS (nc): 9.39x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-27 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/238/results/ 2019-09-04 pass rate: 10488/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/240/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/246/results/ 2019-09-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/252/results/ 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ 2019-10-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/284/results/ 2019-10-15 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/287/results/ 2019-10-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/289/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Thu Oct 17 13:06:18 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 17 Oct 2019 14:06:18 +0100 Subject: [aarch64-port-dev ] RFR (trivial) : fix aarch64-8u type profile bug In-Reply-To: References: <222f9c0b-7320-8d22-cd44-c4f3af7c1311@redhat.com> <880f5072-91ba-66bd-94be-429556e7c132@redhat.com> Message-ID: <8ad0aa09-bfb1-c891-e17a-be7d14b3a2ae@redhat.com> On 9/26/19 2:59 AM, Yangfei (Felix) wrote: > CCing to hotspot-runtime-dev list. > > This has passed hotspot jtreg test on aarch64-linux. Is it OK to go? I'll have a look. -- 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 Fri Oct 18 04:58:28 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 18 Oct 2019 04:58:28 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <803549955.8206.1571374709794.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/2019/290/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/jun/05 pass: 5,737; fail: 5; not run: 11,623 Build 1: aarch64/2019/jun/15 pass: 5,737; fail: 5; not run: 11,623 Build 2: aarch64/2019/jun/27 pass: 5,737; fail: 5 Build 3: aarch64/2019/jul/02 pass: 5,737; fail: 5 Build 4: aarch64/2019/aug/03 pass: 5,746; fail: 4 Build 5: aarch64/2019/aug/10 pass: 5,747; fail: 4 Build 6: aarch64/2019/aug/15 pass: 5,753; fail: 4 Build 7: aarch64/2019/aug/22 pass: 5,755; fail: 4 Build 8: aarch64/2019/sep/04 pass: 5,764; fail: 2 Build 9: aarch64/2019/sep/05 pass: 5,764; fail: 2 Build 10: aarch64/2019/sep/10 pass: 5,764; fail: 2 Build 11: aarch64/2019/sep/17 pass: 5,763; fail: 3 Build 12: aarch64/2019/sep/21 pass: 5,764; fail: 2 Build 13: aarch64/2019/oct/04 pass: 5,764; fail: 2 Build 14: aarch64/2019/oct/17 pass: 5,764; fail: 2 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/jun/05 pass: 8,427; fail: 489; error: 19 Build 1: aarch64/2019/jun/15 pass: 8,409; fail: 506; error: 20 Build 2: aarch64/2019/jun/27 pass: 8,401; fail: 512; error: 22 Build 3: aarch64/2019/jul/02 pass: 8,407; fail: 498; error: 31 Build 4: aarch64/2019/aug/03 pass: 8,429; fail: 509; error: 18 Build 5: aarch64/2019/aug/10 pass: 8,450; fail: 485; error: 16 Build 6: aarch64/2019/aug/15 pass: 8,443; fail: 496; error: 13 Build 7: aarch64/2019/aug/22 pass: 8,446; fail: 494; error: 15 Build 8: aarch64/2019/sep/04 pass: 8,483; fail: 465; error: 10 Build 9: aarch64/2019/sep/05 pass: 8,465; fail: 479; error: 14 Build 10: aarch64/2019/sep/10 pass: 8,444; fail: 500; error: 14 Build 11: aarch64/2019/sep/17 pass: 8,462; fail: 482; error: 12 Build 12: aarch64/2019/sep/21 pass: 8,467; fail: 478; error: 13 Build 13: aarch64/2019/oct/04 pass: 8,444; fail: 498; error: 16 Build 14: aarch64/2019/oct/17 pass: 8,452; fail: 493; error: 16 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/jun/05 pass: 3,908 Build 1: aarch64/2019/jun/15 pass: 3,908 Build 2: aarch64/2019/jun/27 pass: 3,908 Build 3: aarch64/2019/jul/02 pass: 3,908 Build 4: aarch64/2019/aug/03 pass: 3,908 Build 5: aarch64/2019/aug/10 pass: 3,909 Build 6: aarch64/2019/aug/15 pass: 3,909 Build 7: aarch64/2019/aug/22 pass: 3,909 Build 8: aarch64/2019/sep/04 pass: 3,910 Build 9: aarch64/2019/sep/05 pass: 3,910 Build 10: aarch64/2019/sep/10 pass: 3,910 Build 11: aarch64/2019/sep/17 pass: 3,910 Build 12: aarch64/2019/sep/21 pass: 3,910 Build 13: aarch64/2019/oct/04 pass: 3,910 Build 14: aarch64/2019/oct/17 pass: 3,910 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.38x Relative performance: Server critical-jOPS (nc): 8.17x 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: 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/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-06-05 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/156/results/ 2019-06-16 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/166/results/ 2019-06-28 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/178/results/ 2019-07-03 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/183/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/215/results/ 2019-08-11 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/222/results/ 2019-08-16 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/227/results/ 2019-08-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/234/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/247/results/ 2019-09-07 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/248/results/ 2019-09-11 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/253/results/ 2019-09-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/260/results/ 2019-09-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/264/results/ 2019-10-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/277/results/ 2019-10-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/290/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 Oct 19 01:00:39 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 19 Oct 2019 01:00:39 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <613730622.8356.1571446840627.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/291/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/03 pass: 5,732 Build 1: aarch64/2019/sep/05 pass: 5,733; fail: 1 Build 2: aarch64/2019/sep/09 pass: 5,734 Build 3: aarch64/2019/sep/11 pass: 5,736 Build 4: aarch64/2019/sep/13 pass: 5,737 Build 5: aarch64/2019/sep/16 pass: 5,726 Build 6: aarch64/2019/sep/18 pass: 5,727 Build 7: aarch64/2019/sep/20 pass: 5,728 Build 8: aarch64/2019/sep/23 pass: 5,727 Build 9: aarch64/2019/oct/07 pass: 5,750 Build 10: aarch64/2019/oct/09 pass: 5,747; fail: 1 Build 11: aarch64/2019/oct/11 pass: 5,751; fail: 1 Build 12: aarch64/2019/oct/14 pass: 5,753 Build 13: aarch64/2019/oct/16 pass: 5,753; fail: 1 Build 14: aarch64/2019/oct/18 pass: 5,760 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/03 pass: 8,679; fail: 512; error: 15 Build 1: aarch64/2019/sep/05 pass: 8,685; fail: 502; error: 19 Build 2: aarch64/2019/sep/09 pass: 8,679; fail: 510; error: 18 Build 3: aarch64/2019/sep/11 pass: 8,669; fail: 522; error: 18 Build 4: aarch64/2019/sep/13 pass: 8,678; fail: 514; error: 17 Build 5: aarch64/2019/sep/16 pass: 8,687; fail: 501; error: 21 Build 6: aarch64/2019/sep/18 pass: 8,675; fail: 517; error: 18 Build 7: aarch64/2019/sep/20 pass: 8,685; fail: 503; error: 22 Build 8: aarch64/2019/sep/23 pass: 8,696; fail: 497; error: 19 Build 9: aarch64/2019/oct/07 pass: 8,683; fail: 517; error: 18 Build 10: aarch64/2019/oct/09 pass: 8,692; fail: 507; error: 21 Build 11: aarch64/2019/oct/11 pass: 8,693; fail: 511; error: 18 Build 12: aarch64/2019/oct/14 pass: 8,706; fail: 497; error: 20 Build 13: aarch64/2019/oct/16 pass: 8,702; fail: 509; error: 17 Build 14: aarch64/2019/oct/18 pass: 8,694; fail: 522; error: 17 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/03 pass: 3,977 Build 1: aarch64/2019/sep/05 pass: 3,978 Build 2: aarch64/2019/sep/09 pass: 3,978 Build 3: aarch64/2019/sep/11 pass: 3,978 Build 4: aarch64/2019/sep/13 pass: 3,978 Build 5: aarch64/2019/sep/16 pass: 3,978 Build 6: aarch64/2019/sep/18 pass: 3,978 Build 7: aarch64/2019/sep/20 pass: 3,979 Build 8: aarch64/2019/sep/23 pass: 3,979 Build 9: aarch64/2019/oct/07 pass: 3,979 Build 10: aarch64/2019/oct/09 pass: 3,979 Build 11: aarch64/2019/oct/11 pass: 3,979 Build 12: aarch64/2019/oct/14 pass: 3,979 Build 13: aarch64/2019/oct/16 pass: 3,979 Build 14: aarch64/2019/oct/18 pass: 3,979 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.92x Relative performance: Server critical-jOPS (nc): 9.39x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-04 pass rate: 10488/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/240/results/ 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/246/results/ 2019-09-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/252/results/ 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ 2019-10-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/284/results/ 2019-10-15 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/287/results/ 2019-10-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/289/results/ 2019-10-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/291/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From Pengfei.Li at arm.com Mon Oct 21 09:55:58 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 21 Oct 2019 09:55:58 +0000 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl Message-ID: Hi, Please review this small patch on AArch64 codegen. JBS: https://bugs.openjdk.java.net/browse/JDK-8232591 Webrev: http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.00/ This adds AArch64 match rules for multiplying two 32-bit integers into a 64-bit long with an additional add/sub/neg-long operation. After this patch, AArch64 generated instructions like | smull x10, w1, w2 | add x0, x3, x10 are combined to | smaddl x0, w1, w2, x3 Generated instructions like | smull x10, w1, w2 | sub x0, x3, x10 are combined to | smsubl x0, w1, w2, x3 And generated instructions like | sxtw x11, w2 | sxtw x10, w1 | mneg x0, x11, x10 are combined to | smnegl x0, w2, w1 No new failure is found in full jtreg tests. No obvious performance difference can be seen after this patch. This just reduces the code size a little bit. -- Thanks, Pengfei From aph at redhat.com Mon Oct 21 14:15:52 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 21 Oct 2019 15:15:52 +0100 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: References: Message-ID: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> On 10/21/19 10:55 AM, Pengfei Li (Arm Technology China) wrote: > No new failure is found in full jtreg tests. No obvious performance difference can be seen after this patch. This just reduces the code size a little bit. The patch looks reasonable enough, but do any jtreg tests check for the corner cases, etc.? If not, please add some. -- 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 Oct 22 01:30:06 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 22 Oct 2019 01:30:06 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <890903846.10066.1571707807422.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/294/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/05 pass: 5,733; fail: 1 Build 1: aarch64/2019/sep/09 pass: 5,734 Build 2: aarch64/2019/sep/11 pass: 5,736 Build 3: aarch64/2019/sep/13 pass: 5,737 Build 4: aarch64/2019/sep/16 pass: 5,726 Build 5: aarch64/2019/sep/18 pass: 5,727 Build 6: aarch64/2019/sep/20 pass: 5,728 Build 7: aarch64/2019/sep/23 pass: 5,727 Build 8: aarch64/2019/oct/07 pass: 5,750 Build 9: aarch64/2019/oct/09 pass: 5,747; fail: 1 Build 10: aarch64/2019/oct/11 pass: 5,751; fail: 1 Build 11: aarch64/2019/oct/14 pass: 5,753 Build 12: aarch64/2019/oct/16 pass: 5,753; fail: 1 Build 13: aarch64/2019/oct/18 pass: 5,760 Build 14: aarch64/2019/oct/21 pass: 5,716; fail: 43; error: 1 44 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/05 pass: 8,685; fail: 502; error: 19 Build 1: aarch64/2019/sep/09 pass: 8,679; fail: 510; error: 18 Build 2: aarch64/2019/sep/11 pass: 8,669; fail: 522; error: 18 Build 3: aarch64/2019/sep/13 pass: 8,678; fail: 514; error: 17 Build 4: aarch64/2019/sep/16 pass: 8,687; fail: 501; error: 21 Build 5: aarch64/2019/sep/18 pass: 8,675; fail: 517; error: 18 Build 6: aarch64/2019/sep/20 pass: 8,685; fail: 503; error: 22 Build 7: aarch64/2019/sep/23 pass: 8,696; fail: 497; error: 19 Build 8: aarch64/2019/oct/07 pass: 8,683; fail: 517; error: 18 Build 9: aarch64/2019/oct/09 pass: 8,692; fail: 507; error: 21 Build 10: aarch64/2019/oct/11 pass: 8,693; fail: 511; error: 18 Build 11: aarch64/2019/oct/14 pass: 8,706; fail: 497; error: 20 Build 12: aarch64/2019/oct/16 pass: 8,702; fail: 509; error: 17 Build 13: aarch64/2019/oct/18 pass: 8,694; fail: 522; error: 17 Build 14: aarch64/2019/oct/21 pass: 8,705; fail: 512; error: 18 5 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/05 pass: 3,978 Build 1: aarch64/2019/sep/09 pass: 3,978 Build 2: aarch64/2019/sep/11 pass: 3,978 Build 3: aarch64/2019/sep/13 pass: 3,978 Build 4: aarch64/2019/sep/16 pass: 3,978 Build 5: aarch64/2019/sep/18 pass: 3,978 Build 6: aarch64/2019/sep/20 pass: 3,979 Build 7: aarch64/2019/sep/23 pass: 3,979 Build 8: aarch64/2019/oct/07 pass: 3,979 Build 9: aarch64/2019/oct/09 pass: 3,979 Build 10: aarch64/2019/oct/11 pass: 3,979 Build 11: aarch64/2019/oct/14 pass: 3,979 Build 12: aarch64/2019/oct/16 pass: 3,979 Build 13: aarch64/2019/oct/18 pass: 3,979 Build 14: aarch64/2019/oct/21 pass: 3,979 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.92x Relative performance: Server critical-jOPS (nc): 9.39x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/246/results/ 2019-09-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/252/results/ 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ 2019-10-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/284/results/ 2019-10-15 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/287/results/ 2019-10-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/289/results/ 2019-10-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/291/results/ 2019-10-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/294/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From Pengfei.Li at arm.com Tue Oct 22 09:50:29 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 22 Oct 2019 09:50:29 +0000 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> Message-ID: Hi, > The patch looks reasonable enough, but do any jtreg tests check for the > corner cases, etc.? > > If not, please add some. I don't find any jtreg cases testing these. I've created a jtreg and uploaded a new webrev, please see http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.01/ Is it good enough? -- Thanks, Pengfei From ci_notify at linaro.org Wed Oct 23 23:11:22 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 23 Oct 2019 23:11:22 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <587082393.10308.1571872282401.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/296/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/09 pass: 5,734 Build 1: aarch64/2019/sep/11 pass: 5,736 Build 2: aarch64/2019/sep/13 pass: 5,737 Build 3: aarch64/2019/sep/16 pass: 5,726 Build 4: aarch64/2019/sep/18 pass: 5,727 Build 5: aarch64/2019/sep/20 pass: 5,728 Build 6: aarch64/2019/sep/23 pass: 5,727 Build 7: aarch64/2019/oct/07 pass: 5,750 Build 8: aarch64/2019/oct/09 pass: 5,747; fail: 1 Build 9: aarch64/2019/oct/11 pass: 5,751; fail: 1 Build 10: aarch64/2019/oct/14 pass: 5,753 Build 11: aarch64/2019/oct/16 pass: 5,753; fail: 1 Build 12: aarch64/2019/oct/18 pass: 5,760 Build 13: aarch64/2019/oct/21 pass: 5,716; fail: 43; error: 1 Build 14: aarch64/2019/oct/23 pass: 5,760; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/09 pass: 8,679; fail: 510; error: 18 Build 1: aarch64/2019/sep/11 pass: 8,669; fail: 522; error: 18 Build 2: aarch64/2019/sep/13 pass: 8,678; fail: 514; error: 17 Build 3: aarch64/2019/sep/16 pass: 8,687; fail: 501; error: 21 Build 4: aarch64/2019/sep/18 pass: 8,675; fail: 517; error: 18 Build 5: aarch64/2019/sep/20 pass: 8,685; fail: 503; error: 22 Build 6: aarch64/2019/sep/23 pass: 8,696; fail: 497; error: 19 Build 7: aarch64/2019/oct/07 pass: 8,683; fail: 517; error: 18 Build 8: aarch64/2019/oct/09 pass: 8,692; fail: 507; error: 21 Build 9: aarch64/2019/oct/11 pass: 8,693; fail: 511; error: 18 Build 10: aarch64/2019/oct/14 pass: 8,706; fail: 497; error: 20 Build 11: aarch64/2019/oct/16 pass: 8,702; fail: 509; error: 17 Build 12: aarch64/2019/oct/18 pass: 8,694; fail: 522; error: 17 Build 13: aarch64/2019/oct/21 pass: 8,705; fail: 512; error: 18 Build 14: aarch64/2019/oct/23 pass: 8,712; fail: 505; error: 18 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/09 pass: 3,978 Build 1: aarch64/2019/sep/11 pass: 3,978 Build 2: aarch64/2019/sep/13 pass: 3,978 Build 3: aarch64/2019/sep/16 pass: 3,978 Build 4: aarch64/2019/sep/18 pass: 3,978 Build 5: aarch64/2019/sep/20 pass: 3,979 Build 6: aarch64/2019/sep/23 pass: 3,979 Build 7: aarch64/2019/oct/07 pass: 3,979 Build 8: aarch64/2019/oct/09 pass: 3,979 Build 9: aarch64/2019/oct/11 pass: 3,979 Build 10: aarch64/2019/oct/14 pass: 3,979 Build 11: aarch64/2019/oct/16 pass: 3,979 Build 12: aarch64/2019/oct/18 pass: 3,979 Build 13: aarch64/2019/oct/21 pass: 3,979 Build 14: aarch64/2019/oct/23 pass: 3,980 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.92x Relative performance: Server critical-jOPS (nc): 9.39x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 201.64 Server 201.64 / Server 2014-04-01 (71.00): 2.84x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/252/results/ 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ 2019-10-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/284/results/ 2019-10-15 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/287/results/ 2019-10-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/289/results/ 2019-10-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/291/results/ 2019-10-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/294/results/ 2019-10-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/296/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Fri Oct 25 13:11:23 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Oct 2019 14:11:23 +0100 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> Message-ID: <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> On 10/22/19 10:50 AM, Pengfei Li (Arm Technology China) wrote: > I don't find any jtreg cases testing these. I've created a jtreg and uploaded a new webrev, please see > http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.01/ > > Is it good enough? Yes, I think so. It's enough to make sure that the corner cases and overflows are handled correctly. We have to be sure that we really are generating the correct instructions. 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 Oct 25 14:42:18 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Oct 2019 15:42:18 +0100 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> Message-ID: <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> On 10/25/19 2:11 PM, Andrew Haley wrote: > On 10/22/19 10:50 AM, Pengfei Li (Arm Technology China) wrote: >> I don't find any jtreg cases testing these. I've created a jtreg and uploaded a new webrev, please see >> http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.01/ >> >> Is it good enough? > > Yes, I think so. It's enough to make sure that the corner cases and overflows > are handled correctly. We have to be sure that we really are generating the > correct instructions. Thanks. By the way, I also checked with this Case: new Case(0xffffffff, 0xffffffff, 0xffffffffeL << 32, 0xfffffffe00000001L, 0xfffffffdffffffffL, -1L), which tests the carries frm highpart to lowpart. (It's the result of 0xffffffff * 0xffffffff == 0xfffffffe00000001.) -- 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 felix.yang at huawei.com Mon Oct 28 06:11:53 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 28 Oct 2019 06:11:53 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> Message-ID: Ping... Is that enough for us to push the 8u backport patch ? It still applies: http://cr.openjdk.java.net/~fyang/8209835-8u-backport/webrev.00/ Thanks, Felix > -----Original Message----- > From: Yangfei (Felix) > Sent: Friday, October 11, 2019 11:41 AM > To: 'Andrew Haley' ; aarch64-port-dev at openjdk.java.net > Subject: RE: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on > all volatile operations > > > On 8/28/19 11:39 AM, Yangfei (Felix) wrote: > > >> Having said that, I can sort-of imagine a jcstress failure if we > > >> had a test that > > was doing compareAndSwap in one thread and getAndSet in another. That > > would be a seriously compelling reason for a backport! > > > Can you elaborate more please? especially the possible code sequence. > > > > > > Currently, we have C2 JIT for getAndSet like this: > > > > > > 33 ;; membar_release > > > 34 0x0000ffffa416ae74: dmb ish > > > 35 ;; 0x40000000000 > > > 36 0x0000ffffa416ae78: orr x11, xzr, #0x40000000000 > > > 37 0x0000ffffa416ae7c: add x10, x1, #0x10 > > > 38 0x0000ffffa416ae80: prfm pstl1strm, [x10] > > > 39 0x0000ffffa416ae84: ldxr x9, [x10] > > > 40 0x0000ffffa416ae88: stxr w8, x11, [x10] > > > 41 0x0000ffffa416ae8c: cbnz w8, 0x0000ffffa416ae84 > > > 42 0x0000ffffa416ae90: mov x10, x9 > > > 43 ;; membar_acquire > > > 44 0x0000ffffa416ae94: dmb ishld ;*invokevirtual > > getAndSetLong > > > > The important thing is that there should be a StoreLoad barrier > > between a volatile store and a volatile load. If we have a getAndSet > > followed by a CompareAndExchange that might not happen. > > > > Hi, > > Sorry for the late reply. > After some searching in jcstress code, I think the following test might be the > test you wanted to see. > > > org.openjdk.jcstress.tests.atomics.longs.AtomicLongArrayPairwiseTests.GetA > ndSet_CAS > > 43 @State > 44 public static class S { > 45 public final int SIZE = 256; // double the maximum cache line > 46 public final AtomicLongArray a = new AtomicLongArray(SIZE); > 47 public final int idx = ThreadLocalRandom.current().nextInt(SIZE); > 48 } > > 445 @JCStressTest > 446 @JCStressMeta(G.class) > 447 @Outcome(id = "0, 10", expect = Expect.ACCEPTABLE, desc = "T1 -> > T2 execution") > 448 @Outcome(id = "20, 20", expect = Expect.ACCEPTABLE, desc = "T2 -> > T1 execution") > 449 public static class GetAndSet_CAS { > 450 @Actor public void actor1(S s, LongResult2 r) { r.r1 = > s.a.getAndSet(s.idx, 5); } > 451 @Actor public void actor2(S s, LongResult2 r) { r.r2 = > s.a.compareAndSet(s.idx, 0, 20) ? 20 : 10; } > 452 } > > AtomicLongArray.getAndSet calls unsafe.getAndSetLong and > AtomicLongArray.compareAndSet calls compareAndSetRaw which calls > unsafe.compareAndSwapLong. > For this test, one thread will do actor1 method. And another thread will do > actor2 method concurrently. > > Thanks, > Felix From Pengfei.Li at arm.com Mon Oct 28 09:48:31 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 28 Oct 2019 09:48:31 +0000 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> Message-ID: Hi, > > Yes, I think so. It's enough to make sure that the corner cases and > > overflows are handled correctly. We have to be sure that we really are > > generating the correct instructions. Thanks. > > By the way, I also checked with this Case: > > new Case(0xffffffff, 0xffffffff, 0xffffffffeL << 32, 0xfffffffe00000001L, > 0xfffffffdffffffffL, -1L), > > which tests the carries frm highpart to lowpart. > (It's the result of 0xffffffff * 0xffffffff == 0xfffffffe00000001.) Thanks for review. I've appended this case in my jtreg. See updated webrev: http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.02/ Is another reviewer required for this change? If not, @Ningsheng Jian (Arm Technology China) could you help to push? -- Thanks, Pengfei From ci_notify at linaro.org Tue Oct 29 02:32:49 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 29 Oct 2019 02:32:49 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <582227386.10773.1572316369967.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/301/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/11 pass: 5,736 Build 1: aarch64/2019/sep/13 pass: 5,737 Build 2: aarch64/2019/sep/16 pass: 5,726 Build 3: aarch64/2019/sep/18 pass: 5,727 Build 4: aarch64/2019/sep/20 pass: 5,728 Build 5: aarch64/2019/sep/23 pass: 5,727 Build 6: aarch64/2019/oct/07 pass: 5,750 Build 7: aarch64/2019/oct/09 pass: 5,747; fail: 1 Build 8: aarch64/2019/oct/11 pass: 5,751; fail: 1 Build 9: aarch64/2019/oct/14 pass: 5,753 Build 10: aarch64/2019/oct/16 pass: 5,753; fail: 1 Build 11: aarch64/2019/oct/18 pass: 5,760 Build 12: aarch64/2019/oct/21 pass: 5,716; fail: 43; error: 1 Build 13: aarch64/2019/oct/23 pass: 5,760; fail: 1 Build 14: aarch64/2019/oct/28 pass: 5,766 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/11 pass: 8,669; fail: 522; error: 18 Build 1: aarch64/2019/sep/13 pass: 8,678; fail: 514; error: 17 Build 2: aarch64/2019/sep/16 pass: 8,687; fail: 501; error: 21 Build 3: aarch64/2019/sep/18 pass: 8,675; fail: 517; error: 18 Build 4: aarch64/2019/sep/20 pass: 8,685; fail: 503; error: 22 Build 5: aarch64/2019/sep/23 pass: 8,696; fail: 497; error: 19 Build 6: aarch64/2019/oct/07 pass: 8,683; fail: 517; error: 18 Build 7: aarch64/2019/oct/09 pass: 8,692; fail: 507; error: 21 Build 8: aarch64/2019/oct/11 pass: 8,693; fail: 511; error: 18 Build 9: aarch64/2019/oct/14 pass: 8,706; fail: 497; error: 20 Build 10: aarch64/2019/oct/16 pass: 8,702; fail: 509; error: 17 Build 11: aarch64/2019/oct/18 pass: 8,694; fail: 522; error: 17 Build 12: aarch64/2019/oct/21 pass: 8,705; fail: 512; error: 18 Build 13: aarch64/2019/oct/23 pass: 8,712; fail: 505; error: 18 Build 14: aarch64/2019/oct/28 pass: 8,711; fail: 509; error: 18 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/11 pass: 3,978 Build 1: aarch64/2019/sep/13 pass: 3,978 Build 2: aarch64/2019/sep/16 pass: 3,978 Build 3: aarch64/2019/sep/18 pass: 3,978 Build 4: aarch64/2019/sep/20 pass: 3,979 Build 5: aarch64/2019/sep/23 pass: 3,979 Build 6: aarch64/2019/oct/07 pass: 3,979 Build 7: aarch64/2019/oct/09 pass: 3,979 Build 8: aarch64/2019/oct/11 pass: 3,979 Build 9: aarch64/2019/oct/14 pass: 3,979 Build 10: aarch64/2019/oct/16 pass: 3,979 Build 11: aarch64/2019/oct/18 pass: 3,979 Build 12: aarch64/2019/oct/21 pass: 3,979 Build 13: aarch64/2019/oct/23 pass: 3,980 Build 14: aarch64/2019/oct/28 pass: 3,980 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 8.04x Relative performance: Server critical-jOPS (nc): 9.15x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/254/results/ 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ 2019-10-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/284/results/ 2019-10-15 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/287/results/ 2019-10-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/289/results/ 2019-10-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/291/results/ 2019-10-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/294/results/ 2019-10-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/296/results/ 2019-10-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/301/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From aph at redhat.com Tue Oct 29 08:29:12 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Oct 2019 08:29:12 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> Message-ID: <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> On 10/28/19 6:11 AM, Yangfei (Felix) wrote: > Ping... > Is that enough for us to push the 8u backport patch ? > It still applies: http://cr.openjdk.java.net/~fyang/8209835-8u-backport/webrev.00/ Does this change fix any bugs? Does this change make a significant performance improvement? It is not a low-risk change and I'm not sure it's worth it. Andrew Dinn, what do you think? -- 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 Jie.He at arm.com Tue Oct 29 09:33:29 2019 From: Jie.He at arm.com (Jie He (Arm Technology China)) Date: Tue, 29 Oct 2019 09:33:29 +0000 Subject: [aarch64-port-dev ] unimplemented code patching in AARCH64 Message-ID: Hi Recently, I noticed some deoptimization in AARCH64, but not in X86, and found that when OSR compiled code encounter unresolved filed or not-loaded yet class, it has to initial a deoptimization. but in X86, it will do a code patching instead. so I realized the different SMC rules (ARM ARM b2.2.5) between x86 and AARCH64. It makes hard to do the same thing like X86 did. I also noticed Andrew Dinn reported the performance issue of case TestLongVect in AARCH64, which caused by too much deoptimization in aarch64, and the similar case TestByteVect doesn't happen because the function test() couldn't enter OSR due to its byte code size (> 8000). Details pls refer to [1]. and I think there are at least 2 options to implement the code patching in aarch64. 1, replace the origin jump to patch stub with a new jump to the patched code, no code copy any more, it could conform with b2.2.5. 2, move the jump address and patching data into a data section, let compiled code to be address independent code, like fPIC did, at first time launch, jump address should point to patch stub, and patching data is 0, after oop resolving, patching data should become oop address/offset, and jump address should become to loading code address. At the same time, I implement a workaround by changes in patchingstub, patch_code, to fix the TestLongVect according to option 1, which only fixes the part of code patching issues exposed by this test case, but still further tests are necessary for correctness. Finally, I'm not sure if it is worth doing, because in general OSR shouldn't impact the real workload. But fixing it could bring the unified behavior between aarch64 and other platforms. [1]. http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-August/007876.html B.R Jie He From aph at redhat.com Tue Oct 29 09:33:23 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Oct 2019 09:33:23 +0000 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> Message-ID: <5fe09111-cd87-cb53-19ac-e45367a5d490@redhat.com> On 10/28/19 9:48 AM, Pengfei Li (Arm Technology China) wrote: > Is another reviewer required for this change? If not, @Ningsheng Jian (Arm Technology China) could you help to push? Please push. -- 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 patrick at os.amperecomputing.com Tue Oct 29 09:58:54 2019 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Tue, 29 Oct 2019 09:58:54 +0000 Subject: [aarch64-port-dev ] RFR: 8229351: AArch64: Make the stub threshold of string_compare intrinsic tunable Message-ID: Hi, Could you please review this patch, thanks. JBS: https://bugs.openjdk.java.net/browse/JDK-8229351 Webrev: http://cr.openjdk.java.net/~qpzhang/8229351/webrev.02 (this starts from .02 since there had been some internal review and updates) Changes: 1. Split the STUB_THRESHOLD from the hard-coded 72 to be CompareLongStringLimitLatin and CompareLongStringLimitUTF as a more flexible control over the stub thresholds for string_compare intrinsics, especially for various uArchs. 2. MacroAssembler::string_compare LL and UU shared the same threshold, actually UU may only require the half (length of chars) of that of LL's, because one character has two-bytes for UU, while for compacted LL strings, one character means one byte. In addition, LU/UL may need a separated threshold, as the stub function is different from the same encoding one, and the performance may vary as well. 3. In generate_compare_long_string_same_encoding, the hard-coded 72 was originally able to ensure that there can be always 64 bytes at least for the prefetch code path. However once a smaller stub threshold is set, a new condition is needed to tell if this would be still valid, or has to go to the NO_PREFETCH branch. This change can ensure the correctness. 4. In generate_compare_long_string_different_encoding, some temp vars for handling the last 4 characters are not valid any longer, cleaned up strU and strL, and related pointers initialization to the next U (cnt1) and L (tmp2). 5. In compare_string_16_x_LU, the reference to r10 (tmp1) is not needed, as tmpU or tmpL point to the same register. Tests: 1. For function check, I have run jdk jtreg tier1 tests, with default vm flags hotspot jtreg tests: runtime/compiler/gc parts, with "-Xcomp -XX:-TieredCompilation" jck10/api/java.lang 1609 cases and other selected modules, no new failures found, with default vm flags and "-Xcomp -XX:-TieredCompilation" respectively; some specific test cases had been carefully executed to double check, i.e., TestStringCompareToDifferentLength.java [1] and TestStringCompareToDifferentLength.java [1] introduced by [2], StrCmpTest.java [3] introduced by [4]. 1. For performance check, I have run string-density-bench/CompareToBench.java [5] and StringCompareBench.java [6] respectively, and SPECjbb2015.jar, no obvious performance change has been found (since the default threshold is NOT changed within this patch). FYI. with Ampere eMAG system, microbenchmarks [5][6] can have 1.5x consistent perf gain with LU/UL comparison for shorter strings (<72 chars, smaller stub thresholds), and slight improvement (5~10%) with LL/UU cases. Refs: [1] http://hg.openjdk.java.net/jdk/jdk/file/3df2bf731a87/test/hotspot/jtreg/compiler/intrinsics/string [2] https://bugs.openjdk.java.net/browse/JDK-8218966 AArch64: String.compareTo() can read memory after string [3] http://cr.openjdk.java.net/~dpochepk/8202326/StrCmpTest.java, contributed by Dmitrij Pochepko [4] https://bugs.openjdk.java.net/browse/JDK-8202326 AARCH64: optimize string compare intrinsic [5] http://cr.openjdk.java.net/~shade/density/string-density-bench.jar, contributed by Aleksey Shipilev [6] http://cr.openjdk.java.net/~dpochepk/8202326/StringCompareBench.java, contributed by Dmitrij Pochepko Regards Patrick From felix.yang at huawei.com Tue Oct 29 10:04:24 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 29 Oct 2019 10:04:24 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> Message-ID: Actually, I didn't see a real world problem related to this. As you mentioned before, there should be a StoreLoad barrier between a volatile store and a volatile load. I agree with that and I didn't see this kind of barrier when we have a getAndSet followed by a CompareAndSwap. I just worried that developers may create code that relies on this memory model requirement. Currently we have C2 JIT for getAndSetLong like: 33 ;; membar_release 34 0x0000ffffa416ae74: dmb ish 35 ;; 0x40000000000 36 0x0000ffffa416ae78: orr x11, xzr, #0x40000000000 37 0x0000ffffa416ae7c: add x10, x1, #0x10 38 0x0000ffffa416ae80: prfm pstl1strm, [x10] 39 0x0000ffffa416ae84: ldxr x9, [x10] 40 0x0000ffffa416ae88: stxr w8, x11, [x10] <======== 41 0x0000ffffa416ae8c: cbnz w8, 0x0000ffffa416ae84 <======== 42 0x0000ffffa416ae90: mov x10, x9 43 ;; membar_acquire 44 0x0000ffffa416ae94: dmb ishld ;*invokevirtual getAndSetLong And C2 JIT for compareAndSwapLong like: 433 0x0000ffffa6695088: ldaxr x8, [x10] 434 0x0000ffffa669508c: cmp x8, x3 435 0x0000ffffa6695090: b.ne 0x0000ffffa669509c 436 0x0000ffffa6695094: stlxr w8, x4, [x10] 437 0x0000ffffa6695098: cbnz w8, 0x0000ffffa6695088 438 0x0000ffffa669509c: cset x0, eq ;*invokevirtual compareAndSwapLong Thanks, Felix > > On 10/28/19 6:11 AM, Yangfei (Felix) wrote: > > Ping... > > Is that enough for us to push the 8u backport patch ? > > It still applies: > > http://cr.openjdk.java.net/~fyang/8209835-8u-backport/webrev.00/ > > Does this change fix any bugs? > > Does this change make a significant performance improvement? > > It is not a low-risk change and I'm not sure it's worth it. > Andrew Dinn, what do you think? > > -- > 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 adinn at redhat.com Tue Oct 29 11:12:04 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 29 Oct 2019 11:12:04 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> Message-ID: On 29/10/2019 10:04, Yangfei (Felix) wrote: > Actually, I didn't see a real world problem related to this. > As you mentioned before, there should be a StoreLoad barrier between a volatile store and a volatile load. > I agree with that and I didn't see this kind of barrier when we have a getAndSet followed by a CompareAndSwap. > I just worried that developers may create code that relies on this memory model requirement. . . . >> Does this change make a significant performance improvement? >> >> It is not a low-risk change and I'm not sure it's worth it. >> Andrew Dinn, what do you think? Yes, it's a risk trade off. Felix is right that there is a real risk here. Programmers could legitimately write a program using a combination of getAndSetXXX followed by a CompareAndSwapXXX,expect it to work as advertised but run into problems because of the current implementation. However, no one has done that yet (as far as we know). The question is what is being traded off. I am not sure the risk from the patch is very large. The code being relied on to detect and apply the new rules is Roland's modified predicates that detect the need for acquire/release semantics at a load/store. They are aided and abetted in identifying the accompanying leading and trailing membars by generic code; in other words they are not relying on the old shape-related predicates that were always very fragile. Also, these predicates and the corresponding rule changes are in use (and have baked) upstream in jdk11u+ to handle the proposed new translations and are already in use (and have baked) in jdk8u to handle the existing translations for volatile operations. So, I think the risk of breakage from introducing the patch is low. On the other hand the danger of sticking to the status is arguably theoretical. On the face of it, it seems unlikely that code is going to mix these two operations on the same object field. I am not sure I'd like to be held to that though. Nor do I relish trying to work out that this is the problem if someone does run into it (nor would that unlucky someone be very happy, I suspect). So, on balance I think it's probably worth pushing this change just in case it does hit someone and we end up having to deal with the fallout. 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 ningsheng.jian at arm.com Wed Oct 30 01:22:55 2019 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 30 Oct 2019 09:22:55 +0800 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: <5fe09111-cd87-cb53-19ac-e45367a5d490@redhat.com> References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> <5fe09111-cd87-cb53-19ac-e45367a5d490@redhat.com> Message-ID: <39e04e57-74a5-138e-1b87-e8b3f5bc4d50@arm.com> Pushed. On 10/29/19 5:33 PM, Andrew Haley wrote: > On 10/28/19 9:48 AM, Pengfei Li (Arm Technology China) wrote: >> Is another reviewer required for this change? If not, @Ningsheng Jian (Arm Technology China) could you help to push? > > Please push. > Thanks, Ningsheng From aph at redhat.com Wed Oct 30 17:17:13 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Oct 2019 17:17:13 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> Message-ID: On 10/29/19 11:12 AM, Andrew Dinn wrote: > So, on balance I think it's probably worth pushing this change just in > case it does hit someone and we end up having to deal with the fallout. OK, I can live with 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 Wed Oct 30 17:19:45 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Oct 2019 17:19:45 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> Message-ID: <7046e0e1-492d-1157-8e68-a8261bcb01e7@redhat.com> On 10/29/19 10:04 AM, Yangfei (Felix) wrote: > Currently we have C2 JIT for getAndSetLong like: > 33 ;; membar_release > 34 0x0000ffffa416ae74: dmb ish > 35 ;; 0x40000000000 > 36 0x0000ffffa416ae78: orr x11, xzr, #0x40000000000 > 37 0x0000ffffa416ae7c: add x10, x1, #0x10 > 38 0x0000ffffa416ae80: prfm pstl1strm, [x10] > 39 0x0000ffffa416ae84: ldxr x9, [x10] > 40 0x0000ffffa416ae88: stxr w8, x11, [x10] <======== > 41 0x0000ffffa416ae8c: cbnz w8, 0x0000ffffa416ae84 <======== > 42 0x0000ffffa416ae90: mov x10, x9 > 43 ;; membar_acquire > 44 0x0000ffffa416ae94: dmb ishld ;*invokevirtual getAndSetLong > > > And C2 JIT for compareAndSwapLong like: > 433 0x0000ffffa6695088: ldaxr x8, [x10] > 434 0x0000ffffa669508c: cmp x8, x3 > 435 0x0000ffffa6695090: b.ne 0x0000ffffa669509c > 436 0x0000ffffa6695094: stlxr w8, x4, [x10] > 437 0x0000ffffa6695098: cbnz w8, 0x0000ffffa6695088 > 438 0x0000ffffa669509c: cset x0, eq ;*invokevirtual compareAndSwapLong I think this is actually safe whichever order these occur in. However, we might as well generate ldaxr/stlxr everywhere. -- 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 Wed Oct 30 18:58:54 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Oct 2019 18:58:54 +0000 Subject: [aarch64-port-dev ] RFD: scratch registers cleanup [Long post] Message-ID: <3e4aaf79-59a9-b346-e6b0-69839acf723e@redhat.com> [TL, DR: A large patch to clean up the use of scratch registers in the AArch64 port. Anyone who has ever written assembly code for the AArch64 port should probably read this.] In AArch64 HotSpot we reserve two scratch registers for general use and especially for use in macros. When we first wrote the port things were fairly simple: low-level assembler macros would use these registers freely and any macro that calls a macro would have to be aware that rscratch1 and rscratch2 would be clobbered. However, things haven't quite worked out that way. In practice people "know" that the macro WhizzyMacro they're using only clobbers rscratch1 and so rscratch2 will be "safe" and its contents will be preserved across WhizzyMacro. The danger of this is obvious: a maintenance programmer less familiar with the code base will come along and use some other registers. This is particularly problematic when a macro is used in many places, and if there are several versions of a macro, as happens in the case of GC barriers. There is another risk: aliasing, the extreme sport of referring to the same register in a macro by more than one name. Again, the risk is obvious: the poor programmer won't know that the registers "tmp" and "rscratch2" are in fact the same register. And there is the most excitingly risky practice of all, where an input operand to WhizzyMacro is passed in one of the scratch registers *by a different name* and WhizzyMacro also freely uses the same scratch register by its generic name. This has caused some programmers to confuse themselves about the code they were writing *while they were writing it*. Please do not do this. It is the road to perdition. Bear in mind that it is sometimes convenient to avoid declaring scratch registers in macros altogether. You can do this by passing all of the temporary registers a macro needs explicitly as arguments, and this can make the code smaller and simpler. Despite all of the foregoing, I still believe that reserving a couple of scratch registers was a good idea, but we need to clarify rules of ownership so that it is always clear to the reader who "owns" which scratch registers. Sometimes this is informally documented in comments, often not. I propose to mitigate this problem by removing the global declarations of rscratch1 and rscratch2 altogether and instead requiring them to be declared at the point of use. The Assembler will keep track of which registers are in use and which are free. For example, to use rscratch1 declare it thusly: ScratchRegister rscratch1(__ as(), r8); After this declaration rscratch1 may be used until the end of the innermost enclosing scope, like so: { ScratchRegister rscratch1(__ as(), r8); __ ldrb(rscratch1, gc_state); __ tbz(rscratch1, ShenandoahHeap::MARKING_BITPOS, done); } [NB: it is possible to give the scratch register a name other than rscratch1, but please don't!] Let's say you need to call InnerMacro from WhizzyMacro, and both InnerMacro and WhizzyMacro need scratch registers. You can do this by explicitly freeing the scratch registers, like so: WhizzyMacro() { ... ScratchRegister rscratch1(__ as(), r8); // Code using rscratch1 ... { FreeScratchRegs dummy(__ as()); __ InnerMacro(); // Try to use rscratch1 here and you'll get an assertion // because you don't own it. } // You can use rscratch1 again here. ... } In this case it is clear to the reader that InnerMacro() may clobber both scratch registers. At the end of the scope of FreeScratchRegs, rscratch1 is again owned by WhizzyMacro. I've written a prototype of this idea which does not (intentionally) change any of the generated code, it just documents what it does, and it enforces it. Anyone who uses a register way which conflicts with what has been declared will get an assertion failure. In a few special cases in this prototype I haven't attempted to use the new syntax. The interpreter has its own convention for register usage so scattering ScratchRegister declarations wouldn't much help. Likewise in aarch64.ad: many instruction patterns wouldn't benefit from such declarations because scratch registers are always free to use in patterns, but be careful if the patterns call macros. In that case you should probably declare the scratch registers you use. Some of the resulting patch looks gnarly and complex, but that's just the way that the existing code is structured, I'm just documenting it. The code itself probably could be rewritten to make things simpler and cleaner, but not as part of this patch. Webrev at http://cr.openjdk.java.net/~aph/scratch-regs/webrev/ I'm thinking of disabling register ownership checking in release builds and release branches because I don't want assertions to trigger in production systems and cause the VM to abort. We should leave it on in debug builds and the development trunk. Finally, I'm not wedded to the current syntax for declarations: I can think of some nicer ways to do it so that you could say use_scratch(rscratch1); rather than ScratchRegister rscratch1(__ as(), r8); Comments gratefully received. -- 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 Wed Oct 30 20:42:36 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Oct 2019 20:42:36 +0000 Subject: [aarch64-port-dev ] unimplemented code patching in AARCH64 In-Reply-To: References: Message-ID: <6a5699ee-6129-6300-8066-5d8418a60b94@redhat.com> On 10/29/19 9:33 AM, Jie He (Arm Technology China) wrote: > Recently, I noticed some deoptimization in AARCH64, but not in X86, > and found that when OSR compiled code encounter unresolved filed or > not-loaded yet class, it has to initial a deoptimization. but in > X86, it will do a code patching instead. so I realized the different > SMC rules (ARM ARM b2.2.5) between x86 and AARCH64. It makes hard to > do the same thing like X86 did. Yes, and I don't believe we should. Hot-patching live code is fraught with problems, and if we can recompile we should. > I also noticed Andrew Dinn reported > the performance issue of case TestLongVect in AARCH64, which caused > by too much deoptimization in aarch64, and the similar case > TestByteVect doesn't happen because the function test() couldn't > enter OSR due to its byte code size (> 8000). Details pls refer to > [1]. > > and I think there are at least 2 options to implement the code > patching in aarch64. > 1, replace the origin jump to patch stub with a new jump to the > patched code, no code copy any more, it could conform with b2.2.5. Possibly. > 2, move the jump address and patching data into a data section, let > compiled code to be address independent code, like fPIC did, at > first time launch, jump address should point to patch stub, and > patching data is 0, after oop resolving, patching data should become > oop address/offset, and jump address should become to loading code > address. That seems like a rather extreme solution. > At the same time, I implement a workaround by changes in > patchingstub, patch_code, to fix the TestLongVect according to > option 1, which only fixes the part of code patching issues exposed > by this test case, but still further tests are necessary for > correctness. > > Finally, I'm not sure if it is worth doing, because in general OSR > shouldn't impact the real workload. But fixing it could bring the > unified behavior between aarch64 and other platforms. My thinking goes like this: proving that patching is safe is difficult. The AArch64 rules are strict but have not yet been formalized, and I know that we're doing some thing that I believe are safe in practice but may not fully accord with the rules. I have measured that deoptimization and recompilation due to situations that would cause patching on x86 is only about 10% of all recompilation events. 90% is due to tiered compilation events, where C1 code is recompiled to C2. By not patching C1-compiled code we're making things simpler and safer. IMO, x86 could do the same and no-one would ever notice. > [1]. http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-August/007876.html This one should be investigated some more. It looks like a bug. -- 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 felix.yang at huawei.com Thu Oct 31 03:03:06 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 31 Oct 2019 03:03:06 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <7046e0e1-492d-1157-8e68-a8261bcb01e7@redhat.com> References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> <7046e0e1-492d-1157-8e68-a8261bcb01e7@redhat.com> Message-ID: > On 10/29/19 10:04 AM, Yangfei (Felix) wrote: > > Currently we have C2 JIT for getAndSetLong like: > > 33 ;; membar_release > > 34 0x0000ffffa416ae74: dmb ish > > 35 ;; 0x40000000000 > > 36 0x0000ffffa416ae78: orr x11, xzr, #0x40000000000 > > 37 0x0000ffffa416ae7c: add x10, x1, #0x10 > > 38 0x0000ffffa416ae80: prfm pstl1strm, [x10] > > 39 0x0000ffffa416ae84: ldxr x9, [x10] > > 40 0x0000ffffa416ae88: stxr w8, x11, [x10] > <======== > > 41 0x0000ffffa416ae8c: cbnz w8, 0x0000ffffa416ae84 > <======== > > 42 0x0000ffffa416ae90: mov x10, x9 > > 43 ;; membar_acquire > > 44 0x0000ffffa416ae94: dmb ishld ;*invokevirtual > getAndSetLong > > > > > > And C2 JIT for compareAndSwapLong like: > > 433 0x0000ffffa6695088: ldaxr x8, [x10] > > 434 0x0000ffffa669508c: cmp x8, x3 > > 435 0x0000ffffa6695090: b.ne 0x0000ffffa669509c > > 436 0x0000ffffa6695094: stlxr w8, x4, [x10] > > 437 0x0000ffffa6695098: cbnz w8, 0x0000ffffa6695088 > > 438 0x0000ffffa669509c: cset x0, eq ;*invokevirtual > compareAndSwapLong > > I think this is actually safe whichever order these occur in. However, we might > as well generate ldaxr/stlxr everywhere. Thanks. Will push. My thoughts about the risk: Suppose we have T1 executing getAndSetLong on Core1 and T2 executing compareAndSwapLong on Core2. Consider execution order: T1 - > T2 The stxr of the getAndSetLong sequence executed on T1/Core1 may not be observed by T2/Core2. The dmb ishld at the end of the getAndSetLong sequence does not ensure the visibility of the stxr, according to the architecture manual. Felix From ci_notify at linaro.org Thu Oct 31 03:49:03 2019 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 31 Oct 2019 03:49:03 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1502913159.10974.1572493744022.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/jdkX/openjdk-jtreg-nightly-tests/summary/2019/303/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/13 pass: 5,737 Build 1: aarch64/2019/sep/16 pass: 5,726 Build 2: aarch64/2019/sep/18 pass: 5,727 Build 3: aarch64/2019/sep/20 pass: 5,728 Build 4: aarch64/2019/sep/23 pass: 5,727 Build 5: aarch64/2019/oct/07 pass: 5,750 Build 6: aarch64/2019/oct/09 pass: 5,747; fail: 1 Build 7: aarch64/2019/oct/11 pass: 5,751; fail: 1 Build 8: aarch64/2019/oct/14 pass: 5,753 Build 9: aarch64/2019/oct/16 pass: 5,753; fail: 1 Build 10: aarch64/2019/oct/18 pass: 5,760 Build 11: aarch64/2019/oct/21 pass: 5,716; fail: 43; error: 1 Build 12: aarch64/2019/oct/23 pass: 5,760; fail: 1 Build 13: aarch64/2019/oct/28 pass: 5,766 Build 14: aarch64/2019/oct/30 pass: 5,768 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/13 pass: 8,678; fail: 514; error: 17 Build 1: aarch64/2019/sep/16 pass: 8,687; fail: 501; error: 21 Build 2: aarch64/2019/sep/18 pass: 8,675; fail: 517; error: 18 Build 3: aarch64/2019/sep/20 pass: 8,685; fail: 503; error: 22 Build 4: aarch64/2019/sep/23 pass: 8,696; fail: 497; error: 19 Build 5: aarch64/2019/oct/07 pass: 8,683; fail: 517; error: 18 Build 6: aarch64/2019/oct/09 pass: 8,692; fail: 507; error: 21 Build 7: aarch64/2019/oct/11 pass: 8,693; fail: 511; error: 18 Build 8: aarch64/2019/oct/14 pass: 8,706; fail: 497; error: 20 Build 9: aarch64/2019/oct/16 pass: 8,702; fail: 509; error: 17 Build 10: aarch64/2019/oct/18 pass: 8,694; fail: 522; error: 17 Build 11: aarch64/2019/oct/21 pass: 8,705; fail: 512; error: 18 Build 12: aarch64/2019/oct/23 pass: 8,712; fail: 505; error: 18 Build 13: aarch64/2019/oct/28 pass: 8,711; fail: 509; error: 18 Build 14: aarch64/2019/oct/30 pass: 8,723; fail: 504; error: 19 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/13 pass: 3,978 Build 1: aarch64/2019/sep/16 pass: 3,978 Build 2: aarch64/2019/sep/18 pass: 3,978 Build 3: aarch64/2019/sep/20 pass: 3,979 Build 4: aarch64/2019/sep/23 pass: 3,979 Build 5: aarch64/2019/oct/07 pass: 3,979 Build 6: aarch64/2019/oct/09 pass: 3,979 Build 7: aarch64/2019/oct/11 pass: 3,979 Build 8: aarch64/2019/oct/14 pass: 3,979 Build 9: aarch64/2019/oct/16 pass: 3,979 Build 10: aarch64/2019/oct/18 pass: 3,979 Build 11: aarch64/2019/oct/21 pass: 3,979 Build 12: aarch64/2019/oct/23 pass: 3,980 Build 13: aarch64/2019/oct/28 pass: 3,980 Build 14: aarch64/2019/oct/30 pass: 3,980 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 8.01x Relative performance: Server critical-jOPS (nc): 9.85x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-14 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/256/results/ 2019-09-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/259/results/ 2019-09-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/261/results/ 2019-09-21 pass rate: 10487/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/263/results/ 2019-09-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/266/results/ 2019-10-08 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/280/results/ 2019-10-10 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/282/results/ 2019-10-12 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/284/results/ 2019-10-15 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/287/results/ 2019-10-17 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/289/results/ 2019-10-19 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/291/results/ 2019-10-22 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/294/results/ 2019-10-23 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/296/results/ 2019-10-29 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/301/results/ 2019-10-31 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2019/303/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From nick.gasson at arm.com Thu Oct 31 08:04:23 2019 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 31 Oct 2019 16:04:23 +0800 Subject: [aarch64-port-dev ] RFD: scratch registers cleanup [Long post] In-Reply-To: <3e4aaf79-59a9-b346-e6b0-69839acf723e@redhat.com> References: <3e4aaf79-59a9-b346-e6b0-69839acf723e@redhat.com> Message-ID: <6c5aab62-d110-6b76-c27d-a242ce9c44d0@arm.com> Hi Andrew, In general I think this is an improvement. I've put some comments below. > > However, things haven't quite worked out that way. In practice people > "know" that the macro WhizzyMacro they're using only clobbers > rscratch1 and so rscratch2 will be "safe" and its contents will be > preserved across WhizzyMacro. The danger of this is obvious: a > maintenance programmer less familiar with the code base will come > along and use some other registers. This is particularly problematic > when a macro is used in many places, and if there are several versions > of a macro, as happens in the case of GC barriers. Do you think this partly stems from having *two* scratch registers, where one or the other is often not clobbered? The 32-bit Arm ports gets away with just a single Rtmp, and perhaps in that case programmers are more likely to think it's always clobbered. > > There is another risk: aliasing, the extreme sport of referring to the > same register in a macro by more than one name. Again, the risk is > obvious: the poor programmer won't know that the registers "tmp" and > "rscratch2" are in fact the same register. This can be mitigated somewhat if the macros name all the registers they use up-front and then do an assert_different_registers(...). > > Bear in mind that it is sometimes convenient to avoid declaring > scratch registers in macros altogether. You can do this by passing all > of the temporary registers a macro needs explicitly as arguments, and > this can make the code smaller and simpler. Yes, it makes the macro much easier to understand in isolation. As someone new to the codebase I would be a bit surprised that seemingly primitive operation like cmpxchg, increment, compare_eq, etc. clobber scratch registers. I think readability would improve if we added explicit temporary arguments to these macros. So that the majority of MacroAssembler::* then doesn't use the implicit scratch registers at all. Maybe we can try this as an exercise and see what's left over? I guess it wouldn't increase verbosity all that much. > > { > ScratchRegister rscratch1(__ as(), r8); > __ ldrb(rscratch1, gc_state); > __ tbz(rscratch1, ShenandoahHeap::MARKING_BITPOS, done); > } > > > [NB: it is possible to give the scratch register a name other than > rscratch1, but please don't!] It's also possible to do `ScratchRegister rscratch1(__ as(), r9)' which is perhaps more confusing. > > Let's say you need to call InnerMacro from WhizzyMacro, and both > InnerMacro and WhizzyMacro need scratch registers. You can do this by > explicitly freeing the scratch registers, like so: > > WhizzyMacro() { > ... > ScratchRegister rscratch1(__ as(), r8); > // Code using rscratch1 ... > { > FreeScratchRegs dummy(__ as()); > __ InnerMacro(); > // Try to use rscratch1 here and you'll get an assertion > // because you don't own it. > } > // You can use rscratch1 again here. > ... > } > > In this case it is clear to the reader that InnerMacro() may clobber > both scratch registers. At the end of the scope of FreeScratchRegs, > rscratch1 is again owned by WhizzyMacro. But you could equally write it with two separate ScratchRegister scopes and avoid FreeScratchRegs altogether: WhizzyMacro() { ... { ScratchRegister rscratch1(__ as(), r8); // Code using rscratch1 ... } __ InnerMacro(); // Try to use rscratch1 here and you'll get an assertion // because you don't own it. { ScratchRegister rscratch1(__ as(), r8); // You can use rscratch1 again here. ... } } Visually this makes it clear to the reader that the two "rscratch1"s are unrelated and not preserved across InnerMacro. Looking at the patch I can see why FreeScratchRegs helps minimise changes to the existing code, but it still feels like a bit of a kludge. > > Webrev at http://cr.openjdk.java.net/~aph/scratch-regs/webrev/ > I couldn't apply that cleanly on top of jdk/jdk. Maybe needs rebasing? src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp +class ScratchRegister { + Register _r; + MacroAssembler *_masm; I think this class can inherit from StackObj to disallow new/delete, like the other RAII types in Hotspot do. + ScratchRegister(const ScratchRegister &r) { + _r = r._r; + _masm = NULL; + } Do we really need to support copying? It seems to complicate the model quite a lot and has some issues e.g. if the copy outlives the original. I can only see it being used in the new cmpw overload - do we actually call that? src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp - set_last_Java_frame(esp, rfp, (address) pc(), rscratch1); + set_last_Java_frame(esp, rfp, (address) pc(), r8); This is a bit icky. Can we move the body of _call_Unimplemented into the .cpp file where there is already a global constant for rscratch1? src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp +void tassert(bool shouldBeTrue, const char *msg) { + if (! shouldBeTrue) { + fprintf(stderr, "%s\n", msg); + } +} This isn't used? > Finally, I'm not wedded to the current syntax for declarations: I can > think of some nicer ways to do it so that you could say > > use_scratch(rscratch1); > > rather than > > ScratchRegister rscratch1(__ as(), r8); I think it's OK as-is, and preferable to anything that uses pre-processor magic. Maybe something like the following using a move constructor for ScratchRegister would be prettier: ScratchRegister rscratch1(__ scratch_register(r8)); Thanks, Nick From adinn at redhat.com Thu Oct 31 09:02:37 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 31 Oct 2019 09:02:37 +0000 Subject: [aarch64-port-dev ] unimplemented code patching in AARCH64 In-Reply-To: <6a5699ee-6129-6300-8066-5d8418a60b94@redhat.com> References: <6a5699ee-6129-6300-8066-5d8418a60b94@redhat.com> Message-ID: <5cef5ee3-2cd2-6e39-51d5-7472a993b61a@redhat.com> On 30/10/2019 20:42, Andrew Haley wrote: > On 10/29/19 9:33 AM, Jie He (Arm Technology China) wrote: > . . . >> I also noticed Andrew Dinn reported >> the performance issue of case TestLongVect in AARCH64, which caused >> by too much deoptimization in aarch64, and the similar case >> TestByteVect doesn't happen because the function test() couldn't >> enter OSR due to its byte code size (> 8000). Details pls refer to >> [1]. > . . . >> [1]. http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-August/007876.html > > This one should be investigated some more. It looks like a bug. It is on my list of things to do. I think it is strictly a pathological case behaviour rather than a bug (a fine distinction). However, we should probably see if we can find a way to avoid the pathology. regards, Andrew Dinn ----------- From aph at redhat.com Thu Oct 31 09:21:36 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Oct 2019 09:21:36 +0000 Subject: [aarch64-port-dev ] RFD: scratch registers cleanup [Long post] In-Reply-To: <6c5aab62-d110-6b76-c27d-a242ce9c44d0@arm.com> References: <3e4aaf79-59a9-b346-e6b0-69839acf723e@redhat.com> <6c5aab62-d110-6b76-c27d-a242ce9c44d0@arm.com> Message-ID: <0213179b-2770-532e-8fb9-77f208200318@redhat.com> Hi, On 10/31/19 8:04 AM, Nick Gasson wrote: > > In general I think this is an improvement. I've put some comments below. > >> However, things haven't quite worked out that way. In practice people >> "know" that the macro WhizzyMacro they're using only clobbers >> rscratch1 and so rscratch2 will be "safe" and its contents will be >> preserved across WhizzyMacro. The danger of this is obvious: a >> maintenance programmer less familiar with the code base will come >> along and use some other registers. This is particularly problematic >> when a macro is used in many places, and if there are several versions >> of a macro, as happens in the case of GC barriers. > > Do you think this partly stems from having *two* scratch registers, > where one or the other is often not clobbered? The 32-bit Arm ports gets > away with just a single Rtmp, and perhaps in that case programmers are > more likely to think it's always clobbered. It's possible, but there are many cases where the code would be worse with only one. >> There is another risk: aliasing, the extreme sport of referring to the >> same register in a macro by more than one name. Again, the risk is >> obvious: the poor programmer won't know that the registers "tmp" and >> "rscratch2" are in fact the same register. > > This can be mitigated somewhat if the macros name all the registers they > use up-front and then do an assert_different_registers(...). I think you're missing my point: this aliasing has been done *deliberately*. So the assert_different_registers(...) isn't there. >> Bear in mind that it is sometimes convenient to avoid declaring >> scratch registers in macros altogether. You can do this by passing all >> of the temporary registers a macro needs explicitly as arguments, and >> this can make the code smaller and simpler. > > Yes, it makes the macro much easier to understand in isolation. > > As someone new to the codebase I would be a bit surprised that seemingly > primitive operation like cmpxchg, increment, compare_eq, etc. clobber > scratch registers. That ease of use was the reason for having the scratch registers: that they were always free, and any macro could use them. IMO this is a desirable property if it can be used safely, and I believe it can be. > I think readability would improve if we added explicit temporary > arguments to these macros. So that the majority of MacroAssembler::* > then doesn't use the implicit scratch registers at all. Maybe we can > try this as an exercise and see what's left over? I guess it > wouldn't increase verbosity all that much. I disagree. It wouldn't much help readability or ease of maintenance. Someone would have to be responsible at the top level for choosing which scratch registers to be passed down. But how do you know which is and is not a "top level" macro? Sometimes what was once a "top level" macro becomes a lower-level one. I'm proposing that we handle it automatically. >> { >> ScratchRegister rscratch1(__ as(), r8); >> __ ldrb(rscratch1, gc_state); >> __ tbz(rscratch1, ShenandoahHeap::MARKING_BITPOS, done); >> } >> >> >> [NB: it is possible to give the scratch register a name other than >> rscratch1, but please don't!] > > It's also possible to do `ScratchRegister rscratch1(__ as(), r9)' which > is perhaps more confusing. The penalty for that should be severe, but I would like to try to make it impossible. >> Let's say you need to call InnerMacro from WhizzyMacro, and both >> InnerMacro and WhizzyMacro need scratch registers. You can do this by >> explicitly freeing the scratch registers, like so: >> >> WhizzyMacro() { >> ... >> ScratchRegister rscratch1(__ as(), r8); >> // Code using rscratch1 ... >> { >> FreeScratchRegs dummy(__ as()); >> __ InnerMacro(); >> // Try to use rscratch1 here and you'll get an assertion >> // because you don't own it. >> } >> // You can use rscratch1 again here. >> ... >> } >> >> In this case it is clear to the reader that InnerMacro() may clobber >> both scratch registers. At the end of the scope of FreeScratchRegs, >> rscratch1 is again owned by WhizzyMacro. > > But you could equally write it with two separate ScratchRegister scopes > and avoid FreeScratchRegs altogether: > > WhizzyMacro() { > ... > { > ScratchRegister rscratch1(__ as(), r8); > // Code using rscratch1 ... > } > __ InnerMacro(); > // Try to use rscratch1 here and you'll get an assertion > // because you don't own it. > { > ScratchRegister rscratch1(__ as(), r8); > // You can use rscratch1 again here. > ... > } > } Sure, and in such a simple case I would, but it's a very simple case for illustration. Maybe I should have done something more complicated, but it would obfuscate the example. > Visually this makes it clear to the reader that the two "rscratch1"s > are unrelated and not preserved across InnerMacro. Looking at the > patch I can see why FreeScratchRegs helps minimise changes to the > existing code, but it still feels like a bit of a kludge. We have to be realistic, and not let the best be the enemy of the good enough. This patch introduces a new facility rather and uses it, rather than what would be a fairly large-scale reorganization of the code base. There are many cases where we have deep nesting: for example, one macro calls another, and there are many nested scopes, and in the middle someone needs a scratch register. One common case is where a macro calls a macro calls a macro, and there is a callout to the runtime which needs a scratch register. I can (almost) guarantee that this patch won't change the generated code and therefore won't break anything. That is an important guarantee at this stage. The chances of rewriting all macros (to pass scratch registers explicitly) without making mistakes and breaking things in very hard-to-debug ways is asymptotically close to zero. >> Webrev at http://cr.openjdk.java.net/~aph/scratch-regs/webrev/ > > I couldn't apply that cleanly on top of jdk/jdk. Maybe needs rebasing? OK, will do. It's not very old, but things move fast. > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp > > +class ScratchRegister { > + Register _r; > + MacroAssembler *_masm; > > I think this class can inherit from StackObj to disallow new/delete, > like the other RAII types in Hotspot do. > > + ScratchRegister(const ScratchRegister &r) { > + _r = r._r; > + _masm = NULL; > + } > > Do we really need to support copying? It seems to complicate the > model quite a lot and has some issues e.g. if the copy outlives the > original. I can only see it being used in the new cmpw overload - > do we actually call that? You're right, we could do wihtout that. > src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp > > - set_last_Java_frame(esp, rfp, (address) pc(), rscratch1); > + set_last_Java_frame(esp, rfp, (address) pc(), r8); > > This is a bit icky. Can we move the body of _call_Unimplemented into the > .cpp file where there is already a global constant for rscratch1? That seems reasonable. > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp > > +void tassert(bool shouldBeTrue, const char *msg) { > + if (! shouldBeTrue) { > + fprintf(stderr, "%s\n", msg); > + } > +} > > This isn't used? It's all Work In Progress. :-) > > Finally, I'm not wedded to the current syntax for declarations: I can > > think of some nicer ways to do it so that you could say > > > > use_scratch(rscratch1); > > > > rather than > > > > ScratchRegister rscratch1(__ as(), r8); > > I think it's OK as-is, and preferable to anything that uses > pre-processor magic. Maybe something like the following using a move > constructor for ScratchRegister would be prettier: > > ScratchRegister rscratch1(__ scratch_register(r8)); OK, I'll give that some more thought. I'm still thinking I need some automatic way to name the scratch registers correctly so that some silly programmer can't do the Wrong Thing. Thank you for such a thoughtful and detailed reply. It must have taken some time to write, and it is very helpful. -- 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 Oct 31 09:32:59 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Oct 2019 09:32:59 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> <7046e0e1-492d-1157-8e68-a8261bcb01e7@redhat.com> Message-ID: <6740bbac-6496-05fc-8886-147a5486b140@redhat.com> On 10/31/19 3:03 AM, Yangfei (Felix) wrote: > My thoughts about the risk: > Suppose we have T1 executing getAndSetLong on Core1 and T2 executing compareAndSwapLong on Core2. > Consider execution order: T1 - > T2 > The stxr of the getAndSetLong sequence executed on T1/Core1 may not be observed by T2/Core2. > The dmb ishld at the end of the getAndSetLong sequence does not ensure the visibility of the stxr, according to the architecture manual. Is the case you are talking about to the same variable or to different variables? If it's the same variable then the rules of multi-copy atomicity apply, and the stxr is definitely visible to a ldaxr. All stores, regardless of barrier instructions, are coherent. If it's a different variable then there is no happens-before relationship between them. -- 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 felix.yang at huawei.com Thu Oct 31 10:25:16 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 31 Oct 2019 10:25:16 +0000 Subject: [aarch64-port-dev ] RFR: [8u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <6740bbac-6496-05fc-8886-147a5486b140@redhat.com> References: <93e5aa14-4db6-97cf-8809-0e4bb3ad11cb@redhat.com> <4b17ffd0-6534-cc3a-656f-899538027eea@redhat.com> <7046e0e1-492d-1157-8e68-a8261bcb01e7@redhat.com> <6740bbac-6496-05fc-8886-147a5486b140@redhat.com> Message-ID: > On 10/31/19 3:03 AM, Yangfei (Felix) wrote: > > My thoughts about the risk: > > Suppose we have T1 executing getAndSetLong on Core1 and T2 executing > compareAndSwapLong on Core2. > > Consider execution order: T1 - > T2 > > The stxr of the getAndSetLong sequence executed on T1/Core1 may not > be observed by T2/Core2. > > The dmb ishld at the end of the getAndSetLong sequence does not ensure > the visibility of the stxr, according to the architecture manual. > > Is the case you are talking about to the same variable or to different variables? > > If it's the same variable then the rules of multi-copy atomicity apply, and the > stxr is definitely visible to a ldaxr. All stores, regardless of barrier instructions, > are coherent. If it's a different variable then there is no happens-before > relationship between them. I am talking about the case when they operate on the same variable. Looks like I missed the details of the aarch64's Other-multi-copy atomicity. Thanks for the clarification. Felix From adinn at redhat.com Thu Oct 31 10:58:29 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 31 Oct 2019 10:58:29 +0000 Subject: [aarch64-port-dev ] RFD: scratch registers cleanup [Long post] In-Reply-To: <3e4aaf79-59a9-b346-e6b0-69839acf723e@redhat.com> References: <3e4aaf79-59a9-b346-e6b0-69839acf723e@redhat.com> Message-ID: <110468b7-9621-f8bf-dfd0-4a30fffb936c@redhat.com> On 30/10/2019 18:58, Andrew Haley wrote: > [TL, DR: A large patch to clean up the use of scratch registers in the > AArch64 port. Anyone who has ever written assembly code for the > AArch64 port should probably read this.] > . . . > Comments gratefully received. I'm looking at this. It's a very nice idea and will take some time to give it the review it deserves. 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 aph at redhat.com Thu Oct 31 12:43:26 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Oct 2019 12:43:26 +0000 Subject: [aarch64-port-dev ] RFD: scratch registers cleanup [Long post] In-Reply-To: <110468b7-9621-f8bf-dfd0-4a30fffb936c@redhat.com> References: <3e4aaf79-59a9-b346-e6b0-69839acf723e@redhat.com> <110468b7-9621-f8bf-dfd0-4a30fffb936c@redhat.com> Message-ID: On 10/31/19 10:58 AM, Andrew Dinn wrote: > On 30/10/2019 18:58, Andrew Haley wrote: >> [TL, DR: A large patch to clean up the use of scratch registers in the >> AArch64 port. Anyone who has ever written assembly code for the >> AArch64 port should probably read this.] >> . . . >> Comments gratefully received. > > I'm looking at this. It's a very nice idea and will take some time to > give it the review it deserves. OK. bear in mind that it's still a bit scrappy, but I'm releasing it early to give you that time. BTW, I wrote an earlier version of this patch which allocated the registers automagically rather than the requiring the programmer to name them, but it turned into such a mess that I gave up. IMO it's better to do this more gradually, with this first patch making essentially no changes. -- 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 felix.yang at huawei.com Thu Oct 31 14:49:59 2019 From: felix.yang at huawei.com (felix.yang at huawei.com) Date: Thu, 31 Oct 2019 14:49:59 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8209835: Aarch64: elide barriers on all volatile operations Message-ID: <201910311450.x9VEo0rC012691@aojmv0008.oracle.com> Changeset: 02145a45eff6 Author: roland Date: 2018-11-05 12:53 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/02145a45eff6 8209835: Aarch64: elide barriers on all volatile operations Reviewed-by: aph, adinn ! src/cpu/aarch64/vm/aarch64.ad From aph at redhat.com Thu Oct 31 16:45:55 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Oct 2019 16:45:55 +0000 Subject: [aarch64-port-dev ] RFR 8232992: Shenandoah: Implement self-fixing interpreter LRB In-Reply-To: <1648aef7-6df9-6f54-6601-fde9d7251187@redhat.com> References: <1648aef7-6df9-6f54-6601-fde9d7251187@redhat.com> Message-ID: <15f764f4-8cbe-5a9c-88f9-1843b1e97d0c@redhat.com> On 10/25/19 3:29 PM, Zhengyu Gu wrote: > Test: > hotspot_gc_shenandoah (fastdebug and release) > x86_64 and x86_32 on Linux > aarch64 Linux > Windows x86_64 I didn't see this because I don't read all the Shenandoah and GC messages. The AArch64 code is unidiomatic and cumbersome in places, not to mention extremely confusing, and I can help with that. 236 void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { 237 assert(ShenandoahLoadRefBarrier, "Should be enabled"); 238 assert(dst != rscratch2, "need rscratch2"); 239 assert_different_registers(load_addr.base(), load_addr.index(), rscratch1); 240 assert_different_registers(load_addr.base(), load_addr.index(), rscratch2); 241 242 Label done; 243 __ enter(); 244 Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); 245 __ ldrb(rscratch2, gc_state); 246 247 // Check for heap stability 248 __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); 249 250 // use r1 for load address 251 Register result_dst = dst; 252 if (dst == r1) { 253 __ mov(rscratch1, dst); This is pointless. On AArch64 mov(Rn, Rm) generates no code if Rn == Rm. 254 dst = rscratch1; 255 } 256 257 RegSet to_save_r1 = RegSet::of(r1); 258 // If outgoing register is r1, we can clobber it 259 if (result_dst != r1) { 260 __ push(to_save_r1, sp); 261 } On AArch64 registers are always saved in pairs, so it makes sense to push individual registers. You might as well push both if either is to be saved. 262 __ lea(r1, load_addr); 263 264 RegSet to_save_r0 = RegSet::of(r0); 265 if (dst != r0) { 266 __ push(to_save_r0, sp); 267 __ mov(r0, dst); 268 } 269 270 __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); 271 272 if (result_dst != r0) { 273 __ mov(result_dst, r0); 274 } 275 276 if (dst != r0) { 277 __ pop(to_save_r0, sp); 278 } 279 280 if (result_dst != r1) { 281 __ pop(to_save_r1, sp); 282 } 283 284 __ bind(done); 285 __ leave(); 286 } So, you want to save r1 and r0, but if either of those is the destination you don't want to save it. The code at ShenandoahBarrierSetAssembler::shenandoah_lrb() preserves everything but r1 and r0. I believe this is what you want: void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { assert(ShenandoahLoadRefBarrier, "Should be enabled"); assert(dst != rscratch2, "need rscratch2"); assert_different_registers(load_addr.base(), load_addr.index(), rscratch1, rscratch2); Label done; __ enter(); Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); __ ldrb(rscratch2, gc_state); // Check for heap stability __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); // use r1 for load address Register result_dst = dst; if (dst == r1) { __ mov(rscratch1, dst); dst = rscratch1; } RegSet to_save = RegSet::of(r0, r1) - result_dst; __ push(to_save, sp); __ lea(r1, load_addr); __ mov(r0, dst); __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); __ mov(result_dst, r0); __ pop(to_save, sp); __ bind(done); __ leave(); } Please forward any patches which contain AArch64 assembly code to the aarch64-port-dev at openjdk.java.net list. I don't mean any criticism of you personally, but the AArch64 code in the Shenandoah GC barriers is gnarly and some of the most difficult to read in the whole port, probably because its authors, while undoubtedly brilliant, were not experienced AArch64 programmers. Let me help. :-) -- 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 Oct 31 16:50:04 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Oct 2019 16:50:04 +0000 Subject: [aarch64-port-dev ] RFR 8232992: Shenandoah: Implement self-fixing interpreter LRB In-Reply-To: <1648aef7-6df9-6f54-6601-fde9d7251187@redhat.com> References: <1648aef7-6df9-6f54-6601-fde9d7251187@redhat.com> Message-ID: <8adb0165-383d-b18b-4a05-52828100d397@redhat.com> On 10/25/19 3:29 PM, Zhengyu Gu wrote: > Test: > hotspot_gc_shenandoah (fastdebug and release) > x86_64 and x86_32 on Linux > aarch64 Linux > Windows x86_64 I didn't see this because I don't read all the Shenandoah and GC messages. The AArch64 code is unidiomatic and cumbersome in places, not to mention extremely confusing, and I can help with that. 236 void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { 237 assert(ShenandoahLoadRefBarrier, "Should be enabled"); 238 assert(dst != rscratch2, "need rscratch2"); 239 assert_different_registers(load_addr.base(), load_addr.index(), rscratch1); 240 assert_different_registers(load_addr.base(), load_addr.index(), rscratch2); 241 242 Label done; 243 __ enter(); 244 Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); 245 __ ldrb(rscratch2, gc_state); 246 247 // Check for heap stability 248 __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); 249 250 // use r1 for load address 251 Register result_dst = dst; 252 if (dst == r1) { 253 __ mov(rscratch1, dst); This is pointless. On AArch64 mov(Rn, Rm) generates no code if Rn == Rm. 254 dst = rscratch1; 255 } 256 257 RegSet to_save_r1 = RegSet::of(r1); 258 // If outgoing register is r1, we can clobber it 259 if (result_dst != r1) { 260 __ push(to_save_r1, sp); 261 } On AArch64 registers are always saved in pairs, so it makes sense to push individual registers. You might as well push both if either is to be saved. 262 __ lea(r1, load_addr); 263 264 RegSet to_save_r0 = RegSet::of(r0); 265 if (dst != r0) { 266 __ push(to_save_r0, sp); 267 __ mov(r0, dst); 268 } 269 270 __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); 271 272 if (result_dst != r0) { 273 __ mov(result_dst, r0); 274 } 275 276 if (dst != r0) { 277 __ pop(to_save_r0, sp); 278 } 279 280 if (result_dst != r1) { 281 __ pop(to_save_r1, sp); 282 } 283 284 __ bind(done); 285 __ leave(); 286 } So, you want to save r1 and r0, but if either of those is the destination you don't want to save it. The code at ShenandoahBarrierSetAssembler::shenandoah_lrb() preserves everything but r1 and r0. I believe this is what you want: void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { assert(ShenandoahLoadRefBarrier, "Should be enabled"); assert(dst != rscratch2, "need rscratch2"); assert_different_registers(load_addr.base(), load_addr.index(), rscratch1, rscratch2); Label done; __ enter(); Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); __ ldrb(rscratch2, gc_state); // Check for heap stability __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); // use r1 for load address Register result_dst = dst; if (dst == r1) { __ mov(rscratch1, dst); dst = rscratch1; } RegSet to_save = RegSet::of(r0, r1) - result_dst; __ push(to_save, sp); __ lea(r1, load_addr); __ mov(r0, dst); __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); __ mov(result_dst, r0); __ pop(to_save, sp); __ bind(done); __ leave(); } Please forward any patches which contain AArch64 assembly code to the aarch64-port-dev at openjdk.java.net list. I don't mean any criticism of you personally, but the AArch64 code in the Shenandoah GC barriers is gnarly and some of the most difficult to read in the whole port, probably because its authors, while undoubtedly brilliant, were not experienced AArch64 programmers. Let me help. :-) -- 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 Oct 31 18:46:26 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 31 Oct 2019 18:46:26 +0000 Subject: [aarch64-port-dev ] RFD: scratch registers cleanup [Long post] In-Reply-To: <6c5aab62-d110-6b76-c27d-a242ce9c44d0@arm.com> References: <3e4aaf79-59a9-b346-e6b0-69839acf723e@redhat.com> <6c5aab62-d110-6b76-c27d-a242ce9c44d0@arm.com> Message-ID: <61b73f1a-6775-d619-7777-755fe2d45078@redhat.com> On 10/31/19 8:04 AM, Nick Gasson wrote: > I couldn't apply that cleanly on top of jdk/jdk. Maybe needs rebasing? Phew. New patch at http://cr.openjdk.java.net/~aph/scratch-regs/webrev.1/ -- 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 zgu at redhat.com Thu Oct 31 18:48:04 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 31 Oct 2019 14:48:04 -0400 Subject: [aarch64-port-dev ] RFR 8233339: Shenandoah: Centralize load barrier decisions into ShenandoahBarrierSet Message-ID: <6ef89df6-84db-0ffe-d1fc-7ffde7e622bf@redhat.com> Right now, the decisions on, if a load barrier needs load reference barrier, if so, what kind? and if the reference needs to be kept alive, are scattered inside interpreter/c1/2 load barrier code, which is hard to make them consistent. I would like to centralize the decision making into ShenandoahBarrierSet, so them can be consistent and easy to maintain. Bug: https://bugs.openjdk.java.net/browse/JDK-8233339 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8233339/webrev.00/index.html Test: hotspot_gc_shenandoah (fastdebug and release) x86_64 and x86_32 on Linux AArch64 on Linux Thanks, -Zhengyu From zgu at redhat.com Thu Oct 31 18:09:17 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 31 Oct 2019 18:09:17 -0000 Subject: [aarch64-port-dev ] RFR 8232992: Shenandoah: Implement self-fixing interpreter LRB In-Reply-To: <8adb0165-383d-b18b-4a05-52828100d397@redhat.com> References: <1648aef7-6df9-6f54-6601-fde9d7251187@redhat.com> <8adb0165-383d-b18b-4a05-52828100d397@redhat.com> Message-ID: <540275f5-595a-faa0-2304-a95e657f92a0@redhat.com> Hi Andrew, Thanks for the suggestions. Filed JDK-8233337 to clean this up. -Zhengyu On 10/31/19 12:50 PM, Andrew Haley wrote: > On 10/25/19 3:29 PM, Zhengyu Gu wrote: >> Test: >> hotspot_gc_shenandoah (fastdebug and release) >> x86_64 and x86_32 on Linux >> aarch64 Linux >> Windows x86_64 > > I didn't see this because I don't read all the Shenandoah and GC > messages. > > The AArch64 code is unidiomatic and cumbersome in places, not to > mention extremely confusing, and I can help with that. > > 236 void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { > 237 assert(ShenandoahLoadRefBarrier, "Should be enabled"); > 238 assert(dst != rscratch2, "need rscratch2"); > 239 assert_different_registers(load_addr.base(), load_addr.index(), rscratch1); > 240 assert_different_registers(load_addr.base(), load_addr.index(), rscratch2); > 241 > 242 Label done; > 243 __ enter(); > 244 Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); > 245 __ ldrb(rscratch2, gc_state); > 246 > 247 // Check for heap stability > 248 __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); > 249 > 250 // use r1 for load address > 251 Register result_dst = dst; > 252 if (dst == r1) { > 253 __ mov(rscratch1, dst); > > This is pointless. On AArch64 mov(Rn, Rm) generates no code if Rn == Rm. > > 254 dst = rscratch1; > 255 } > 256 > 257 RegSet to_save_r1 = RegSet::of(r1); > 258 // If outgoing register is r1, we can clobber it > 259 if (result_dst != r1) { > 260 __ push(to_save_r1, sp); > 261 } > > On AArch64 registers are always saved in pairs, so it makes sense to push > individual registers. You might as well push both if either is to be saved. > > 262 __ lea(r1, load_addr); > 263 > 264 RegSet to_save_r0 = RegSet::of(r0); > 265 if (dst != r0) { > 266 __ push(to_save_r0, sp); > 267 __ mov(r0, dst); > 268 } > 269 > 270 __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); > 271 > 272 if (result_dst != r0) { > 273 __ mov(result_dst, r0); > 274 } > 275 > 276 if (dst != r0) { > 277 __ pop(to_save_r0, sp); > 278 } > 279 > 280 if (result_dst != r1) { > 281 __ pop(to_save_r1, sp); > 282 } > 283 > 284 __ bind(done); > 285 __ leave(); > 286 } > > So, you want to save r1 and r0, but if either of those is the destination you > don't want to save it. The code at ShenandoahBarrierSetAssembler::shenandoah_lrb() > preserves everything but r1 and r0. > > I believe this is what you want: > > void ShenandoahBarrierSetAssembler::load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr) { > assert(ShenandoahLoadRefBarrier, "Should be enabled"); > assert(dst != rscratch2, "need rscratch2"); > assert_different_registers(load_addr.base(), load_addr.index(), rscratch1, rscratch2); > > Label done; > __ enter(); > Address gc_state(rthread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); > __ ldrb(rscratch2, gc_state); > > // Check for heap stability > __ tbz(rscratch2, ShenandoahHeap::HAS_FORWARDED_BITPOS, done); > > // use r1 for load address > Register result_dst = dst; > if (dst == r1) { > __ mov(rscratch1, dst); > dst = rscratch1; > } > > RegSet to_save = RegSet::of(r0, r1) - result_dst; > __ push(to_save, sp); > __ lea(r1, load_addr); > __ mov(r0, dst); > > __ far_call(RuntimeAddress(CAST_FROM_FN_PTR(address, ShenandoahBarrierSetAssembler::shenandoah_lrb()))); > > __ mov(result_dst, r0); > __ pop(to_save, sp); > > __ bind(done); > __ leave(); > } > > > Please forward any patches which contain AArch64 assembly code to the > aarch64-port-dev at openjdk.java.net list. > > I don't mean any criticism of you personally, but the AArch64 code in > the Shenandoah GC barriers is gnarly and some of the most difficult to > read in the whole port, probably because its authors, while > undoubtedly brilliant, were not experienced AArch64 programmers. Let > me help. :-) >