From stuart.monteith at linaro.org Thu Dec 1 13:31:06 2016 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 1 Dec 2016 13:31:06 +0000 Subject: [aarch64-port-dev ] Fireside chat - Thursday In-Reply-To: <1480548248.7423.71.camel@gmail.com> References: <1480548248.7423.71.camel@gmail.com> Message-ID: That's perfectly right - it serves me right to reuse old emails. TTYL, Stuart On 30 November 2016 at 23:24, Edward Nevill wrote: > Hi, > > I think 1600 UTC is 1100 EST, not 1200 EST as advertised. > > EST is UTC-5 at the moment, at times they are UTC-4 because the US put > the clocks back later than the UK, but at the moment I believe we are > both on winter time so it should be UTC-5. > > I stand to be corrected:-) > > All the best, > Ed. > > On Wed, 2016-11-30 at 11:06 +0000, Stuart Monteith wrote: >> Hello, >> This week we'll be having a fireside chat on Thursday at 1600 >> UTC, >> 1600 GMT, 1200 EST. Please note that daylight savings time are out of >> sync this week, but will be back to the usual offset after this >> weekend. >> >> In order to join in, please join the chat at Bluejeans here: >> https://bluejeans.com/791239268 >> >> Alternatively you may dial in using one of the following numbers >> >> http://bluejeans.com/numbers >> >> and enter the Meeting ID: 791239268 >> >> Please do not use any of the 'freefone' numbers, because although >> they >> may be free for you they cost us $$$$. >> >> For the agenda Ed would like to discuss "JEP 297: Unified arm32/arm64 >> Port". >> >> http://openjdk.java.net/jeps/297 >> >> Best Regards, >> Stuart From ci_notify at linaro.org Thu Dec 1 14:49:23 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 1 Dec 2016 14:49:23 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <1069716460.904.1480603763652.JavaMail.jenkins@ci.linaro.org> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2016/336/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/01 pass: 668; fail: 44; error: 6 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/01 pass: 3,091; error: 16 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/03 pass: 664; fail: 44; error: 6 Build 1: aarch64/2016/nov/08 pass: 664; fail: 44; error: 6 Build 2: aarch64/2016/nov/09 pass: 664; fail: 44; error: 6 Build 3: aarch64/2016/nov/21 pass: 668; fail: 44; error: 6 Build 4: aarch64/2016/dec/01 pass: 669; fail: 43; error: 6 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/03 pass: 3,092; error: 15 Build 1: aarch64/2016/nov/08 pass: 3,092; error: 15 Build 2: aarch64/2016/nov/09 pass: 3,091; error: 16 Build 3: aarch64/2016/nov/21 pass: 3,095; error: 12 Build 4: aarch64/2016/dec/01 pass: 3,095; error: 12 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.93x Relative performance: Server critical-jOPS (nc): 0.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 56.01, Server: 106.13 Client 56.01 / Client 2014-04-01 (43.00): 1.30x Server 106.13 / Server 2014-04-01 (71.00): 1.49x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-03 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2016/308/results/ 2016-11-21 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2016/326/results/ 2016-12-01 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2016/336/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From bob.vandette at oracle.com Fri Dec 2 20:28:41 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 2 Dec 2016 15:28:41 -0500 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port Message-ID: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> Please review the proposed changes to be integrated under JEP 297. Summary: This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. This changeset also removes the support for the pregenerated interpreter since this is no longer supported. The addition of arm64 does not replace the existing aarch64 port. A new configure option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. JEP 297: https://bugs.openjdk.java.net/browse/JDK-8168503 Webrev: http://cr.openjdk.java.net/~bobv/8168503 Note: A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 Thanks, Bob Vandette From vladimir.kozlov at oracle.com Sat Dec 3 01:04:53 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 2 Dec 2016 17:04:53 -0800 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> Message-ID: <58421A35.5070706@oracle.com> hi Bob, I would suggest to have separate webrevs for different repositories because different groups should look on them. For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net Why do you need cahnges in SA libproc.h? I saw Hotspot changes before and I think they are fine (did not dive deep). Thanks, Vladimir On 12/2/16 12:28 PM, Bob Vandette wrote: > Please review the proposed changes to be integrated under JEP 297. > > Summary: > > This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. > > This changeset also removes the support for the pregenerated interpreter since > this is no longer supported. > > The addition of arm64 does not replace the existing aarch64 port. A new configure > option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the > 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. > > JEP 297: > > https://bugs.openjdk.java.net/browse/JDK-8168503 > > Webrev: > > http://cr.openjdk.java.net/~bobv/8168503 > > > Note: > > A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 > > Thanks, > Bob Vandette > From bob.vandette at oracle.com Mon Dec 5 15:23:50 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 5 Dec 2016 10:23:50 -0500 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <58421A35.5070706@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> <58421A35.5070706@oracle.com> Message-ID: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> > On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov wrote: > > hi Bob, > > I would suggest to have separate webrevs for different repositories because different groups should look on them. There are only 3 non hotspot files and they are on top. Forwarding to build-dev for their review. > > For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net > > Why do you need cahnges in SA libproc.h? The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs. I just looked again and there is a definition of struct user_regs in user.h. I might be able to change the code to: #if defined(arm) || defined(arm64) #define user_regs_struct user_regs #endif This change would result in the exact same declaration based on the number of registers derived from the structure in user.h. Bob. > > I saw Hotspot changes before and I think they are fine (did not dive deep). > > Thanks, > Vladimir > > On 12/2/16 12:28 PM, Bob Vandette wrote: >> Please review the proposed changes to be integrated under JEP 297. >> >> Summary: >> >> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. >> >> This changeset also removes the support for the pregenerated interpreter since >> this is no longer supported. >> >> The addition of arm64 does not replace the existing aarch64 port. A new configure >> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the >> 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. >> >> JEP 297: >> >> https://bugs.openjdk.java.net/browse/JDK-8168503 >> >> Webrev: >> >> http://cr.openjdk.java.net/~bobv/8168503 >> >> >> Note: >> >> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 >> >> Thanks, >> Bob Vandette >> From vladimir.kozlov at oracle.com Mon Dec 5 17:24:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Dec 2016 09:24:55 -0800 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> <58421A35.5070706@oracle.com> <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> Message-ID: <5845A2E7.8050203@oracle.com> On 12/5/16 7:23 AM, Bob Vandette wrote: > >> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov wrote: >> >> hi Bob, >> >> I would suggest to have separate webrevs for different repositories because different groups should look on them. > > There are only 3 non hotspot files and they are on top. Forwarding to build-dev for their review. +3 Hotspot makefile cahnges. + new jvm.cfg But you are right that makefiles changes are first in the webrev and easy to find/review. > >> >> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net >> >> Why do you need cahnges in SA libproc.h? > > The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs. > > I just looked again and there is a definition of struct user_regs in user.h. I might be able to change the code to: > > #if defined(arm) || defined(arm64) > #define user_regs_struct user_regs > #endif > > This change would result in the exact same declaration based on the number of registers > derived from the structure in user.h. Please, do this. Thanks, Vladimir > > Bob. > > >> >> I saw Hotspot changes before and I think they are fine (did not dive deep). >> >> Thanks, >> Vladimir >> >> On 12/2/16 12:28 PM, Bob Vandette wrote: >>> Please review the proposed changes to be integrated under JEP 297. >>> >>> Summary: >>> >>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. >>> >>> This changeset also removes the support for the pregenerated interpreter since >>> this is no longer supported. >>> >>> The addition of arm64 does not replace the existing aarch64 port. A new configure >>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the >>> 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. >>> >>> JEP 297: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8168503 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~bobv/8168503 >>> >>> >>> Note: >>> >>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 >>> >>> Thanks, >>> Bob Vandette >>> > From erik.joelsson at oracle.com Tue Dec 6 12:33:21 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 6 Dec 2016 13:33:21 +0100 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> <58421A35.5070706@oracle.com> <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> Message-ID: <87dd5a84-f307-d8e9-11f3-35dc379f1fb5@oracle.com> Build changes look ok to me. /Erik On 2016-12-05 16:23, Bob Vandette wrote: >> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov wrote: >> >> hi Bob, >> >> I would suggest to have separate webrevs for different repositories because different groups should look on them. > There are only 3 non hotspot files and they are on top. Forwarding to build-dev for their review. > >> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net >> >> Why do you need cahnges in SA libproc.h? > The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs. > > I just looked again and there is a definition of struct user_regs in user.h. I might be able to change the code to: > > #if defined(arm) || defined(arm64) > #define user_regs_struct user_regs > #endif > > This change would result in the exact same declaration based on the number of registers > derived from the structure in user.h. > > Bob. > > >> I saw Hotspot changes before and I think they are fine (did not dive deep). >> >> Thanks, >> Vladimir >> >> On 12/2/16 12:28 PM, Bob Vandette wrote: >>> Please review the proposed changes to be integrated under JEP 297. >>> >>> Summary: >>> >>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. >>> >>> This changeset also removes the support for the pregenerated interpreter since >>> this is no longer supported. >>> >>> The addition of arm64 does not replace the existing aarch64 port. A new configure >>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the >>> 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. >>> >>> JEP 297: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8168503 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~bobv/8168503 >>> >>> >>> Note: >>> >>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 >>> >>> Thanks, >>> Bob Vandette >>> From david.holmes at oracle.com Wed Dec 7 02:11:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Dec 2016 12:11:29 +1000 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> Message-ID: This all looks good to me Bob! Thanks. David On 3/12/2016 6:28 AM, Bob Vandette wrote: > Please review the proposed changes to be integrated under JEP 297. > > Summary: > > This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. > > This changeset also removes the support for the pregenerated interpreter since > this is no longer supported. > > The addition of arm64 does not replace the existing aarch64 port. A new configure > option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the > 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. > > JEP 297: > > https://bugs.openjdk.java.net/browse/JDK-8168503 > > Webrev: > > http://cr.openjdk.java.net/~bobv/8168503 > > > Note: > > A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 > > Thanks, > Bob Vandette > From magnus.ihse.bursie at oracle.com Wed Dec 7 08:44:31 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 7 Dec 2016 09:44:31 +0100 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> <58421A35.5070706@oracle.com> <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> Message-ID: <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com> On 2016-12-05 16:23, Bob Vandette wrote: >> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov wrote: >> >> hi Bob, >> >> I would suggest to have separate webrevs for different repositories because different groups should look on them. > There are only 3 non hotspot files and they are on top. Forwarding to build-dev for their review. Build changes mostly look good. A few comments: * We try to use the autoconf defined "$with_opt" variables only when checking and verifying arguments. In hotspot.m4, please let SETUP_HOTSPOT_TARGET_CPU_PORT assign the user specified value to e.g. OPENJDK_TARGET_CPU_PORT, and use that to do the check in HOTSPOT_SETUP_JVM_FEATURES. * In flags.m4, the SET_SHARED_LIBRARY_ORIGIN code checks OPENJDK_TARGET_CPU_ARCH. I'd prefer if it checked OPENJDK_TARGET_CPU instead, since explicitly checking the CPU_ARCH variable seems to indicate that we want to test more than a single CPU, but for arm there is only one. (At first, I thought this was a test for "arm64" as well. If this was the intention, then the code is broken.) * In CompileJvm.gmk, you might want to rephrase the comment, since from now on both the original aarch64 and the new arm64 port are "open". What the code does is in fact to select between the two different aarch64 ports. /Magnus > >> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net >> >> Why do you need cahnges in SA libproc.h? > The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs. > > I just looked again and there is a definition of struct user_regs in user.h. I might be able to change the code to: > > #if defined(arm) || defined(arm64) > #define user_regs_struct user_regs > #endif > > This change would result in the exact same declaration based on the number of registers > derived from the structure in user.h. > > Bob. > > >> I saw Hotspot changes before and I think they are fine (did not dive deep). >> >> Thanks, >> Vladimir >> >> On 12/2/16 12:28 PM, Bob Vandette wrote: >>> Please review the proposed changes to be integrated under JEP 297. >>> >>> Summary: >>> >>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. >>> >>> This changeset also removes the support for the pregenerated interpreter since >>> this is no longer supported. >>> >>> The addition of arm64 does not replace the existing aarch64 port. A new configure >>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the >>> 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. >>> >>> JEP 297: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8168503 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~bobv/8168503 >>> >>> >>> Note: >>> >>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 >>> >>> Thanks, >>> Bob Vandette >>> From ci_notify at linaro.org Wed Dec 7 08:45:00 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 7 Dec 2016 08:45:00 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1525622914.474.1481100301433.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/341/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.93x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 73.13, Server: 110.27 Client 73.13 / Client 2014-04-01 (43.00): 1.70x Server 110.27 / Server 2014-04-01 (71.00): 1.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From ci_notify at linaro.org Wed Dec 7 08:57:51 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 7 Dec 2016 08:57:51 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1219314614.476.1481101072204.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/341/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.93x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 73.13, Server: 110.27 Client 73.13 / Client 2014-04-01 (43.00): 1.70x Server 110.27 / Server 2014-04-01 (71.00): 1.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From edward.nevill at gmail.com Wed Dec 7 16:05:41 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 07 Dec 2016 16:05:41 +0000 Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 In-Reply-To: <1525622914.474.1481100301433.JavaMail.jenkins@ci.linaro.org> References: <1525622914.474.1481100301433.JavaMail.jenkins@ci.linaro.org> Message-ID: <1481126741.27954.3.camel@gmail.com> On Wed, 2016-12-07 at 08:45 +0000, ci_notify at linaro.org wrote: > ? > ? http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/summary/ > 2016/341/summary.html > ? > ------------------------------------------------------------------- > ------------ > client-release/hotspot > ------------------------------------------------------------------- > ------------ > Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 > Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 > Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 > > 1 fatal errors were detected; please follow the link above for more > detail. Hi, When I follow the link above, and then try to following the "Hotspot Error Log" link (http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-t ests/builds/client-release/2016/341/JTwork- hotspot/scratch/3/hs_err_pid27769.log) I get error 404. Can this file be made available. The error log is very useful in trying to debug the problem. It contains a backtrace, register contents and a memory dump around where the error occurred. All the best, Ed. From bob.vandette at oracle.com Wed Dec 7 18:51:45 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 7 Dec 2016 13:51:45 -0500 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> <58421A35.5070706@oracle.com> <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com> Message-ID: <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com> Thanks Magnus, see comments below .. > On Dec 7, 2016, at 3:44 AM, Magnus Ihse Bursie wrote: > > On 2016-12-05 16:23, Bob Vandette wrote: >>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov wrote: >>> >>> hi Bob, >>> >>> I would suggest to have separate webrevs for different repositories because different groups should look on them. >> There are only 3 non hotspot files and they are on top. Forwarding to build-dev for their review. > > Build changes mostly look good. A few comments: > > * We try to use the autoconf defined "$with_opt" variables only when checking and verifying arguments. In hotspot.m4, please let SETUP_HOTSPOT_TARGET_CPU_PORT assign the user specified value to e.g. OPENJDK_TARGET_CPU_PORT, and use that to do the check in HOTSPOT_SETUP_JVM_FEATURES. I think it should be called HOTSPOT_TARGET_CPU_PORT since this variable only impact which directory hotspot uses for it build. I also removed a redundant if test "x$with_cpu_port" != x; in SETUP_HOTSPOT_TARGET_CPU_PORT. + # Override hotspot cpu definitions for ARM platforms + if test "x$OPENJDK_TARGET_CPU" = xarm; then + HOTSPOT_TARGET_CPU=arm_32 + HOTSPOT_TARGET_CPU_DEFINE="ARM32" + JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char" + JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char" + elif test "x$OPENJDK_TARGET_CPU" = xaarch64 && test "x$HOTSPOT_TARGET_CPU_PORT" = xarm64; then + HOTSPOT_TARGET_CPU=arm_64 + HOTSPOT_TARGET_CPU_ARCH=arm + JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char" + JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char" + fi + +AC_DEFUN([SETUP_HOTSPOT_TARGET_CPU_PORT], +[ + AC_ARG_WITH(cpu-port, [AS_HELP_STRING([--with-cpu-port], + [specify sources to use for Hotspot 64-bit ARM port (arm64,aarch64) @<:@aarch64@:>@ ])]) + + if test "x$with_cpu_port" != x; then + if test "x$OPENJDK_TARGET_CPU" != xaarch64; then + AC_MSG_ERROR([--with-cpu-port only available on aarch64]) + fi + if test "x$with_cpu_port" != xarm64 && \ + test "x$with_cpu_port" != xaarch64; then + AC_MSG_ERROR([--with-cpu-port must specify arm64 or aarch64]) + fi + HOTSPOT_TARGET_CPU_PORT = $with_cpu_port + fi +]) + + > > * In flags.m4, the SET_SHARED_LIBRARY_ORIGIN code checks OPENJDK_TARGET_CPU_ARCH. I'd prefer if it checked OPENJDK_TARGET_CPU instead, since explicitly checking the CPU_ARCH variable seems to indicate that we want to test more than a single CPU, but for arm there is only one. (At first, I thought this was a test for "arm64" as well. If this was the intention, then the code is broken.) > Ok. > * In CompileJvm.gmk, you might want to rephrase the comment, since from now on both the original aarch64 and the new arm64 port are "open". What the code does is in fact to select between the two different aarch64 ports. Done. I also found another comment that needed to be updated. diff --git a/make/lib/CompileJvm.gmk b/make/lib/CompileJvm.gmk --- a/make/lib/CompileJvm.gmk +++ b/make/lib/CompileJvm.gmk @@ -63,8 +63,8 @@ # INCLUDE_SUFFIX_* is only meant for including the proper # platform files. Don't use it to guard code. Use the value of # HOTSPOT_TARGET_CPU_DEFINE etc. instead. -# Remaining TARGET_ARCH_* is needed to distinguish closed and open -# 64-bit ARM ports (also called AARCH64). +# Remaining TARGET_ARCH_* is needed to select the cpu specific +# sources for 64-bit ARM ports (arm versus aarch64). JVM_CFLAGS_TARGET_DEFINES += \ -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) \ -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ @@ -139,6 +139,20 @@ ################################################################################ # Platform specific setup +# ARM source selection + +ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-arm) + JVM_EXCLUDE_PATTERNS += arm_64 + +else ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-aarch64) + # For 64-bit arm builds, we use the 64 bit hotspot/src/cpu/arm + # hotspot sources if HOTSPOT_TARGET_CPU_ARCH is set to arm. + # Exclude the aarch64 and 32 bit arm files for this build. + ifeq ($(HOTSPOT_TARGET_CPU_ARCH), arm) + JVM_EXCLUDE_PATTERNS += arm_32 aarch64 + endif +endif + Bob. > > /Magnus > > >> >>> For example, top repository and makefiles changes should be also reviewed on build-dev at openjdk.java.net >>> >>> Why do you need cahnges in SA libproc.h? >> The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs. >> >> I just looked again and there is a definition of struct user_regs in user.h. I might be able to change the code to: >> >> #if defined(arm) || defined(arm64) >> #define user_regs_struct user_regs >> #endif >> >> This change would result in the exact same declaration based on the number of registers >> derived from the structure in user.h. >> >> Bob. >> >> >>> I saw Hotspot changes before and I think they are fine (did not dive deep). >>> >>> Thanks, >>> Vladimir >>> >>> On 12/2/16 12:28 PM, Bob Vandette wrote: >>>> Please review the proposed changes to be integrated under JEP 297. >>>> >>>> Summary: >>>> >>>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. >>>> >>>> This changeset also removes the support for the pregenerated interpreter since >>>> this is no longer supported. >>>> >>>> The addition of arm64 does not replace the existing aarch64 port. A new configure >>>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the >>>> 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. >>>> >>>> JEP 297: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8168503 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~bobv/8168503 >>>> >>>> >>>> Note: >>>> >>>> A complete build-able forest containing these changes is located here: http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 >>>> >>>> Thanks, >>>> Bob Vandette >>>> > From ci_notify at linaro.org Thu Dec 8 08:12:51 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 8 Dec 2016 08:12:51 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1467408512.544.1481184771869.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/342/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.90x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.58, Server: 108.58 Client 70.58 / Client 2014-04-01 (43.00): 1.64x Server 108.58 / Server 2014-04-01 (71.00): 1.53x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From ci_notify at linaro.org Thu Dec 8 08:34:25 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 8 Dec 2016 08:34:25 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <928216915.546.1481186065514.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/342/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.90x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.58, Server: 108.58 Client 70.58 / Client 2014-04-01 (43.00): 1.64x Server 108.58 / Server 2014-04-01 (71.00): 1.53x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From magnus.ihse.bursie at oracle.com Thu Dec 8 10:32:28 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Dec 2016 11:32:28 +0100 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> <58421A35.5070706@oracle.com> <35F08BAA-BE09-4A63-A4AB-EA71F3FA808F@oracle.com> <84d6c7ff-cef6-c245-660a-7cb61074b1a4@oracle.com> <530D0083-BD1C-41CF-A782-42935ACCDCFB@oracle.com> Message-ID: <78f05033-1d85-61a6-8401-40fffaeb2baa@oracle.com> On 2016-12-07 19:51, Bob Vandette wrote: > Thanks Magnus, see comments below .. Your fixes look good. I'm ok with the build part of the patch now. /Magnus > >> On Dec 7, 2016, at 3:44 AM, Magnus Ihse Bursie >> > > wrote: >> >> On 2016-12-05 16:23, Bob Vandette wrote: >>>> On Dec 2, 2016, at 8:04 PM, Vladimir Kozlov wrote: >>>> >>>> hi Bob, >>>> >>>> I would suggest to have separate webrevs for different repositories because different groups should look on them. >>> There are only 3 non hotspot files and they are on top. Forwarding to build-dev for their review. >> >> Build changes mostly look good. A few comments: >> >> * We try to use the autoconf defined "$with_opt" variables only when >> checking and verifying arguments. In hotspot.m4, please let >> SETUP_HOTSPOT_TARGET_CPU_PORT assign the user specified value to e.g. >> OPENJDK_TARGET_CPU_PORT, and use that to do the check in >> HOTSPOT_SETUP_JVM_FEATURES. > > I think it should be called HOTSPOT_TARGET_CPU_PORT since this > variable only impact which directory hotspot uses for it build. > I also removed a redundant if test "x$with_cpu_port" != x; in > SETUP_HOTSPOT_TARGET_CPU_PORT. > > + # Override hotspot cpu definitions for ARM platforms > + if test "x$OPENJDK_TARGET_CPU" = xarm; then > + HOTSPOT_TARGET_CPU=arm_32 > + HOTSPOT_TARGET_CPU_DEFINE="ARM32" > + JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char" > + JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char" > + elif test "x$OPENJDK_TARGET_CPU" = xaarch64 && test > *"x$HOTSPOT_TARGET_CPU_PORT"* = xarm64; then > + HOTSPOT_TARGET_CPU=arm_64 > + HOTSPOT_TARGET_CPU_ARCH=arm > + JVM_LDFLAGS="$JVM_LDFLAGS -fsigned-char" > + JVM_CFLAGS="$JVM_CFLAGS -DARM -fsigned-char" > + fi > + > > +AC_DEFUN([SETUP_HOTSPOT_TARGET_CPU_PORT], > +[ > + AC_ARG_WITH(cpu-port, [AS_HELP_STRING([--with-cpu-port], > + [specify sources to use for Hotspot 64-bit ARM port > (arm64,aarch64) @<:@aarch64@:>@ ])]) > + > + if test "x$with_cpu_port" != x; then > + if test "x$OPENJDK_TARGET_CPU" != xaarch64; then > + AC_MSG_ERROR([--with-cpu-port only available on aarch64]) > + fi > + if test "x$with_cpu_port" != xarm64 && \ > + test "x$with_cpu_port" != xaarch64; then > + AC_MSG_ERROR([--with-cpu-port must specify arm64 or aarch64]) > + fi > *+ HOTSPOT_TARGET_CPU_PORT = $with_cpu_port* > + fi > +]) > + > + > >> >> * In flags.m4, the SET_SHARED_LIBRARY_ORIGIN code checks >> OPENJDK_TARGET_CPU_ARCH. I'd prefer if it checked OPENJDK_TARGET_CPU >> instead, since explicitly checking the CPU_ARCH variable seems to >> indicate that we want to test more than a single CPU, but for arm >> there is only one. (At first, I thought this was a test for "arm64" >> as well. If this was the intention, then the code is broken.) >> > Ok. > >> * In CompileJvm.gmk, you might want to rephrase the comment, since >> from now on both the original aarch64 and the new arm64 port are >> "open". What the code does is in fact to select between the two >> different aarch64 ports. > > Done. I also found another comment that needed to be updated. > > diff --git a/make/lib/CompileJvm.gmk b/make/lib/CompileJvm.gmk > --- a/make/lib/CompileJvm.gmk > +++ b/make/lib/CompileJvm.gmk > @@ -63,8 +63,8 @@ > # INCLUDE_SUFFIX_* is only meant for including the proper > # platform files. Don't use it to guard code. Use the value of > # HOTSPOT_TARGET_CPU_DEFINE etc. instead. > -# Remaining TARGET_ARCH_* is needed to distinguish closed and open > -# 64-bit ARM ports (also called AARCH64). > +# Remaining TARGET_ARCH_* is needed to select the cpu specific > +# sources for 64-bit ARM ports (arm versus aarch64). > JVM_CFLAGS_TARGET_DEFINES += \ > -DTARGET_ARCH_$(HOTSPOT_TARGET_CPU_ARCH) \ > -DINCLUDE_SUFFIX_OS=_$(HOTSPOT_TARGET_OS) \ > @@ -139,6 +139,20 @@ > ################################################################################ > # Platform specific setup > > > +# ARM source selection > + > +ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-arm) > + JVM_EXCLUDE_PATTERNS += arm_64 > + > +else ifeq ($(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), linux-aarch64) > + # For 64-bit arm builds, we use the 64 bit hotspot/src/cpu/arm > + # hotspot sources if HOTSPOT_TARGET_CPU_ARCH is set to arm. > + # Exclude the aarch64 and 32 bit arm files for this build. > + ifeq ($(HOTSPOT_TARGET_CPU_ARCH), arm) > + JVM_EXCLUDE_PATTERNS += arm_32 aarch64 > + endif > +endif > + > > Bob. > > >> >> /Magnus >> >> >>>> For example, top repository and makefiles changes should be also reviewed onbuild-dev at openjdk.java.net >>>> >>>> Why do you need cahnges in SA libproc.h? >>> The cross compilation toolchains we use do not define user_regs_struct or user_pt_regs. >>> >>> I just looked again and there is a definition of struct user_regs in user.h. I might be able to change the code to: >>> >>> #if defined(arm) || defined(arm64) >>> #define user_regs_struct user_regs >>> #endif >>> >>> This change would result in the exact same declaration based on the number of registers >>> derived from the structure in user.h. >>> >>> Bob. >>> >>> >>>> I saw Hotspot changes before and I think they are fine (did not dive deep). >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/2/16 12:28 PM, Bob Vandette wrote: >>>>> Please review the proposed changes to be integrated under JEP 297. >>>>> >>>>> Summary: >>>>> >>>>> This JEP adds arm32 and arm64 Linux platform support to OpenJDK for JDK 9. >>>>> >>>>> This changeset also removes the support for the pregenerated interpreter since >>>>> this is no longer supported. >>>>> >>>>> The addition of arm64 does not replace the existing aarch64 port. A new configure >>>>> option (-with-cpu-port=) allows for the selection of the existing aarch64 versus the >>>>> 64-bit arm64 support being added via this JEP. Please refer to the JEP for more details. >>>>> >>>>> JEP 297: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8168503 >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~bobv/8168503 >>>>> >>>>> >>>>> Note: >>>>> >>>>> A complete build-able forest containing these changes is located here:http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 >>>>> >>>>> Thanks, >>>>> Bob Vandette >>>>> >> > From rwestrel at redhat.com Thu Dec 8 13:41:01 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 08 Dec 2016 14:41:01 +0100 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: Message-ID: Hi Ningsheng, > NEON vector MLA instructions can not be generated in some simple > multiply-add cases. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8169697 > This is a bug fix and bug fixes can still be pushed without restrictions so I see no reason to not go with this: > In the mean time, Yang also has a more generic fix for this issue, > which patches share code and could also fix this issue: > > http://cr.openjdk.java.net/~njian/8169697/webrev.share/ That looks good to me. Anyone on the compiler side can take a look (and sponsor)? Roland. From ningsheng.jian at linaro.org Fri Dec 9 01:56:24 2016 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Fri, 9 Dec 2016 09:56:24 +0800 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: Message-ID: Hi Roland, Thanks for the review. >> NEON vector MLA instructions can not be generated in some simple >> multiply-add cases. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8169697 >> > > This is a bug fix and bug fixes can still be pushed without restrictions > so I see no reason to not go with this: > >> In the mean time, Yang also has a more generic fix for this issue, >> which patches share code and could also fix this issue: >> >> http://cr.openjdk.java.net/~njian/8169697/webrev.share/ > > That looks good to me. Anyone on the compiler side can take a look (and > sponsor)? Compared to aarch64 only version, I also prefer this patch. Thanks, Ningsheng From ci_notify at linaro.org Fri Dec 9 09:03:27 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 9 Dec 2016 09:03:27 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1022239168.718.1481274207536.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/343/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 73.13, Server: 110.27 Client 73.13 / Client 2014-04-01 (43.00): 1.70x Server 110.27 / Server 2014-04-01 (71.00): 1.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From ci_notify at linaro.org Fri Dec 9 09:40:11 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 9 Dec 2016 09:40:11 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <967627424.722.1481276412317.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/343/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 73.13, Server: 110.27 Client 73.13 / Client 2014-04-01 (43.00): 1.70x Server 110.27 / Server 2014-04-01 (71.00): 1.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From edward.nevill at gmail.com Fri Dec 9 11:33:28 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 09 Dec 2016 11:33:28 +0000 Subject: [aarch64-port-dev ] RFR: 8168503 JEP 297: Unified arm32/arm64 Port In-Reply-To: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> References: <8BACE784-C921-4C0E-90E0-C7446859C367@oracle.com> Message-ID: <1481283208.12942.22.camel@gmail.com> On Fri, 2016-12-02 at 15:28 -0500, Bob Vandette wrote: > > JEP 297: > > https://bugs.openjdk.java.net/browse/JDK-8168503 > > Webrev: > > http://cr.openjdk.java.net/~bobv/8168503 > I have added the results of JCStress testing as a comment to the JEP. Basically 100% pass with some 'formally acceptable but surprising' results. Thanks to Stuart Monteith for helping with the arm32 testing. All the best, Ed. From rwestrel at redhat.com Fri Dec 9 16:35:32 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 09 Dec 2016 17:35:32 +0100 Subject: [aarch64-port-dev ] RFR(S): 8162338: AArch64: Intrinsify fused mac operations Message-ID: http://cr.openjdk.java.net/~roland/8162338/webrev.00/ This also fixes a shared code bug in c1 and adds a new test case so I'll need a sponsor. I know I need to request extension: I'll do that. Roland. From stuart.monteith at linaro.org Fri Dec 9 16:41:09 2016 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 9 Dec 2016 16:41:09 +0000 Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 In-Reply-To: <967627424.722.1481276412317.JavaMail.jenkins@ci.linaro.org> References: <967627424.722.1481276412317.JavaMail.jenkins@ci.linaro.org> Message-ID: <625fb881-265e-ea57-f02d-3310772939a1@linaro.org> Hi, I've been looking at the JCStress failures, and as far as I can tell, Andrew's patch on jdk9/hs seems to stop the errors from occurring. They are a SIGSEGV at variants of the "stlxr x3,x8, [x0]" instruction. 12316:f5689e544d44 rkennke default public Parent:12315:0be832746ebe 8166719: gc/stress/TestStressG1Humongous.java fails with OOM... Child: 12317:3f551de87e59 8169711: CDS does not patch entry trampoline if intrinsic me... 8169901: AArch64: CompareAndExchange intrinsics clobber address register Reviewed-by: aph BR, Stuart On 09/12/16 09:40, ci_notify at linaro.org wrote: > 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/343/summary.html > > ------------------------------------------------------------------------------- > client-release/hotspot > ------------------------------------------------------------------------------- > Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 > Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 > Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 > Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 > Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 > > 1 fatal errors were detected; please follow the link above for more detail. > > ------------------------------------------------------------------------------- > client-release/jdk > ------------------------------------------------------------------------------- > Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 > Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 > Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 > > ------------------------------------------------------------------------------- > client-release/langtools > ------------------------------------------------------------------------------- > Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 > Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 > Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 > Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 > Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 > > ------------------------------------------------------------------------------- > server-release/hotspot > ------------------------------------------------------------------------------- > Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 > Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 > Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 > Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 > Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 > Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 > Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 > Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 > Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 > Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 > Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 > > ------------------------------------------------------------------------------- > server-release/jdk > ------------------------------------------------------------------------------- > Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 > Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 > Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 > Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 > Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 > Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 > Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 > Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 > Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 > > ------------------------------------------------------------------------------- > server-release/langtools > ------------------------------------------------------------------------------- > Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 > Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 > Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 > Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 > Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 > Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 > Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 > Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 > Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 > Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 > Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 > > Previous results can be found here: > > http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html > > > SPECjbb2015 composite regression test completed > =============================================== > > This test measures the relative performance of the server > compiler running the SPECjbb2015 composite tests and compares > the performance against the baseline performance of the server > compiler taken on 2016-11-21. > > In accordance with [1], the SPECjbb2015 tests are run on a system > which is not production ready and does not meet all the > requirements for publishing compliant results. The numbers below > shall be treated as non-compliant (nc) and are for experimental > purposes only. > > Relative performance: Server max-jOPS (nc): 1.01x > Relative performance: Server critical-jOPS (nc): 0.92x > > Details of the test setup and historical results may be found here: > > http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ > > [1] http://www.spec.org/fairuse.html#Academic > > Regression test Hadoop-Terasort completed > ========================================= > > This test measures the performance of the server and client compilers > running Hadoop sorting a 1GB file using Terasort and compares > the performance against the baseline performance of the Zero interpreter > and against the baseline performance of the client and server compilers > on 2014-04-01. > > Relative performance: Zero: 1.0, Client: 73.13, Server: 110.27 > > Client 73.13 / Client 2014-04-01 (43.00): 1.70x > Server 110.27 / Server 2014-04-01 (71.00): 1.55x > > Details of the test setup and historical results may be found here: > > http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ > > This is a summary of the jcstress test results > ============================================== > > The build and test results are cycled every 15 days. > > 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ > 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ > 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ > 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ > 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ > 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ > > For detailed information on the test output please refer to: > > http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ > > From aph at redhat.com Fri Dec 9 16:49:32 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 9 Dec 2016 16:49:32 +0000 Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 In-Reply-To: <625fb881-265e-ea57-f02d-3310772939a1@linaro.org> References: <967627424.722.1481276412317.JavaMail.jenkins@ci.linaro.org> <625fb881-265e-ea57-f02d-3310772939a1@linaro.org> Message-ID: On 09/12/16 16:41, Stuart Monteith wrote: > 've been looking at the JCStress failures, and as far as I can tell, > Andrew's patch on jdk9/hs seems to stop the errors from occurring. Yeah, needs a backport. Andrew. From vladimir.kozlov at oracle.com Fri Dec 9 18:46:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 10:46:05 -0800 Subject: [aarch64-port-dev ] RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: References: Message-ID: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> Hi Roland, You said in FC extension request that only aarch64 code is affected but you changed c1/c1_LIR.cpp. Can you do without this change? Otherwise RFE have to be rejected since there is no time to go through internal review process. I am fine with additional test. Thanks, Vladimir On 12/9/16 8:35 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8162338/webrev.00/ > > This also fixes a shared code bug in c1 and adds a new test case so I'll > need a sponsor. I know I need to request extension: I'll do that. > > Roland. > From rwestrel at redhat.com Fri Dec 9 19:19:54 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 09 Dec 2016 20:19:54 +0100 Subject: [aarch64-port-dev ] RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> Message-ID: Vladimir, Thanks for looking at this (and while I have your attention: I would need your opinion on 8169697 as well). > You said in FC extension request that only aarch64 code is affected but > you changed c1/c1_LIR.cpp. > > Can you do without this change? Otherwise RFE have to be rejected since > there is no time to go through internal review process. It's a bug fix. In the current code there's no call to do_input(op3->_opr3) which is how the register allocator knows that there's a third input to the LIR operation. So the current code works by accident at best. Do you want me to get this fixed separately? Roland. From vladimir.kozlov at oracle.com Fri Dec 9 19:30:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 11:30:20 -0800 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: Message-ID: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> On 12/8/16 5:56 PM, Ningsheng Jian wrote: > Hi Roland, > > Thanks for the review. > >>> NEON vector MLA instructions can not be generated in some simple >>> multiply-add cases. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8169697 >>> >> >> This is a bug fix and bug fixes can still be pushed without restrictions >> so I see no reason to not go with this: >> >>> In the mean time, Yang also has a more generic fix for this issue, >>> which patches share code and could also fix this issue: >>> >>> http://cr.openjdk.java.net/~njian/8169697/webrev.share/ >> >> That looks good to me. Anyone on the compiler side can take a look (and >> sponsor)? > > Compared to aarch64 only version, I also prefer this patch. What about SubV* and MulV* nodes? I prefer shared code change but we would need to test on all platforms which support vectors. Thanks, Vladimir > > Thanks, > Ningsheng > From vladimir.kozlov at oracle.com Fri Dec 9 19:31:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 11:31:35 -0800 Subject: [aarch64-port-dev ] RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> Message-ID: <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> On 12/9/16 11:19 AM, Roland Westrelin wrote: > > Vladimir, > > Thanks for looking at this (and while I have your attention: I would > need your opinion on 8169697 as well). It is bug but very intrusive for all platforms supporting vectors. We will have to test it before push. But I am fine to keep it as bug. > >> You said in FC extension request that only aarch64 code is affected but >> you changed c1/c1_LIR.cpp. >> >> Can you do without this change? Otherwise RFE have to be rejected since >> there is no time to go through internal review process. > > It's a bug fix. In the current code there's no call to > do_input(op3->_opr3) which is how the register allocator knows that > there's a third input to the LIR operation. So the current code works by > accident at best. Do you want me to get this fixed separately? File separate bug for this we can fix it any time until ZBB in Feb. Include test into it too. This way I can approve this RFE and you can push. Vladimir > > Roland. > From ci_notify at linaro.org Sat Dec 10 09:09:37 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 10 Dec 2016 09:09:37 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <104498092.926.1481360981917.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/344/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.86x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.93, Server: 108.58 Client 70.93 / Client 2014-04-01 (43.00): 1.65x Server 108.58 / Server 2014-04-01 (71.00): 1.53x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From aph at redhat.com Sat Dec 10 09:26:18 2016 From: aph at redhat.com (Andrew Haley) Date: Sat, 10 Dec 2016 09:26:18 +0000 Subject: [aarch64-port-dev ] Fwd: RFR(s) 8170873: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <584B21D9.20105@linux.vnet.ibm.com> References: <584B21D9.20105@linux.vnet.ibm.com> Message-ID: <2f504973-1010-292c-d4fa-8b41660a62fe@redhat.com> We need a backport of this for 8u. Andrew. -------------- next part -------------- An embedded message was scrubbed... From: Gustavo Romero Subject: RFR(s) 8170873: PPC64: Poor StrictMath performance due to non-optimized compilation Date: Fri, 9 Dec 2016 19:27:53 -0200 Size: 7795 URL: From ci_notify at linaro.org Sat Dec 10 09:50:33 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 10 Dec 2016 09:50:33 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1114280157.928.1481363434499.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/344/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.86x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.93, Server: 108.58 Client 70.93 / Client 2014-04-01 (43.00): 1.65x Server 108.58 / Server 2014-04-01 (71.00): 1.53x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From ci_notify at linaro.org Sun Dec 11 08:31:52 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 11 Dec 2016 08:31:52 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <228079235.991.1481445113365.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/345/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 12: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 10: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 12: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.76x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.76, Server: 106.93 Client 72.76 / Client 2014-04-01 (43.00): 1.69x Server 106.93 / Server 2014-04-01 (71.00): 1.51x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From ci_notify at linaro.org Sun Dec 11 08:58:07 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 11 Dec 2016 08:58:07 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <596813604.993.1481446688334.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/345/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 12: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 10: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 12: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.76x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.76, Server: 106.93 Client 72.76 / Client 2014-04-01 (43.00): 1.69x Server 106.93 / Server 2014-04-01 (71.00): 1.51x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From aph at redhat.com Sun Dec 11 18:52:48 2016 From: aph at redhat.com (Andrew Haley) Date: Sun, 11 Dec 2016 18:52:48 +0000 Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 In-Reply-To: References: <967627424.722.1481276412317.JavaMail.jenkins@ci.linaro.org> <625fb881-265e-ea57-f02d-3310772939a1@linaro.org> Message-ID: <07fb7ed1-8793-3e01-f698-ef4d5e22feb6@redhat.com> On 09/12/16 16:49, Andrew Haley wrote: > On 09/12/16 16:41, Stuart Monteith wrote: >> 've been looking at the JCStress failures, and as far as I can tell, >> Andrew's patch on jdk9/hs seems to stop the errors from occurring. > > Yeah, needs a backport. In case there was any doubt: please post a patch for this backport and I'll approve it. Thanks, Andrew. From yang.zhang at linaro.org Mon Dec 12 03:42:59 2016 From: yang.zhang at linaro.org (Yang Zhang) Date: Mon, 12 Dec 2016 11:42:59 +0800 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> References: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> Message-ID: Hi Vladimir, Thanks for your review. > > What about SubV* and MulV* nodes? > After checking commut_op_list, I think MulV*, AndV, OrV and XorV nodes can also be added. Should I add them all? SubV* nodes are not commutative, so I don't think they need to be considered here. > > I prefer shared code change but we would need to test on all platforms which support vectors. > Yeah, we need to test on all platforms. We already tested previous patch on x86 and aarch64 platforms, but we don't have other platforms. Regards Yang From ci_notify at linaro.org Mon Dec 12 08:40:08 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 12 Dec 2016 08:40:08 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <225271031.1039.1481532008882.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/346/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 12: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 13: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 10: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 11: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 12: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 13: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 71.65, Server: 109.42 Client 71.65 / Client 2014-04-01 (43.00): 1.67x Server 109.42 / Server 2014-04-01 (71.00): 1.54x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From ci_notify at linaro.org Mon Dec 12 09:23:58 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 12 Dec 2016 09:23:58 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <2027660664.1041.1481534642930.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/346/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 12: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 13: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 10: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 11: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 12: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 13: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 71.65, Server: 109.42 Client 71.65 / Client 2014-04-01 (43.00): 1.67x Server 109.42 / Server 2014-04-01 (71.00): 1.54x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From rwestrel at redhat.com Mon Dec 12 14:40:08 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 12 Dec 2016 15:40:08 +0100 Subject: [aarch64-port-dev ] RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> Message-ID: > File separate bug for this we can fix it any time until ZBB in Feb. > Include test into it too. It's 8171092. It's out for review. Here is the updated webrev without the bug fix for the fma aarch64 support: http://cr.openjdk.java.net/~roland/8162338/webrev.01/ Roland. From vladimir.kozlov at oracle.com Mon Dec 12 17:29:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 09:29:35 -0800 Subject: [aarch64-port-dev ] RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> Message-ID: <72ebde65-c0b3-9ec7-3f68-71044f29ef4f@oracle.com> Good. Let me push since we need to run test on all platforms. Thanks, Vladimir On 12/12/16 6:40 AM, Roland Westrelin wrote: > >> File separate bug for this we can fix it any time until ZBB in Feb. >> Include test into it too. > > It's 8171092. It's out for review. > > Here is the updated webrev without the bug fix for the fma aarch64 > support: > > http://cr.openjdk.java.net/~roland/8162338/webrev.01/ > > Roland. > From ci_notify at linaro.org Tue Dec 13 06:17:30 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 13 Dec 2016 06:17:30 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1089092816.1121.1481609850693.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/347/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 1,312; fail: 9; error: 48 Build 1: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 2: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 3: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 5: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 7: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 8: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 9: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 10: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 12: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 13: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 14: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 10: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 11: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 12: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 3,736; fail: 2; error: 32 Build 1: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 2: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 3: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 5: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 6: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 7: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 8: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 10: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 12: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 13: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 14: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.96x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 73.52, Server: 109.42 Client 73.52 / Client 2014-04-01 (43.00): 1.71x Server 109.42 / Server 2014-04-01 (71.00): 1.54x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From rwestrel at redhat.com Tue Dec 13 09:21:06 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 10:21:06 +0100 Subject: [aarch64-port-dev ] RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: <72ebde65-c0b3-9ec7-3f68-71044f29ef4f@oracle.com> References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> <72ebde65-c0b3-9ec7-3f68-71044f29ef4f@oracle.com> Message-ID: > Good. Let me push since we need to run test on all platforms. Thanks for your help with this. Roland. From kavitha.natarajan at linaro.org Tue Dec 13 10:57:01 2016 From: kavitha.natarajan at linaro.org (Kavitha Natarajan) Date: Tue, 13 Dec 2016 16:27:01 +0530 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: I have been trying to resolve a SEGV issue after using zero_words. # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000007f70b22a50, pid=12602, tid=12633 # # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-2016-11-16-004839.dinesh.openjdk9hs) # Java VM: OpenJDK 64-Bit Server VM (9-internal+0-2016-11-16-004839.dinesh.openjdk9hs, mixed mode, tiered, parallel gc, linux-aarch64) # Problematic frame: # v ~RuntimeStub::fast_new_instance Runtime1 stub # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /user/dinesh/temp/JTwork/scratch/core.12602) The pc address maps to instructions in eden_allocate(). Looks like large memory is not being handled properly by eden_allocate(). Or if block_zero() is polluting the memory. This is the code that I am concerned on: hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp: 3999 // if end < obj then we wrapped around high memory 4000 cmp(end, obj); 4001 br(Assembler::LO, slow_case); 4002 4003 cmp(end, heap_end); 4004 br(Assembler::HI, slow_case); 4005 4006 // If heap_top hasn't been changed by some other thread, update it. 4007 stlxr(rscratch2, end, rscratch1); 4008 cbnzw(rscratch2, retry); I haven't got a solution yet. Wondering if I can get any help from this forum. Regards, Kavitha On 16 November 2016 at 23:22, Andrew Haley wrote: > On 16/11/16 17:08, White, Derek wrote: > > > But I still suggest calling zero_words in > > MacroAssembler::tlab_refill(). > > > > The whole point of the ZeroTLAB flag is if bulk clearing the TLAB is > > faster than piecemeal clearing as needed. Doing a simpler > > zero_memory just has the potential to pollute the cache > > unnecessarily. The extra size of calling zero_words here only comes > > into play if ZeroTLAB flag is on, and the macro should only be > > expanded once in any case. > > Sounds reasonable. This will need to be submitted to hotspot-dev for > formal approval. > > Andrew. > From aph at redhat.com Tue Dec 13 14:51:00 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Dec 2016 14:51:00 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: <50bb8087-d116-a1e5-50f2-9c4226b73c75@redhat.com> On 13/12/16 10:57, Kavitha Natarajan wrote: > I haven't got a solution yet. Wondering if I can get any help from this > forum. Sure, but we'll need to see your patch and test case. Andrew. From rwestrel at redhat.com Tue Dec 13 16:58:04 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 13 Dec 2016 16:58:04 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u: 8170873: PPC64/aarch64: Poor StrictMath performance due to non-optimized compilation Message-ID: <201612131658.uBDGw4jC017923@aojmv0008.oracle.com> Changeset: 7dc91fd23728 Author: gromero Date: 2016-12-12 08:01 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/rev/7dc91fd23728 8170873: PPC64/aarch64: Poor StrictMath performance due to non-optimized compilation Reviewed-by: mdoerr, erikj, simonis, aph ! make/common/NativeCompilation.gmk From rwestrel at redhat.com Tue Dec 13 16:58:38 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Tue, 13 Dec 2016 16:58:38 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jdk: 8170873: PPC64/aarch64: Poor StrictMath performance due to non-optimized compilation Message-ID: <201612131658.uBDGwdt6018133@aojmv0008.oracle.com> Changeset: 7c54c63ba667 Author: gromero Date: 2016-12-12 08:06 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/7c54c63ba667 8170873: PPC64/aarch64: Poor StrictMath performance due to non-optimized compilation Reviewed-by: mdoerr, erikj, simonis, aph ! make/lib/CoreLibraries.gmk From Derek.White at cavium.com Tue Dec 13 17:27:55 2016 From: Derek.White at cavium.com (White, Derek) Date: Tue, 13 Dec 2016 17:27:55 +0000 Subject: [aarch64-port-dev ] RFR(XS) [aarch64] hs_err logs do not print register mappings Message-ID: Please review this simple change to have the hs_err logs print register mappings on aarch64 as they are on other platforms. See end of message for example. BUG: https://bugs.openjdk.java.net/browse/JDK-8171129 WEBREV: http://cr.openjdk.java.net/~drwhite/8171129/webrev.01/ Tested by crashing the JVM (thanks Unsafe!) Thanks, - Derek White Old Output (example): Register to memory mapping: R0=0x00000000ffffffff . . (etc) . R30=0x0000400007cd7514 New output (example): Register to memory mapping: R0 =0x0000000000000000 is an unknown value R1 =0x0000000101d08388 is an oop sun.misc.Unsafe {0x0000000101d08388} - klass: 'sun/misc/Unsafe' - ---- fields (total size 2 words): R2 =0x000000000000000d is an unknown value R3 =0x0000ffffa801aaa0 is an unknown value R4 =0x0000ffffb0552074: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 R5 =0x0000ffffb048a000: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 R6 =0x0000000000000004 is an unknown value R7 =0x0000ffffa801aaa0 is an unknown value R8 =0x0000ffff9875e480 is at entry_point+64 in (nmethod*)0x0000ffff9875e290 R9 =0xffffffffffff0000 is an unknown value R10=0x0000ffffa80184a8 is an unknown value R11=0x0000000000000000 is an unknown value R12={method} {0x0000fffcf18455e0} 'getByte' '(J)B' in 'sun/misc/Unsafe' R13=0x0000ffffb04913ca: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 R14=0x0000000000000001 is an unknown value R15=0x0000ffffaee0d8e8 is pointing into the stack for thread: 0x0000ffffa801a800 R16=0xfefefefefefefefe is an unknown value R17=0x0000000101d07cd0 is an oop java.lang.Class {0x0000000101d07cd0} - klass: 'java/lang/Class' - ---- fields (total size 14 words): - private volatile transient strict 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @12 NULL (0 0) - private volatile transient strict 'newInstanceCallerCache' 'Ljava/lang/Class;' @16 NULL (0 203a0f aa) - private transient 'name' 'Ljava/lang/String;' @20 "segvtest.SEGVTest"{0x0000000101d07d50} (203a0f aa 203936bd) - private transient 'module' 'Ljava/lang/reflect/Module;' @24 a 'java/lang/reflect/Module'{0x000000 0101c9b5e8} (203936bd 0) - private final 'classLoader' 'Ljava/lang/ClassLoader;' @28 NULL (0 0) - private 'packageName' 'Ljava/lang/String;' @32 NULL (0 0) - private final strict 'componentType' 'Ljava/lang/Class;' @36 NULL (0 203a0fdc) - private volatile transient strict 'reflectionData' 'Ljava/lang/ref/SoftReference;' @40 a 'java/la ng/ref/SoftReference'{0x0000000101d07ee0} (203a0fdc 0) - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @44 NULL (0 0) - private volatile transient strict 'enumConstants' '[Ljava/lang/Object;' @48 NULL (0 0) - private volatile transient strict 'enumConstantDirectory' 'Ljava/util/Map;' @52 NULL (0 0) - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @56 NULL (0 0) - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @60 NULL (0 0) - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @64 NULL (0 0) - private volatile transient 'classRedefinedCount' 'I' @96 0 - signature: Lsegvtest/SEGVTest; - fake entry for mirror: 'segvtest/SEGVTest' - fake entry for array: NULL - fake entry for oop_size: 14 - fake entry for static_oop_field_count: 0 R18=0x0000ffffb050d50c: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 R19=0x00000000000000b8 is an unknown value R20=0x0000ffffaee0e328 is pointing into the stack for thread: 0x0000ffffa801a800 R21=0x0000ffffb055ef90: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 R22=0x0000fffcf1840471 is pointing into metadata R23=0x0000ffffaee0e520 is pointing into the stack for thread: 0x0000ffffa801a800 R24=0x0000ffffaee0e390 is pointing into the stack for thread: 0x0000ffffa801a800 R25=0x0000ffff9792a6ec is at begin+0 in a stub StubRoutines::call_stub [0x0000ffff9792a6ec, 0x0000ffff9792a920[ (564 bytes) R26=0x0000fffcf1842160 is pointing into metadata R27=0x0000000000000000 is an unknown value R28=0x0000ffffa801a800 is a thread R29=0x0000ffffaee0e380 is pointing into the stack for thread: 0x0000ffffa801a800 R30=0x0000ffff98757764 is at entry_point+100 in (nmethod*)0x0000ffff98757510 From bob.vandette at oracle.com Tue Dec 13 18:16:08 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 13 Dec 2016 13:16:08 -0500 Subject: [aarch64-port-dev ] JEP 297: Unified arm32/arm64 Port latest Merge Message-ID: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com> Here?s the latest patches for adding the Unified arm32/64 sources to the JDK 9 hotspot forest. I?ve merged up with the latest AOT and Jigsaw changes in http://hg.openjdk.java.net/jdk9/hs as of yesterday. http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/ http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/ http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/ I?m not planning on updating the jdk9-arm3264 forest since I?m trying to maintain a single collection of changesets to be used to integrate into jdk9/dev, assuming I get the go ahead. Bob. From vladimir.kozlov at oracle.com Tue Dec 13 18:29:03 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Dec 2016 10:29:03 -0800 Subject: [aarch64-port-dev ] JEP 297: Unified arm32/arm64 Port latest Merge In-Reply-To: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com> References: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com> Message-ID: <0746f552-7a19-8159-493d-dc5f12df72a1@oracle.com> On 12/13/16 10:16 AM, Bob Vandette wrote: > Here?s the latest patches for adding the Unified arm32/64 sources to the JDK 9 hotspot forest. > > I?ve merged up with the latest AOT and Jigsaw changes in http://hg.openjdk.java.net/jdk9/hs as of yesterday. Good. > > http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/ > http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/ > http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/ > > I?m not planning on updating the jdk9-arm3264 forest since I?m trying to maintain a single > collection of changesets to be used to integrate into jdk9/dev, assuming I get the go ahead. Fine with me. Thanks, Vladimir > > Bob. > From david.holmes at oracle.com Wed Dec 14 05:33:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2016 15:33:03 +1000 Subject: [aarch64-port-dev ] RFR(XS) [aarch64] hs_err logs do not print register mappings In-Reply-To: References: Message-ID: On 14/12/2016 3:27 AM, White, Derek wrote: > Please review this simple change to have the hs_err logs print register mappings on aarch64 as they are on other platforms. See end of message for example. > > BUG: https://bugs.openjdk.java.net/browse/JDK-8171129 > > WEBREV: http://cr.openjdk.java.net/~drwhite/8171129/webrev.01/ Looks okay, but what about the BUILTIN_SIM case? David > Tested by crashing the JVM (thanks Unsafe!) > > Thanks, > > > - Derek White > > Old Output (example): > Register to memory mapping: > > R0=0x00000000ffffffff > . > . (etc) > . > R30=0x0000400007cd7514 > > New output (example): > Register to memory mapping: > > R0 =0x0000000000000000 is an unknown value > R1 =0x0000000101d08388 is an oop > sun.misc.Unsafe > {0x0000000101d08388} - klass: 'sun/misc/Unsafe' > - ---- fields (total size 2 words): > R2 =0x000000000000000d is an unknown value > R3 =0x0000ffffa801aaa0 is an unknown value > R4 =0x0000ffffb0552074: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 > R5 =0x0000ffffb048a000: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 > R6 =0x0000000000000004 is an unknown value > R7 =0x0000ffffa801aaa0 is an unknown value > R8 =0x0000ffff9875e480 is at entry_point+64 in (nmethod*)0x0000ffff9875e290 > R9 =0xffffffffffff0000 is an unknown value > R10=0x0000ffffa80184a8 is an unknown value > R11=0x0000000000000000 is an unknown value > R12={method} {0x0000fffcf18455e0} 'getByte' '(J)B' in 'sun/misc/Unsafe' > R13=0x0000ffffb04913ca: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 > R14=0x0000000000000001 is an unknown value > R15=0x0000ffffaee0d8e8 is pointing into the stack for thread: 0x0000ffffa801a800 > R16=0xfefefefefefefefe is an unknown value > R17=0x0000000101d07cd0 is an oop > java.lang.Class > {0x0000000101d07cd0} - klass: 'java/lang/Class' > - ---- fields (total size 14 words): > - private volatile transient strict 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @12 NULL > (0 0) > - private volatile transient strict 'newInstanceCallerCache' 'Ljava/lang/Class;' @16 NULL (0 203a0f > aa) > - private transient 'name' 'Ljava/lang/String;' @20 "segvtest.SEGVTest"{0x0000000101d07d50} (203a0f > aa 203936bd) > - private transient 'module' 'Ljava/lang/reflect/Module;' @24 a 'java/lang/reflect/Module'{0x000000 > 0101c9b5e8} (203936bd 0) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @28 NULL (0 0) > - private 'packageName' 'Ljava/lang/String;' @32 NULL (0 0) > - private final strict 'componentType' 'Ljava/lang/Class;' @36 NULL (0 203a0fdc) > - private volatile transient strict 'reflectionData' 'Ljava/lang/ref/SoftReference;' @40 a 'java/la > ng/ref/SoftReference'{0x0000000101d07ee0} (203a0fdc 0) > - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @44 > NULL (0 0) > - private volatile transient strict 'enumConstants' '[Ljava/lang/Object;' @48 NULL (0 0) > - private volatile transient strict 'enumConstantDirectory' 'Ljava/util/Map;' @52 NULL (0 0) > - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @56 NULL (0 0) > - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @60 NULL (0 > 0) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @64 NULL (0 0) > - private volatile transient 'classRedefinedCount' 'I' @96 0 > - signature: Lsegvtest/SEGVTest; > - fake entry for mirror: 'segvtest/SEGVTest' > - fake entry for array: NULL > - fake entry for oop_size: 14 > - fake entry for static_oop_field_count: 0 > R18=0x0000ffffb050d50c: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 > R19=0x00000000000000b8 is an unknown value > R20=0x0000ffffaee0e328 is pointing into the stack for thread: 0x0000ffffa801a800 > R21=0x0000ffffb055ef90: in /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so at 0x0000ffffaeec0000 > R22=0x0000fffcf1840471 is pointing into metadata > R23=0x0000ffffaee0e520 is pointing into the stack for thread: 0x0000ffffa801a800 > R24=0x0000ffffaee0e390 is pointing into the stack for thread: 0x0000ffffa801a800 > R25=0x0000ffff9792a6ec is at begin+0 in a stub > StubRoutines::call_stub [0x0000ffff9792a6ec, 0x0000ffff9792a920[ (564 bytes) > R26=0x0000fffcf1842160 is pointing into metadata > R27=0x0000000000000000 is an unknown value > R28=0x0000ffffa801a800 is a thread > R29=0x0000ffffaee0e380 is pointing into the stack for thread: 0x0000ffffa801a800 > R30=0x0000ffff98757764 is at entry_point+100 in (nmethod*)0x0000ffff98757510 > From kavitha.natarajan at linaro.org Wed Dec 14 08:01:06 2016 From: kavitha.natarajan at linaro.org (Kavitha Natarajan) Date: Wed, 14 Dec 2016 13:31:06 +0530 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: <50bb8087-d116-a1e5-50f2-9c4226b73c75@redhat.com> References: <50bb8087-d116-a1e5-50f2-9c4226b73c75@redhat.com> Message-ID: Thanks Andrew. Below is the webrev of the patch: http://people.linaro.org/~kavitha.natarajan/8169177/webrev.01/ Older one with zero_memory() that worked is here: http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ Test case is in : hotspot/test/compiler/stringopts/TestStringObjec tInitialization.java Regards, Kavitha On 13 December 2016 at 20:21, Andrew Haley wrote: > On 13/12/16 10:57, Kavitha Natarajan wrote: > > I haven't got a solution yet. Wondering if I can get any help from this > > forum. > > Sure, but we'll need to see your patch and test case. > > Andrew. > > From adinn at redhat.com Wed Dec 14 12:46:38 2016 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 14 Dec 2016 12:46:38 +0000 Subject: [aarch64-port-dev ] RFR(XS) [aarch64] hs_err logs do not print register mappings In-Reply-To: References: Message-ID: On 14/12/16 05:33, David Holmes wrote: > On 14/12/2016 3:27 AM, White, Derek wrote: >> Please review this simple change to have the hs_err logs print >> register mappings on aarch64 as they are on other platforms. See end >> of message for example. >> >> BUG: https://bugs.openjdk.java.net/browse/JDK-8171129 >> >> WEBREV: http://cr.openjdk.java.net/~drwhite/8171129/webrev.01/ > > Looks okay, but what about the BUILTIN_SIM case? The code included via BUILTIN_SIM was only ever relevant to JDK8. We used the BUILTIN_SIM paths to bootstrap the AArch64 code on x86 (it makes the JVM jump into an AArch64 simulator whenever it enters JITted AArch64 code and back again when it calls out to non-JITted code :-). The BUILTIN_SIM code no longer works in JDK8. It was upstreamed into JDK9 wholesale along with all other changes ti support AArch64. However, the upstreamed BUILTIN_SIM code never worked in JDK9. A separate JIRA to address its removal from both JDK8 and JDK9 code bases might be worth raising but that problem should not be allowed to hinder this 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 aph at redhat.com Wed Dec 14 13:19:43 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 14 Dec 2016 13:19:43 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: <50bb8087-d116-a1e5-50f2-9c4226b73c75@redhat.com> Message-ID: <1b4dad61-1231-faa4-6d34-48c09bdeeeff@redhat.com> On 14/12/16 08:01, Kavitha Natarajan wrote: > Thanks Andrew. Below is the webrev of the patch: > > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.01/ > > Older one with zero_memory() that worked is here: > > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ > > Test case is in : hotspot/test/compiler/stringopts/TestStringObjectInitialization.java The problem is due to the call of _zero_longs() from block_zero(). block_zero()is a buggy macro: it only works with r10 and r11 as its arguments and it trashes LR. Macros must not do this. So, if you're going to call block_zero() from arbitrary code you must save and restore r10, r11, and lr. block_zero() really should be rewritten to take any registers as base and cnt and save and restore any scratch registers it uses. Then it could be safely used as a real assembler macro. But we are too late in the JDK 9 cycle for any of this: it is an enhancement. We will go with the first version of the patch. Thanks, Andrew. From aph at redhat.com Wed Dec 14 13:40:36 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 14 Dec 2016 13:40:36 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: <1b4dad61-1231-faa4-6d34-48c09bdeeeff@redhat.com> References: <50bb8087-d116-a1e5-50f2-9c4226b73c75@redhat.com> <1b4dad61-1231-faa4-6d34-48c09bdeeeff@redhat.com> Message-ID: <6fe0ff29-a08c-eaaf-e957-b29553472331@redhat.com> I created JDK-8171237, AArch64: MacroAssembler::zero_words uses fixed registers and trashes LR. https://bugs.openjdk.java.net/browse/JDK-8171237 Andrew. From Derek.White at cavium.com Wed Dec 14 17:25:11 2016 From: Derek.White at cavium.com (White, Derek) Date: Wed, 14 Dec 2016 17:25:11 +0000 Subject: [aarch64-port-dev ] RFR(XS) [aarch64] hs_err logs do not print register mappings In-Reply-To: References: Message-ID: Thanks for the review David. And yes, it will be nice to clear out the BUILTIN_SIM code some day! - Derek -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Wednesday, December 14, 2016 12:33 AM To: White, Derek ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS) [aarch64] hs_err logs do not print register mappings On 14/12/2016 3:27 AM, White, Derek wrote: > Please review this simple change to have the hs_err logs print register mappings on aarch64 as they are on other platforms. See end of message for example. > > BUG: https://bugs.openjdk.java.net/browse/JDK-8171129 > > WEBREV: http://cr.openjdk.java.net/~drwhite/8171129/webrev.01/ Looks okay, but what about the BUILTIN_SIM case? David > Tested by crashing the JVM (thanks Unsafe!) > > Thanks, > > > - Derek White > > Old Output (example): > Register to memory mapping: > > R0=0x00000000ffffffff > . > . (etc) > . > R30=0x0000400007cd7514 > > New output (example): > Register to memory mapping: > > R0 =0x0000000000000000 is an unknown value > R1 =0x0000000101d08388 is an oop > sun.misc.Unsafe > {0x0000000101d08388} - klass: 'sun/misc/Unsafe' > - ---- fields (total size 2 words): > R2 =0x000000000000000d is an unknown value > R3 =0x0000ffffa801aaa0 is an unknown value > R4 =0x0000ffffb0552074: in > /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so > at 0x0000ffffaeec0000 > R5 =0x0000ffffb048a000: in > /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so > at 0x0000ffffaeec0000 > R6 =0x0000000000000004 is an unknown value > R7 =0x0000ffffa801aaa0 is an unknown value > R8 =0x0000ffff9875e480 is at entry_point+64 in > (nmethod*)0x0000ffff9875e290 > R9 =0xffffffffffff0000 is an unknown value > R10=0x0000ffffa80184a8 is an unknown value > R11=0x0000000000000000 is an unknown value R12={method} > {0x0000fffcf18455e0} 'getByte' '(J)B' in 'sun/misc/Unsafe' > R13=0x0000ffffb04913ca: in > /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so > at 0x0000ffffaeec0000 > R14=0x0000000000000001 is an unknown value > R15=0x0000ffffaee0d8e8 is pointing into the stack for thread: > 0x0000ffffa801a800 R16=0xfefefefefefefefe is an unknown value > R17=0x0000000101d07cd0 is an oop > java.lang.Class > {0x0000000101d07cd0} - klass: 'java/lang/Class' > - ---- fields (total size 14 words): > - private volatile transient strict 'cachedConstructor' > 'Ljava/lang/reflect/Constructor;' @12 NULL > (0 0) > - private volatile transient strict 'newInstanceCallerCache' > 'Ljava/lang/Class;' @16 NULL (0 203a0f > aa) > - private transient 'name' 'Ljava/lang/String;' @20 > "segvtest.SEGVTest"{0x0000000101d07d50} (203a0f aa 203936bd) > - private transient 'module' 'Ljava/lang/reflect/Module;' @24 a > 'java/lang/reflect/Module'{0x000000 > 0101c9b5e8} (203936bd 0) > - private final 'classLoader' 'Ljava/lang/ClassLoader;' @28 NULL (0 > 0) > - private 'packageName' 'Ljava/lang/String;' @32 NULL (0 0) > - private final strict 'componentType' 'Ljava/lang/Class;' @36 NULL > (0 203a0fdc) > - private volatile transient strict 'reflectionData' > 'Ljava/lang/ref/SoftReference;' @40 a 'java/la > ng/ref/SoftReference'{0x0000000101d07ee0} (203a0fdc 0) > - private volatile transient 'genericInfo' > 'Lsun/reflect/generics/repository/ClassRepository;' @44 NULL (0 0) > - private volatile transient strict 'enumConstants' > '[Ljava/lang/Object;' @48 NULL (0 0) > - private volatile transient strict 'enumConstantDirectory' > 'Ljava/util/Map;' @52 NULL (0 0) > - private volatile transient 'annotationData' > 'Ljava/lang/Class$AnnotationData;' @56 NULL (0 0) > - private volatile transient 'annotationType' > 'Lsun/reflect/annotation/AnnotationType;' @60 NULL (0 > 0) > - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @64 > NULL (0 0) > - private volatile transient 'classRedefinedCount' 'I' @96 0 > - signature: Lsegvtest/SEGVTest; > - fake entry for mirror: 'segvtest/SEGVTest' > - fake entry for array: NULL > - fake entry for oop_size: 14 > - fake entry for static_oop_field_count: 0 > R18=0x0000ffffb050d50c: in > /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so > at 0x0000ffffaeec0000 > R19=0x00000000000000b8 is an unknown value > R20=0x0000ffffaee0e328 is pointing into the stack for thread: > 0x0000ffffa801a800 > R21=0x0000ffffb055ef90: in > /mnt/diskc/dwhite/new-memcpy-ws/build/linux-aa > rch64-normal-server-fastdebug/images/jdk/lib/aarch64/server/libjvm.so > at 0x0000ffffaeec0000 > R22=0x0000fffcf1840471 is pointing into metadata > R23=0x0000ffffaee0e520 is pointing into the stack for thread: > 0x0000ffffa801a800 > R24=0x0000ffffaee0e390 is pointing into the stack for thread: > 0x0000ffffa801a800 R25=0x0000ffff9792a6ec is at begin+0 in a stub > StubRoutines::call_stub [0x0000ffff9792a6ec, 0x0000ffff9792a920[ (564 > bytes) > R26=0x0000fffcf1842160 is pointing into metadata > R27=0x0000000000000000 is an unknown value > R28=0x0000ffffa801a800 is a thread > R29=0x0000ffffaee0e380 is pointing into the stack for thread: 0x0000ffffa801a800 > R30=0x0000ffff98757764 is at entry_point+100 in (nmethod*)0x0000ffff98757510 > From kavitha.natarajan at linaro.org Thu Dec 15 07:03:16 2016 From: kavitha.natarajan at linaro.org (Kavitha Natarajan) Date: Thu, 15 Dec 2016 12:33:16 +0530 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: <6fe0ff29-a08c-eaaf-e957-b29553472331@redhat.com> References: <50bb8087-d116-a1e5-50f2-9c4226b73c75@redhat.com> <1b4dad61-1231-faa4-6d34-48c09bdeeeff@redhat.com> <6fe0ff29-a08c-eaaf-e957-b29553472331@redhat.com> Message-ID: Thanks Andrew, for the clarifications. I will post the first patch to hotspot-dev as well and take it to closure. Regards, Kavitha On 14 December 2016 at 19:10, Andrew Haley wrote: > I created JDK-8171237, AArch64: MacroAssembler::zero_words uses fixed > registers and trashes LR. > > https://bugs.openjdk.java.net/browse/JDK-8171237 > > Andrew. > > From ci_notify at linaro.org Thu Dec 15 09:19:32 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 15 Dec 2016 09:19:32 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <281739070.613.1481793572523.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/349/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 9: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 9: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 1: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 2: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 3: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 5: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 6: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 7: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 8: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 9: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 10: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 12: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 13: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 14: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 10: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 11: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 12: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 13: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 1: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 2: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 3: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 5: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 6: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 7: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 8: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 10: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 12: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 13: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 14: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.98x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.02, Server: 101.55 Client 72.02 / Client 2014-04-01 (43.00): 1.67x Server 101.55 / Server 2014-04-01 (71.00): 1.43x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From kavitha.natarajan at linaro.org Thu Dec 15 09:55:42 2016 From: kavitha.natarajan at linaro.org (Kavitha Natarajan) Date: Thu, 15 Dec 2016 15:25:42 +0530 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options Message-ID: Hi, I am re-posting the review request on hotspot-dev which I had missed earlier. The below bug fix was already posted in aarch64-port-dev and hotspot-compiler-dev mailing lists. The following are the jtreg test cases that fail with SIGSEGV on aarch64 when "-XX:+ZeroTLAB" is specified along with a GC option: hotspot/test/compiler/stringopts/TestStringObjectInitialization.java hotspot/test/gc/TestSystemGC.java hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java hotspot/test/gc/cms/TestBubbleUpRef.java hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java hotspot/test/gc/parallel/TestDynShrinkHeap.java hotspot/test/gc/stress/TestGCOld.java Bug fix for JDK-8086053 (Address inconsistencies regarding ZeroTLAB) fixes similar issue on x86 and sparc. This fix has been ported to aarch64 and the above test cases now pass on aarch64 as well. Below is the webrev for the aarch64 changes: http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ Derek White and Andrew Haley had done the review and suggested to use zero_memory() only in C1 and zero_words() in C2. However, zero_words itself need to be enhanced before its been used. So currenly zero_memory() is only used for both C1 and C2. A separate enhancement request has been raised for zero_words(). https://bugs.openjdk.java.net/browse/JDK-8171237 Please review and approve. Thanks, Kavitha From ci_notify at linaro.org Thu Dec 15 10:01:56 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 15 Dec 2016 10:01:56 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <2121461123.630.1481796116672.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/349/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 9: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 9: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/22 pass: 1,316; fail: 9; error: 44 Build 1: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 2: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 3: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 4: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 5: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 6: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 7: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 8: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 9: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 10: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 12: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 13: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 14: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 10: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 11: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 12: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 13: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/22 pass: 3,727; fail: 20; error: 33 Build 1: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 2: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 3: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 4: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 5: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 6: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 7: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 8: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 9: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 10: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 11: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 12: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 13: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 14: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.98x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.02, Server: 101.55 Client 72.02 / Client 2014-04-01 (43.00): 1.67x Server 101.55 / Server 2014-04-01 (71.00): 1.43x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From edward.nevill at gmail.com Thu Dec 15 10:23:44 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 15 Dec 2016 10:23:44 +0000 Subject: [aarch64-port-dev ] JEP 297: Unified arm32/arm64 Port latest Merge In-Reply-To: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com> References: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com> Message-ID: <1481797424.2342.8.camel@gmail.com> On Tue, 2016-12-13 at 13:16 -0500, Bob Vandette wrote: > Here?s the latest patches for adding the Unified arm32/64 sources to the JDK 9 hotspot forest. > > I?ve merged up with the latest AOT and Jigsaw changes in http://hg.openjdk.java.net/jdk9/hs as of yesterday.? > > http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/ > http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/ > http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/ > Looks good. I have built the hs repo with these patches and run jtreg on x86, arm64 and arm32. Here is a summary of the results. x86: hotspot: passed: 1,372; failed: 30; error: 55 langtools: 3,773; failed: 12; error: 9 jdk: passed: 6,378; failed: 202; error: 10 arm64: hotspot: passed: 1,315; failed: 31; error: 49 langtools: 3,772; failed: 10; error: 10 jdk: passed: 6,433; failed: 148; error: 8 arm32: hotspot: 1,212; failed: 50; error: 48 langtools: passed: 3,771; failed: 14; error: 9 jdk: passed: 6,043; failed: 442; error: 18 There were no failures due to fatal errors (ie, SEGV, ABORT, assert/guarantee failure etc). Currently running jcstress, results in approx 10 hours. All the best, Ed. From david.holmes at oracle.com Thu Dec 15 10:26:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2016 20:26:49 +1000 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: Hi Kavitha, Please note that is a requirement that all contributions be hosted on openjdk systems (cr.openjdk.java.net) or else included in-line with openjdk email. They can not be taken directly from external systems like people.linaro.org. Thanks, David On 15/12/2016 7:55 PM, Kavitha Natarajan wrote: > Hi, > > I am re-posting the review request on hotspot-dev which I had missed > earlier. > > The below bug fix was already posted in aarch64-port-dev and > hotspot-compiler-dev mailing lists. > > The following are the jtreg test cases that fail with SIGSEGV on aarch64 > when "-XX:+ZeroTLAB" is specified along with a GC option: > > hotspot/test/compiler/stringopts/TestStringObjectInitialization.java > hotspot/test/gc/TestSystemGC.java > hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java > hotspot/test/gc/cms/TestBubbleUpRef.java > hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java > hotspot/test/gc/parallel/TestDynShrinkHeap.java > hotspot/test/gc/stress/TestGCOld.java > > Bug fix for JDK-8086053 > (Address > inconsistencies regarding ZeroTLAB) fixes similar issue on x86 and sparc. > This fix has been ported to aarch64 and the above test cases now pass on > aarch64 as well. > > Below is the webrev for the aarch64 changes: > > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ > > Derek White and Andrew Haley had done the review and suggested to use > zero_memory() only in C1 and zero_words() in C2. However, zero_words itself > need to be enhanced before its been used. So currenly zero_memory() is only > used for both C1 and C2. > > A separate enhancement request has been raised for zero_words(). > > https://bugs.openjdk.java.net/browse/JDK-8171237 > > Please review and approve. > > Thanks, > Kavitha > From ci_notify at linaro.org Fri Dec 16 09:52:13 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 16 Dec 2016 09:52:13 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <107440371.922.1481881933653.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/350/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 9: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 10: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 8: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 9: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 10: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/24 pass: 1,314; fail: 11; error: 44 Build 1: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 2: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 3: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 4: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 5: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 6: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 7: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 8: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 9: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 10: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 11: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 12: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 13: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 14: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/19 pass: 7,199; fail: 644; error: 38 Build 1: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 2: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 3: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 4: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 5: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 6: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 7: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 8: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 9: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 10: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 11: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 12: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 13: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 14: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/24 pass: 3,745; fail: 2; error: 33 Build 1: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 2: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 3: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 4: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 5: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 6: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 7: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 8: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 9: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 10: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 11: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 12: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 13: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 14: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.89x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.38, Server: 110.27 Client 72.38 / Client 2014-04-01 (43.00): 1.68x Server 110.27 / Server 2014-04-01 (71.00): 1.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From kavitha.natarajan at linaro.org Fri Dec 16 12:17:10 2016 From: kavitha.natarajan at linaro.org (Kavitha Natarajan) Date: Fri, 16 Dec 2016 17:47:10 +0530 Subject: [aarch64-port-dev ] RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: Thanks a lot Felix for creating the patch, as I do not have access to this system. Regards, Kavitha On 16 December 2016 at 17:29, Felix Yang wrote: > Hi, > > Thanks for fixing the bug. New webrev created on behalf of Kavitha: > http://cr.openjdk.java.net/~fyang/8169177/webrev.01/ > Tested again with JTreg hotspot, no regressions. OK to push? > > Thanks for your help, > Felix > > On 16 December 2016 at 18:28, Kavitha Natarajan < > kavitha.natarajan at linaro.org> wrote: > >> Thanks Andrew. >> >> Regards, >> Kavitha >> >> On 15 December 2016 at 15:34, Andrew Haley wrote: >> >>> On 15/12/16 09:55, Kavitha Natarajan wrote: >>> > Below is the webrev for the aarch64 changes: >>> > >>> > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ >>> >>> This is OK. >>> >>> Andrew. >>> >>> >> > From ci_notify at linaro.org Sat Dec 17 08:57:35 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 17 Dec 2016 08:57:35 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1156411539.1345.1481965055839.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/351/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 9: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 10: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 11: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 8: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 9: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 9: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 10: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 11: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/25 pass: 1,310; fail: 11; error: 48 Build 1: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 2: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 3: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 4: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 5: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 6: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 7: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 8: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 9: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 10: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 11: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 12: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 13: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 14: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/22 pass: 7,202; fail: 636; error: 40 Build 1: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 2: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 3: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 4: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 5: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 6: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 7: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 8: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 9: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 10: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 11: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 12: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 13: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 14: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/25 pass: 3,748; fail: 1; error: 32 Build 1: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 2: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 3: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 4: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 5: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 6: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 7: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 8: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 9: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 10: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 11: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 12: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 13: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 14: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.38, Server: 109.42 Client 72.38 / Client 2014-04-01 (43.00): 1.68x Server 109.42 / Server 2014-04-01 (71.00): 1.54x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From ci_notify at linaro.org Sun Dec 18 09:38:08 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 18 Dec 2016 09:38:08 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1699952083.1450.1482053888935.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/352/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 9: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 10: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 11: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 12: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 8: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 9: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 10: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 9: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 10: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 11: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 12: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/26 pass: 1,310; fail: 11; error: 48 Build 1: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 2: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 3: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 4: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 5: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 6: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 7: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 8: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 9: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 10: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 11: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 12: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 13: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 14: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/24 pass: 7,214; fail: 629; error: 42 Build 1: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 2: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 3: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 4: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 5: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 6: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 7: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 8: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 9: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 10: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 11: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 12: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 13: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 14: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/26 pass: 3,748; fail: 1; error: 32 Build 1: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 2: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 3: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 4: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 5: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 6: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 7: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 8: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 9: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 10: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 11: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 12: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 13: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 14: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.79x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.38, Server: 109.42 Client 72.38 / Client 2014-04-01 (43.00): 1.68x Server 109.42 / Server 2014-04-01 (71.00): 1.54x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/327/results/ 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From ci_notify at linaro.org Mon Dec 19 09:00:27 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 19 Dec 2016 09:00:27 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <971953529.1464.1482138028239.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/353/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 9: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 10: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 11: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 12: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 13: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 8: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 9: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 10: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 11: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 9: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 10: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 11: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 12: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 13: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/28 pass: 1,309; fail: 12; error: 48 Build 1: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 2: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 3: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 4: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 5: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 6: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 7: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 8: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 9: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 10: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 11: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 12: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 13: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 14: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/25 pass: 7,187; fail: 660; error: 38 Build 1: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 2: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 3: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 4: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 5: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 6: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 7: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 8: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 9: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 10: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 11: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 12: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 13: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 14: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/28 pass: 3,750; fail: 1; error: 30 Build 1: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 2: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 3: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 4: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 5: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 6: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 7: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 8: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 9: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 10: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 11: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 12: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 13: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 14: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.01x Relative performance: Server critical-jOPS (nc): 0.93x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.02, Server: 106.13 Client 72.02 / Client 2014-04-01 (43.00): 1.67x Server 106.13 / Server 2014-04-01 (71.00): 1.49x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From edward.nevill at gmail.com Mon Dec 19 10:09:22 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 19 Dec 2016 10:09:22 +0000 Subject: [aarch64-port-dev ] RFR: 8171410: aarch64: long multiplyExact shifts by 31 instead of 63 Message-ID: <1482142162.2883.4.camel@gmail.com> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8171410/webrev (changeset is included inline below because of issues with cr.openjdk.java.net) Bug report here https://bugs.openjdk.java.net/browse/JDK-8171410 The patterns for multplyExact long in aarch64.ad shift by 31 instead of 63 ? 0x000003ff64b29aa8: mul???????x8, x19, x20 ? 0x000003ff64b29aac: smulh?????x9, x19, x20 ? 0x000003ff64b29ab0: cmp???????x9, x8, asr #31??<<<<<<< should be 63 ? 0x000003ff64b29ab4: b.ne??????0x000003ff64b29b4c The effect of this is to cause the overflow branch to be taken in cases where the multiply has not overflowed. For example 0x5a5a5a5a * 0xa5a5a5a5 does not overflow but the overflow branch will be taken above. This was not detected in testing because when the overflow branch is taken C2 causes a call to the real (non intrinsic) multiplyExact to be taken. This then executes correctly. The effect is a degenerate dis-improvement in performance. Using the following test case class Mul { ? static long multest(long a, long b) { long res = a; for (int i = 0; i < 100000000; i++) { res += Math.multiplyExact(a, b); a ^= 1L; b ^= 1L; // Stop loop invariant hoisting } return res; ? } ? public static void main(String argv[]) { ????????long a = 0x5a5a5a5aL; long b = 0xa5a5a5a5L; System.out.println("res " + a + ", " + b + " = " + multest(a, b)); ? } } With -XX:-UseMathExactIntrinsics this takes 1.95 S With -XX:+UseMathExactIntrinsics this takes 13.42 S With the following webrev http://cr.openjdk.java.net/~enevill/8171410/webrev -XX:-UseMathExactIntrinsics takes 1.98 S -XX:+UseMathExactIntrinsics takes??0.95 S --- CUT HERE --- # HG changeset patch # User enevill # Date 1482100004 18000 #??????Sun Dec 18 17:26:44 2016 -0500 # Node ID c0e2c655e28064fd01b54a47915037d8f2423f81 # Parent??66e2100be052e42af8064e519658185112be6dc3 8171410: aarch64: long multiplyExact shifts by 31 instead of 63 Reviewed-by: aph diff --git a/src/cpu/aarch64/vm/aarch64.ad b/src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad +++ b/src/cpu/aarch64/vm/aarch64.ad @@ -14086,7 +14086,7 @@ ? ???format %{ "mul???rscratch1, $op1, $op2\t#overflow check long\n\t" ?????????????"smulh rscratch2, $op1, $op2\n\t" -????????????"cmp???rscratch2, rscratch1, ASR #31\n\t" +????????????"cmp???rscratch2, rscratch1, ASR #63\n\t" ?????????????"movw??rscratch1, #0x80000000\n\t" ?????????????"cselw rscratch1, rscratch1, zr, NE\n\t" ?????????????"cmpw??rscratch1, #1" %} @@ -14094,7 +14094,7 @@ ???ins_encode %{ ?????__ mul(rscratch1, $op1$$Register, $op2$$Register);???// Result bits 0..63 ?????__ smulh(rscratch2, $op1$$Register, $op2$$Register); // Result bits 64..127 -????__ cmp(rscratch2, rscratch1, Assembler::ASR, 31);????// Top is pure sign ext +????__ cmp(rscratch2, rscratch1, Assembler::ASR, 63);????// Top is pure sign ext ?????__ movw(rscratch1, 0x80000000);????????????????????// Develop 0 (EQ), ?????__ cselw(rscratch1, rscratch1, zr, Assembler::NE); // or 0x80000000 (NE) ?????__ cmpw(rscratch1, 1);?????????????????????????????// 0x80000000 - 1 => VS @@ -14112,7 +14112,7 @@ ? ???format %{ "mul???rscratch1, $op1, $op2\t#overflow check long\n\t" ?????????????"smulh rscratch2, $op1, $op2\n\t" -????????????"cmp???rscratch2, rscratch1, ASR #31\n\t" +????????????"cmp???rscratch2, rscratch1, ASR #63\n\t" ?????????????"b$cmp $labl" %} ???ins_cost(4 * INSN_COST); // Branch is rare so treat as INSN_COST ???ins_encode %{ @@ -14120,7 +14120,7 @@ ?????Assembler::Condition cond = (Assembler::Condition)$cmp$$cmpcode; ?????__ mul(rscratch1, $op1$$Register, $op2$$Register);???// Result bits 0..63 ?????__ smulh(rscratch2, $op1$$Register, $op2$$Register); // Result bits 64..127 -????__ cmp(rscratch2, rscratch1, Assembler::ASR, 31);????// Top is pure sign ext +????__ cmp(rscratch2, rscratch1, Assembler::ASR, 63);????// Top is pure sign ext ?????__ br(cond == Assembler::VS ? Assembler::NE : Assembler::EQ, *L); ???%} ? --- CUT HERE --- The patterns for multplyExact long in aarch64.ad shift by 31 instead of 63 ? 0x000003ff64b29aa8: mul???????x8, x19, x20 ? 0x000003ff64b29aac: smulh?????x9, x19, x20 ? 0x000003ff64b29ab0: cmp???????x9, x8, asr #31??<<<<<<< should be 63 ? 0x000003ff64b29ab4: b.ne??????0x000003ff64b29b4c The effect of this is to cause the overflow branch to be taken in cases where the multiply has not overflowed. For example 0x5a5a5a5a * 0xa5a5a5a5 does not overflow but the overflow branch will be taken above. This was not detected in testing because when the overflow branch is taken C2 causes a call to the real (non intrinsic) multiplyExact to be taken. This then executes correctly. The effect is a degenerate dis-improvement in performance. Usingthe following test case class Mul { ? static long multest(long a, long b) { long res = a; for (int i = 0; i < 100000000; i++) { res += Math.multiplyExact(a, b); a ^= 1L; b ^= 1L; // Stop loop invariant hoisting } return res; ? } ? public static void main(String argv[]) { ????????long a = 0x5a5a5a5aL; long b = 0xa5a5a5a5L; System.out.println("res " + a + ", " + b + " = " + multest(a, b)); ? } } With -XX:-UseMathExactIntrinsics this takes 1.95 S With -XX:+UseMathExactIntrinsics this takes 13.42 S With the following webrev http://cr.openjdk.java.net/~enevill/8171410/webrev -XX:-UseMathExactIntrinsics takes 1.98 S -XX:+UseMathExactIntrinsics takes??0.95 S --- CUT HERE --- # HG changeset patch # User enevill # Date 1482100004 18000 #??????Sun Dec 18 17:26:44 2016 -0500 # Node ID c0e2c655e28064fd01b54a47915037d8f2423f81 # Parent??66e2100be052e42af8064e519658185112be6dc3 8171410: aarch64: long multiplyExact shifts by 31 instead of 63 Reviewed-by: aph diff --git a/src/cpu/aarch64/vm/aarch64.ad b/src/cpu/aarch64/vm/aarch64.ad --- a/src/cpu/aarch64/vm/aarch64.ad +++ b/src/cpu/aarch64/vm/aarch64.ad @@ -14086,7 +14086,7 @@ ? ???format %{ "mul???rscratch1, $op1, $op2\t#overflow check long\n\t" ?????????????"smulh rscratch2, $op1, $op2\n\t" -????????????"cmp???rscratch2, rscratch1, ASR #31\n\t" +????????????"cmp???rscratch2, rscratch1, ASR #63\n\t" ?????????????"movw??rscratch1, #0x80000000\n\t" ?????????????"cselw rscratch1, rscratch1, zr, NE\n\t" ?????????????"cmpw??rscratch1, #1" %} @@ -14094,7 +14094,7 @@ ???ins_encode %{ ?????__ mul(rscratch1, $op1$$Register, $op2$$Register);???// Result bits 0..63 ?????__ smulh(rscratch2, $op1$$Register, $op2$$Register); // Result bits 64..127 -????__ cmp(rscratch2, rscratch1, Assembler::ASR, 31);????// Top is pure sign ext +????__ cmp(rscratch2, rscratch1, Assembler::ASR, 63);????// Top is pure sign ext ?????__ movw(rscratch1, 0x80000000);????????????????????// Develop 0 (EQ), ?????__ cselw(rscratch1, rscratch1, zr, Assembler::NE); // or 0x80000000 (NE) ?????__ cmpw(rscratch1, 1);?????????????????????????????// 0x80000000 - 1 => VS @@ -14112,7 +14112,7 @@ ? ???format %{ "mul???rscratch1, $op1, $op2\t#overflow check long\n\t" ?????????????"smulh rscratch2, $op1, $op2\n\t" -????????????"cmp???rscratch2, rscratch1, ASR #31\n\t" +????????????"cmp???rscratch2, rscratch1, ASR #63\n\t" ?????????????"b$cmp $labl" %} ???ins_cost(4 * INSN_COST); // Branch is rare so treat as INSN_COST ???ins_encode %{ @@ -14120,7 +14120,7 @@ ?????Assembler::Condition cond = (Assembler::Condition)$cmp$$cmpcode; ?????__ mul(rscratch1, $op1$$Register, $op2$$Register);???// Result bits 0..63 ?????__ smulh(rscratch2, $op1$$Register, $op2$$Register); // Result bits 64..127 -????__ cmp(rscratch2, rscratch1, Assembler::ASR, 31);????// Top is pure sign ext +????__ cmp(rscratch2, rscratch1, Assembler::ASR, 63);????// Top is pure sign ext ?????__ br(cond == Assembler::VS ? Assembler::NE : Assembler::EQ, *L); ???%} ? --- CUT HERE --- From adinn at redhat.com Mon Dec 19 11:33:45 2016 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 19 Dec 2016 11:33:45 +0000 Subject: [aarch64-port-dev ] RFR: 8171410: aarch64: long multiplyExact shifts by 31 instead of 63 In-Reply-To: <1482142162.2883.4.camel@gmail.com> References: <1482142162.2883.4.camel@gmail.com> Message-ID: Hi Ed, On 19/12/16 10:09, Edward Nevill wrote: > Please review the following webrev ... The change looks good to me. 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 Derek.White at cavium.com Mon Dec 19 21:22:31 2016 From: Derek.White at cavium.com (White, Derek) Date: Mon, 19 Dec 2016 21:22:31 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release Message-ID: As the "FIXME" noted, aarch64 really does need to use a store release in the "store_klass" macro, at least when a concurrent GC is in effect. BUG: https://bugs.openjdk.java.net/browse/JDK-8171449 Webrev: http://cr.openjdk.java.net/~drwhite/8171449/webrev.01/index.html BTW, PPC is likely to need a similar fix... Thanks, - Derek From aph at redhat.com Tue Dec 20 08:43:05 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Dec 2016 08:43:05 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: Message-ID: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> On 19/12/16 21:22, White, Derek wrote: > As the "FIXME" noted, aarch64 really does need to use a store release in the "store_klass" macro, at least when a concurrent GC is in effect. > > BUG: https://bugs.openjdk.java.net/browse/JDK-8171449 > > Webrev: http://cr.openjdk.java.net/~drwhite/8171449/webrev.01/index.html > > BTW, PPC is likely to need a similar fix... > > Thanks, > > > - Derek > I'm a bit baffled by the reasoning behind all of this. If a Java thread isn't finished initializing an array then it's not reachable from another thread. At least, I don't think it is. Maybe I should turn that into a question: how is this newly-allocated array reachable from another thread before that array has been initialized? The patch is OK. It could be simpler, though: void MacroAssembler::store_klass(Register dst, Register src, Register tmp) { // concurrent gcs assume klass length is valid if klass field is not null. bool is_concurrentGC = UseG1GC || UseConcMarkSweepGC; Address klass_field = Address(dst, oopDesc::klass_offset_in_bytes(); if (is_concurrentGC) { lea(tmp, klass_field); if (UseCompressedClassPointers) { encode_klass_not_null(src); stlrw(src, tmp); } else { stlr(src, tmp); } } else { if (UseCompressedClassPointers) { encode_klass_not_null(src); strw(src, klass_field)); } else { str(src, klass_field)); } } } Andrew. From thomas.schatzl at oracle.com Tue Dec 20 09:14:22 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 20 Dec 2016 10:14:22 +0100 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> Message-ID: <1482225262.2831.4.camel@oracle.com> Hi, On Tue, 2016-12-20 at 08:43 +0000, Andrew Haley wrote: > On 19/12/16 21:22, White, Derek wrote: > > > > As the "FIXME" noted, aarch64 really does need to use a store > > release in the "store_klass" macro, at least when a concurrent GC > > is in effect. > > > > BUG: https://bugs.openjdk.java.net/browse/JDK-8171449 > > > > Webrev: http://cr.openjdk.java.net/~drwhite/8171449/webrev.01/index > > .html > > > > BTW, PPC is likely to need a similar fix... > > > > Thanks, > > > > > > -????????Derek > > > I'm a bit baffled by the reasoning behind all of this.??If a Java > thread isn't finished initializing an array then it's not reachable > from another thread.? ? you are probably missing a "Java" between "another" and "thread" here to make this statement correct ;) The concurrent garbage collectors may scan areas of the heap that is currently being allocated into. Setting the object's klass field means to them that the members of the particular object have been completely initialized and can be parsed by the GC thread(s). I did not look at the patch, just answering this question. Thanks, ? Thomas From aph at redhat.com Tue Dec 20 09:21:37 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Dec 2016 09:21:37 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <1482225262.2831.4.camel@oracle.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> Message-ID: <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> On 20/12/16 09:14, Thomas Schatzl wrote: >>> >> I'm a bit baffled by the reasoning behind all of this. If a Java >> thread isn't finished initializing an array then it's not reachable >> from another thread. > > you are probably missing a "Java" between "another" and "thread" here > to make this statement correct ;) > > The concurrent garbage collectors may scan areas of the heap that is > currently being allocated into. Those areas of the heap contain garbage before an object is initialized. They can be pointers into the middle of an object, fields that contain longs which look like object pointers, and so on. Anything is possible: it's just memory. Or do the concurrent collectors scrub the memory being allocated into? > Setting the object's klass field means to them that the members of the > particular object have been completely initialized and can be parsed by > the GC thread(s). So how does a concurrent GC know that a klass field has been written, and does not contain leftover garbage? Andrew. From ci_notify at linaro.org Tue Dec 20 09:34:04 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 20 Dec 2016 09:34:04 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1832064857.1573.1482226444885.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/354/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,310; fail: 10; error: 46 Build 1: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 2: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 9: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 10: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 11: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 12: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 13: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 14: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 8: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 9: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 10: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 11: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 12: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,759; fail: 1; error: 21 Build 1: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 2: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 4: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 5: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 6: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 9: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 10: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 11: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 12: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 13: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 14: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 1,312; fail: 12; error: 45 Build 1: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 2: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 3: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 4: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 5: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 6: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 7: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 8: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 9: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 10: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 11: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 12: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 13: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 14: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/26 pass: 7,226; fail: 619; error: 40 Build 1: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 2: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 3: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 4: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 5: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 6: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 7: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 8: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 9: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 10: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 11: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 12: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 13: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 14: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 3,752; fail: 1; error: 28 Build 1: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 2: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 3: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 4: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 5: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 6: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 7: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 8: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 9: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 10: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 11: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 12: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 13: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 14: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.00x Relative performance: Server critical-jOPS (nc): 0.86x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.58, Server: 108.58 Client 70.58 / Client 2014-04-01 (43.00): 1.64x Server 108.58 / Server 2014-04-01 (71.00): 1.53x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/330/results/ 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From adinn at redhat.com Tue Dec 20 10:01:26 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 20 Dec 2016 10:01:26 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: Message-ID: <80b0494d-3e4c-6004-8b94-10dd7d40519c@redhat.com> On 19/12/16 21:22, White, Derek wrote: > As the "FIXME" noted, aarch64 really does need to use a store release > in the "store_klass" macro, at least when a concurrent GC is in > effect. > > BUG: https://bugs.openjdk.java.net/browse/JDK-8171449 > > Webrev: > http://cr.openjdk.java.net/~drwhite/8171449/webrev.01/index.html > > BTW, PPC is likely to need a similar fix... This looks like only half the story. The stlrw is only going to be of any relevance if code which reads the klass and klass length does so using a ldarw (n.b. these synchronizing instructions will only be needed if there is no other guarantee of memory synchronization between any store and its corresponding load). Can you point to where in the GC code the corresponding loads occur? 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 yang.zhang at linaro.org Tue Dec 20 10:02:51 2016 From: yang.zhang at linaro.org (Yang Zhang) Date: Tue, 20 Dec 2016 18:02:51 +0800 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> Message-ID: Hi Vladimir, Roland The patch has been updated in http://cr.openjdk.java.net/~njian/8169697/webrev.01/. Could you please help to review it again? Regards Yang On 12 December 2016 at 11:42, Yang Zhang wrote: > Hi Vladimir, > > Thanks for your review. > >> >> What about SubV* and MulV* nodes? >> > > After checking commut_op_list, I think MulV*, AndV, OrV and XorV nodes > can also be added. Should I add them all? > > SubV* nodes are not commutative, so I don't think they need to be > considered here. > >> >> I prefer shared code change but we would need to test on all platforms which support vectors. >> > Yeah, we need to test on all platforms. We already tested previous > patch on x86 and aarch64 platforms, but we don't have other platforms. > > Regards > Yang From thomas.schatzl at oracle.com Tue Dec 20 10:21:00 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 20 Dec 2016 11:21:00 +0100 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> Message-ID: <1482229260.2831.48.camel@oracle.com> Hi, On Tue, 2016-12-20 at 09:21 +0000, Andrew Haley wrote: > On 20/12/16 09:14, Thomas Schatzl wrote: > > > > > > > > > > > > > > > > I'm a bit baffled by the reasoning behind all of this.??If a Java > > > thread isn't finished initializing an array then it's not > > > reachable from another thread.? > > ? you are probably missing a "Java" between "another" and "thread" > > here to make this statement correct ;) > > > > The concurrent garbage collectors may scan areas of the heap that > > is currently being allocated into. > > Those areas of the heap contain garbage before an object is > initialized.??They can be pointers into the middle of an object, > fields that contain longs which look like object pointers, and so on. > Anything is possible: it's just memory.??Or do the concurrent > collectors scrub the memory being allocated into? Having a NULL klass value is not the only information the concurrent collectors use for determining whether they can safely scan an area. Further, there are a lot of limitations on what can happen in what order depending on the collector. Derek can very likely tell you more about the protocol between CMS' concurrent threads and the mutators, but both collectors have protocols to ensure that the memory contains valid information, either retrying later (G1), or busy waiting (CMS, afaics from code around a "bugfix for systems with weak memory model" comment) until this is the case. > > Setting the object's klass field means to them that the members of > > the particular object have been completely initialized and can be > > parsed by the GC thread(s). > So how does a concurrent GC know that a klass field has been written, > and does not contain leftover garbage? These threads don't scan random memory, and there is other metadata (in case of G1, the region type for that area, CMS seems to have indicators in its lists) that tell whether the area must either contain a NULL or a valid klass pointer at a specific location. Please look at the discussions for the referenced?https://bugs.openjdk. java.net/browse/JDK-8160369?and its sub-tasks about this for detail about possible orderings and the responses etc. Me trying to explain all the interactions off-hand will surely miss the important, finer details. In case of g1, the participants in this dance are the java threads allocating a humongous object (G1CollectedHeap::humongous_obj_allocate_initialize_regions), the write barrier and the refinement queues. On the reader side, please have a look at G1RemSet::refine_card() and HeapRegion::oops_on_card_seq_iterate_careful()/do_oops_on_card_in_humon gous(). The code contains fairly useful comments I think. Feel free to ask specific questions though. One more pair of eyeballs is always appreciated. Thanks, ? Thomas From aph at redhat.com Tue Dec 20 10:27:51 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Dec 2016 10:27:51 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <1482229260.2831.48.camel@oracle.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> Message-ID: <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> On 20/12/16 10:21, Thomas Schatzl wrote: > Derek can very likely tell you more about the protocol between CMS' > concurrent threads and the mutators, but both collectors have protocols > to ensure that the memory contains valid information, either retrying > later (G1), or busy waiting (CMS, afaics from code around a "bugfix for > systems with weak memory model" comment) until this is the case. Yeah. This stuff doesn't make any sense: I need to see the code. I guess that what's going on is that a humongous object is allocated, the memory is zeroed, and the memory is then returned to the Java thread, which then initializes the object. So, the object is reachable from the GC thread even before it has been initialized. But instances of Class aren't humongous... or are they? Andrew. From thomas.schatzl at oracle.com Tue Dec 20 11:09:21 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 20 Dec 2016 12:09:21 +0100 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> Message-ID: <1482232161.2831.76.camel@oracle.com> On Tue, 2016-12-20 at 10:27 +0000, Andrew Haley wrote: > On 20/12/16 10:21, Thomas Schatzl wrote: > > > > Derek can very likely tell you more about the protocol between CMS' > > concurrent threads and the mutators, but both collectors have > > protocols to ensure that the memory contains valid information, > > either retrying later (G1), or busy waiting (CMS, afaics from code > > around a "bugfix for systems with weak memory model" comment) until > > this is the case. > > Yeah.??This stuff doesn't make any sense: I need to see the code.??I > guess that what's going on is that a humongous object is allocated, > the memory is zeroed, and the memory is then returned to the Java > thread, which then initializes the object.??So, the object is > reachable from the GC thread even before it has been initialized.?? > But instances of Class aren't humongous... or are they? ? you can have instances of regular classes that are humongous. :) There is no limitation on object instance size in the language spec afaik, but at least it allows as large objects as to qualify as humongous. In any case, G1 only ever allocates humongous objects in old gen which makes things a lot easier because these regions can only ever contain that single humongous object and nothing else useful. And we only need to take care about appropriate memory barriers in the runtime because humongous objects are always allocated in the runtime. As for the patch, this changes the generated fast-path eden allocation code, so to be of any problem for the interaction with the concurrent gc threads, the runtime would first have needed to hand out "TLABs" from old gen. G1 never does that, so the patch does not seem to be applicable for it at all, but I think for CMS this seems different. The TLAB allocator for CMS can hand out old gen "TLABs" in some cases, e.g. when the GCLocker prevents an immediate GC when running out of space (I did not confirm this particular case yet). So Derek, can you elaborate a bit on what error case you have in mind? Thanks, ? Thomas From martin.doerr at sap.com Tue Dec 20 11:13:45 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Dec 2016 11:13:45 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> Message-ID: Hi, I think an acquire barrier is missing. See ppc implementation "isync(); // Order load of instance Klass wrt. tags." Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Dienstag, 20. Dezember 2016 11:28 To: Thomas Schatzl ; White, Derek ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(s): 8171449" [aarch64] store_klass needs to use store release On 20/12/16 10:21, Thomas Schatzl wrote: > Derek can very likely tell you more about the protocol between CMS' > concurrent threads and the mutators, but both collectors have > protocols to ensure that the memory contains valid information, either > retrying later (G1), or busy waiting (CMS, afaics from code around a > "bugfix for systems with weak memory model" comment) until this is the case. Yeah. This stuff doesn't make any sense: I need to see the code. I guess that what's going on is that a humongous object is allocated, the memory is zeroed, and the memory is then returned to the Java thread, which then initializes the object. So, the object is reachable from the GC thread even before it has been initialized. But instances of Class aren't humongous... or are they? Andrew. From martin.doerr at sap.com Tue Dec 20 14:27:39 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Dec 2016 14:27:39 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> Message-ID: I noticed that the tag field is read by ldarb, so forget my comment below. I can't see how the memory which is getting initialized can get accessed by another thread before the membar(Assembler::StoreStore) at the end was executed. Another thread would need the oop pointing to the memory. And TLAB scanning can only be done at a safepoint as far as I know. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Dienstag, 20. Dezember 2016 12:14 To: Andrew Haley ; Thomas Schatzl ; White, Derek ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR(s): 8171449" [aarch64] store_klass needs to use store release Hi, I think an acquire barrier is missing. See ppc implementation "isync(); // Order load of instance Klass wrt. tags." Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Dienstag, 20. Dezember 2016 11:28 To: Thomas Schatzl ; White, Derek ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(s): 8171449" [aarch64] store_klass needs to use store release On 20/12/16 10:21, Thomas Schatzl wrote: > Derek can very likely tell you more about the protocol between CMS' > concurrent threads and the mutators, but both collectors have > protocols to ensure that the memory contains valid information, either > retrying later (G1), or busy waiting (CMS, afaics from code around a > "bugfix for systems with weak memory model" comment) until this is the case. Yeah. This stuff doesn't make any sense: I need to see the code. I guess that what's going on is that a humongous object is allocated, the memory is zeroed, and the memory is then returned to the Java thread, which then initializes the object. So, the object is reachable from the GC thread even before it has been initialized. But instances of Class aren't humongous... or are they? Andrew. From Derek.White at cavium.com Tue Dec 20 14:40:56 2016 From: Derek.White at cavium.com (White, Derek) Date: Tue, 20 Dec 2016 14:40:56 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <1482232161.2831.76.camel@oracle.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> Message-ID: Hi Andrew, Some background. There are two synchronization issues around object initialization: 1) The allocating thread needs to ensure that the object is fully initialized (to default zeros or specified values) before another Java thread can see the object. This case is well handled with memory barriers etc. 2) A concurrent GC might find an object during heap scanning that has been allocated but not yet initialized. At the least it needs to know the size of the object if it's to reason about it. To enable this, the contract between the runtime and the concurrent collectors is that the length of an array (and 'forgotten case B'), is written before the klass word is installed in the header. If CMS finds an object with a null klass word, it either retries, terminates what it's doing, or uses a back-up method for finding the object size. So the history of this bug and it's relatives started with 'forgotten case B', which is that Class instances themselves are "pseudo" arrays, in that they contain zero or more locations of all of the static fields of a particular class. The size of this variable area is stored as a normal field in the same object, so to get the actual size of the a Class object you need to add the nominal size + the variable size. But the code that allocated the Class objects (which is the regular slow-path allocation code in runtime) wrote the header first (including the Class object's klass field), and then set the variable size field. I.e. the source code had the fields written out-of-order. This is bug JDK-8158946. This was fixed, but discussion led to the point that a compiler or weak memory-model CPU might also write the fields out-of-order, so a series of fixes changed the concurrent GC code to use load-acquires when necessary. This is JDK-8160369 and sub-tasks. See in particular oopDesc:: klass_or_null_acquire(). The C++ code, being static, uses store-releases no matter what GC is in use when allocating objects in the slow-path. The jitted code can chose to do normal stores or store-releases depending on the GC being used. As far as which GCs need to worry about this goes, CMS is clearly in danger with this issue on weak memory model systems. I don't have a definitive answer for G1. Thomas makes a good argument that in G1, concurrent GC would only scan a newly allocated object if it were humongous, and there are enough memory barriers around allocating a humungous region that we should be safe. But there were changes made to G1 to use oopDesc:: klass_or_null_acquire(). See http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1a33f585a889 . Perhaps these are overly conservative? - Derek -----Original Message----- From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] Sent: Tuesday, December 20, 2016 6:09 AM To: Andrew Haley ; White, Derek ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(s): 8171449" [aarch64] store_klass needs to use store release On Tue, 2016-12-20 at 10:27 +0000, Andrew Haley wrote: > On 20/12/16 10:21, Thomas Schatzl wrote: > > > > Derek can very likely tell you more about the protocol between CMS' > > concurrent threads and the mutators, but both collectors have > > protocols to ensure that the memory contains valid information, > > either retrying later (G1), or busy waiting (CMS, afaics from code > > around a "bugfix for systems with weak memory model" comment) until > > this is the case. > > Yeah.??This stuff doesn't make any sense: I need to see the code.??I > guess that what's going on is that a humongous object is allocated, > the memory is zeroed, and the memory is then returned to the Java > thread, which then initializes the object.??So, the object is > reachable from the GC thread even before it has been initialized. > But instances of Class aren't humongous... or are they? ? you can have instances of regular classes that are humongous. :) There is no limitation on object instance size in the language spec afaik, but at least it allows as large objects as to qualify as humongous. In any case, G1 only ever allocates humongous objects in old gen which makes things a lot easier because these regions can only ever contain that single humongous object and nothing else useful. And we only need to take care about appropriate memory barriers in the runtime because humongous objects are always allocated in the runtime. As for the patch, this changes the generated fast-path eden allocation code, so to be of any problem for the interaction with the concurrent gc threads, the runtime would first have needed to hand out "TLABs" from old gen. G1 never does that, so the patch does not seem to be applicable for it at all, but I think for CMS this seems different. The TLAB allocator for CMS can hand out old gen "TLABs" in some cases, e.g. when the GCLocker prevents an immediate GC when running out of space (I did not confirm this particular case yet). So Derek, can you elaborate a bit on what error case you have in mind? Thanks, ? Thomas From Derek.White at cavium.com Tue Dec 20 16:37:12 2016 From: Derek.White at cavium.com (White, Derek) Date: Tue, 20 Dec 2016 16:37:12 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> Message-ID: Hi Martin, That's a good point, and one that Thomas has been trying to make to me think about: Do all allocation paths need to worry about this? If the fast-path allocations done by the interpreter and jitted code only occur in young gen regions, and the concurrent collectors never look at the young gen concurrently, then CPU -specific code probably wouldn't have to worry about it. The fixed code in the runtime slow paths would handle all of the problem allocations. Note that we have a tower of undocumented and untested assumptions about some pretty subtle stuff, that exists in code only as the absence memory ordering instructions. :-) So it seems that CMS violates those constraints by sometimes doing TLAB-like allocations out of the old gen (when concurrent sweep in progress?). I think -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: Tuesday, December 20, 2016 9:28 AM To: Doerr, Martin ; Andrew Haley ; Thomas Schatzl ; White, Derek ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR(s): 8171449" [aarch64] store_klass needs to use store release I noticed that the tag field is read by ldarb, so forget my comment below. I can't see how the memory which is getting initialized can get accessed by another thread before the membar(Assembler::StoreStore) at the end was executed. Another thread would need the oop pointing to the memory. And TLAB scanning can only be done at a safepoint as far as I know. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Dienstag, 20. Dezember 2016 12:14 To: Andrew Haley ; Thomas Schatzl ; White, Derek ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR(s): 8171449" [aarch64] store_klass needs to use store release Hi, I think an acquire barrier is missing. See ppc implementation "isync(); // Order load of instance Klass wrt. tags." Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Dienstag, 20. Dezember 2016 11:28 To: Thomas Schatzl ; White, Derek ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(s): 8171449" [aarch64] store_klass needs to use store release On 20/12/16 10:21, Thomas Schatzl wrote: > Derek can very likely tell you more about the protocol between CMS' > concurrent threads and the mutators, but both collectors have > protocols to ensure that the memory contains valid information, either > retrying later (G1), or busy waiting (CMS, afaics from code around a > "bugfix for systems with weak memory model" comment) until this is the case. Yeah. This stuff doesn't make any sense: I need to see the code. I guess that what's going on is that a humongous object is allocated, the memory is zeroed, and the memory is then returned to the Java thread, which then initializes the object. So, the object is reachable from the GC thread even before it has been initialized. But instances of Class aren't humongous... or are they? Andrew. From aph at redhat.com Tue Dec 20 16:42:51 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Dec 2016 16:42:51 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> Message-ID: <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> Hi, On 20/12/16 14:40, White, Derek wrote: > Some background. There are two synchronization issues around object initialization: > 1) The allocating thread needs to ensure that the object is fully > initialized (to default zeros or specified values) before another > Java thread can see the object. This case is well handled with > memory barriers etc. > > 2) A concurrent GC might find an object during heap scanning that > has been allocated but not yet initialized. At the least it needs to > know the size of the object if it's to reason about it. To enable > this, the contract between the runtime and the concurrent collectors > is that the length of an array (and 'forgotten case B'), is written > before the klass word is installed in the header. If CMS finds an > object with a null klass word, it either retries, terminates what > it's doing, or uses a back-up method for finding the object size. I've had a look at what was confusing me so much, and I think I have found something. In G1CollectedHeap::humongous_obj_allocate_initialize_regions I see this: // First, we need to zero the header of the space that we will be // allocating. When we update top further down, some refinement // threads might try to scan the region. By zeroing the header we // ensure that any thread that will try to scan the region will // come across the zero klass word and bail out. // Copy::fill_to_words(new_obj, oopDesc::header_size(), 0); ... OrderAccess::storestore(); > This was fixed, but discussion led to the point that a compiler or > weak memory-model CPU might also write the fields out-of-order, so a > series of fixes changed the concurrent GC code to use load-acquires > when necessary. This is JDK-8160369 and sub-tasks. See in particular > oopDesc:: klass_or_null_acquire(). Sure. > As far as which GCs need to worry about this goes, CMS is clearly in > danger with this issue on weak memory model systems. I don't have a > definitive answer for G1. Thomas makes a good argument that in G1, > concurrent GC would only scan a newly allocated object if it were > humongous, and there are enough memory barriers around allocating a > humungous region that we should be safe. But there were changes made > to G1 to use oopDesc:: klass_or_null_acquire(). See > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1a33f585a889 > . Perhaps these are overly conservative? After an object is allocated and before it is zeroed, the object is garbage. This includes the klass field, which probably is non-null. There is a window in time between the memory being allocated and the klass field being written. So, I suppose until the klass field is written, some memory which is about to become an array must not be visible to CMS. It must not be visible because it must not be possible for CMS to see a garbage klass field. What is it that hides the array to make sure that it is not visible until we do the releasing store to the klass field? I've stepped through the code and I see nothing. Andrew. From edward.nevill at gmail.com Tue Dec 20 21:01:52 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 20 Dec 2016 21:01:52 +0000 Subject: [aarch64-port-dev ] RFR: 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 Message-ID: <1482267712.2307.11.camel@gmail.com> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8171537/webrev JIRA Issue:?https://bugs.openjdk.java.net/browse/JDK-8171537 This fixes an issue where the JTreg hotspot test compiler/c1/Test6849574.java fails with a guarantee failure when run with -XX:TieredStopAtLevel=1 to force use of C1. # A fatal error has been detected by the Java Runtime Environment:? #? # Internal Error (assembler_aarch64.hpp:232), pid=8576, tid=8601? # guarantee(val < (1U << nbits)) failed: Field too big for insn? The problem is the following call in?LIR_Assembler::atomic_op in?src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ? Address addr = as_Address(src->as_address_ptr(), noreg); (noreg has the value -1) as_Address looks like Address LIR_Assembler::as_Address(LIR_Address* addr, Register tmp) { .... ? ? intptr_t addr_offset = intptr_t(addr->disp()); ????if (Address::offset_ok_for_immed(addr_offset, addr->scale())) ??????return Address(base, addr_offset, Address::lsl(addr->scale())); ????else { ??????__ mov(tmp, addr_offset); ?<<<<< tmp is used here, but has value -1 ??????return Address(base, tmp, Address::lsl(addr->scale())); ????} } The proposed solution is to change the call to ? Address addr = as_Address(src->as_address_ptr()); which calls the two argument form with rscratch1 as the tmp register instead of -1. All the best, Ed. From aph at redhat.com Tue Dec 20 21:24:47 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Dec 2016 21:24:47 +0000 Subject: [aarch64-port-dev ] RFR: 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 In-Reply-To: <1482267712.2307.11.camel@gmail.com> References: <1482267712.2307.11.camel@gmail.com> Message-ID: <76c988e6-307e-5f7f-814a-7b6926ee3d53@redhat.com> On 20/12/16 21:01, Edward Nevill wrote: > http://cr.openjdk.java.net/~enevill/8171537/webrev > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8171537 This is great, thanks. It must go in by tomorrow to meet the freeze deadline. Andrew. From vladimir.kozlov at oracle.com Tue Dec 20 21:43:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 13:43:22 -0800 Subject: [aarch64-port-dev ] RFR: 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 In-Reply-To: <76c988e6-307e-5f7f-814a-7b6926ee3d53@redhat.com> References: <1482267712.2307.11.camel@gmail.com> <76c988e6-307e-5f7f-814a-7b6926ee3d53@redhat.com> Message-ID: <7e80851c-d996-1172-37e9-df4febbf5df0@oracle.com> Only P4 and P5 bugs are affected by "Rampdown Start" January 5. That is what we talking about now. As usual Hotspot should have these fixes 2 weeks before January 5 to have time for fixes propagation into master jdk9/jdk9. We can still push P1-P3 bugs fixes until ZBB, Feb 16 (or 2 weeks before for Hotspot): http://openjdk.java.net/projects/jdk9/ So make your bugs at least P3 if you need to push them into JDK 9. Regards, Vladimir On 12/20/16 1:24 PM, Andrew Haley wrote: > On 20/12/16 21:01, Edward Nevill wrote: >> http://cr.openjdk.java.net/~enevill/8171537/webrev >> >> JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8171537 > > This is great, thanks. It must go in by tomorrow to meet the > freeze deadline. > > Andrew. > From ci_notify at linaro.org Wed Dec 21 09:40:12 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 21 Dec 2016 09:40:12 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1991099618.1671.1482313213454.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/355/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/30 pass: 1,307; fail: 10; error: 49 Build 1: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 2: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 3: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 4: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 7: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 8: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 9: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 10: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 11: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 12: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 13: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 Build 14: aarch64/2016/dec/20 pass: 1,283; fail: 25; error: 67 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 8: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 9: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 10: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 11: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 12: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 Build 13: aarch64/2016/dec/20 pass: 7,215; fail: 638; error: 51 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/30 pass: 3,757; fail: 1; error: 23 Build 1: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 2: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 3: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 4: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 5: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 6: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 7: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 8: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 9: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 10: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 11: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 12: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 13: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 Build 14: aarch64/2016/dec/20 pass: 3,784; fail: 2; error: 20 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/30 pass: 1,309; fail: 12; error: 48 Build 1: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 2: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 3: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 4: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 5: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 6: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 7: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 8: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 9: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 10: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 11: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 12: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 13: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 Build 14: aarch64/2016/dec/20 pass: 1,285; fail: 27; error: 66 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/28 pass: 7,208; fail: 639; error: 39 Build 1: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 2: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 3: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 4: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 5: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 6: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 7: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 8: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 9: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 10: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 11: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 12: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 13: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 Build 14: aarch64/2016/dec/20 pass: 7,231; fail: 629; error: 44 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/30 pass: 3,754; fail: 1; error: 26 Build 1: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 2: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 3: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 4: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 5: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 6: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 7: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 8: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 9: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 10: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 11: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 12: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 13: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Build 14: aarch64/2016/dec/20 pass: 3,775; fail: 1; error: 30 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.02x Relative performance: Server critical-jOPS (nc): 0.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 60.84, Server: 109.42 Client 60.84 / Client 2014-04-01 (43.00): 1.41x Server 109.42 / Server 2014-04-01 (71.00): 1.54x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-26 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/331/results/ 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ 2016-12-21 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/355/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From edward.nevill at gmail.com Wed Dec 21 10:16:53 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 21 Dec 2016 10:16:53 +0000 Subject: [aarch64-port-dev ] RFR: 8171410: aarch64: long multiplyExact shifts by 31 instead of 63 In-Reply-To: References: <1482142162.2883.4.camel@gmail.com> Message-ID: <1482315413.2303.4.camel@gmail.com> On Mon, 2016-12-19 at 11:33 +0000, Andrew Dinn wrote: > Hi Ed, > > On 19/12/16 10:09, Edward Nevill wrote: > > > > Please review the following webrev ... > The change looks good to me. > > Andrew Dinn Thanks Andrew, could I have an official Reviewer please. All the best, Ed. From aph at redhat.com Wed Dec 21 10:29:31 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Dec 2016 10:29:31 +0000 Subject: [aarch64-port-dev ] RFR: 8171410: aarch64: long multiplyExact shifts by 31 instead of 63 In-Reply-To: <1482315413.2303.4.camel@gmail.com> References: <1482142162.2883.4.camel@gmail.com> <1482315413.2303.4.camel@gmail.com> Message-ID: <54cbf252-9996-1066-22a2-be43d955bd2d@redhat.com> On 21/12/16 10:16, Edward Nevill wrote: > Thanks Andrew, could I have an official Reviewer please. OK. Andrew. From thomas.schatzl at oracle.com Wed Dec 21 12:22:11 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 21 Dec 2016 13:22:11 +0100 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> Message-ID: <1482322931.2730.28.camel@oracle.com> Hi Andrew, On Tue, 2016-12-20 at 16:42 +0000, Andrew Haley wrote: > Hi, > > On 20/12/16 14:40, White, Derek wrote: > > > > > Some background. There are two synchronization issues around object > > initialization: > > 1) The allocating thread needs to ensure that the object is fully > > initialized (to default zeros or specified values) before another > > Java thread can see the object. This case is well handled with > > memory barriers etc. > > > > 2) A concurrent GC might find an object during heap scanning that > > has been allocated but not yet initialized. At the least it needs > > to know the size of the object if it's to reason about it. To > > enable this, the contract between the runtime and the concurrent > > collectors is that the length of an array (and 'forgotten case B'), > > is written before the klass word is installed in the header. If CMS > > finds an object with a null klass word, it either retries, > > terminates what it's doing, or uses a back-up method for finding > > the object size. > > I've had a look at what was confusing me so much, and I think I have > found something.??In > G1CollectedHeap::humongous_obj_allocate_initialize_regions I see > this: > > ? // First, we need to zero the header of the space that we will be > ? // allocating. When we update top further down, some refinement > ? // threads might try to scan the region. By zeroing the header we > ? // ensure that any thread that will try to scan the region will > ? // come across the zero klass word and bail out. > ? // > ? Copy::fill_to_words(new_obj, oopDesc::header_size(), 0); > > ... > > ? OrderAccess::storestore(); > > > > > This was fixed, but discussion led to the point that a compiler or > > weak memory-model CPU might also write the fields out-of-order, so > > a series of fixes changed the concurrent GC code to use load- > > acquires when necessary. This is JDK-8160369 and sub-tasks. See in > > particular oopDesc:: klass_or_null_acquire(). > Sure. > > > > > As far as which GCs need to worry about this goes, CMS is clearly > > in > > danger with this issue on weak memory model systems. I don't have a > > definitive answer for G1. Thomas makes a good argument that in G1, > > concurrent GC would only scan a newly allocated object if it were > > humongous, and there are enough memory barriers around allocating a > > humungous region that we should be safe. But there were changes > > made > > to G1 to use oopDesc:: klass_or_null_acquire(). See > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1a33f585a889 > > . Perhaps these are overly conservative? > After an object is allocated and before it is zeroed, the object is > garbage.??This includes the klass field, which probably is non-null. > There is a window in time between the memory being allocated and the > klass field being written.??So, I suppose until the klass field is > written, some memory which is about to become an array must not be > visible to CMS.??It must not be visible because it must not be > possible for CMS to see a garbage klass field. s/CMS/G1? At that point "top" of the region must be the same as "bottom" in this case. To be allocated, a region must have been "Free" before that; we set to "Free" and reset a regions' "top" to "bottom" only during STW pause, so this must be visible. So this card will be filtered out by the gc thread and that area not scanned, the check is at g1RemSet.cpp:668. Also see the comment at line 659. I hope this is the answer to your question. Hth, ? Thomas From thomas.schatzl at oracle.com Wed Dec 21 12:34:51 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 21 Dec 2016 13:34:51 +0100 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> Message-ID: <1482323691.2730.37.camel@oracle.com> Hi all, On Tue, 2016-12-20 at 16:37 +0000, White, Derek wrote: > Hi Martin, > > That's a good point, and one that Thomas has been trying to make to > me think about: Do all allocation paths need to worry about this? > > If the fast-path allocations done by the interpreter and jitted code > only occur in young gen regions, and the concurrent collectors never > look at the young gen concurrently, then CPU -specific code probably > wouldn't have to worry about it. The fixed code in the runtime slow > paths would handle all of the problem allocations. > > Note that we have a tower of undocumented and untested assumptions > about some pretty subtle stuff, that exists in code only as the > absence memory ordering instructions. :-) > > So it seems that CMS violates those constraints by sometimes doing > TLAB-like allocations out of the old gen (when concurrent sweep in > progress?). > > I think? ? I tend to disagree after studying the CMS allocation code. Allocations in the old gen should always end up in the slow- path/runtime. Feel free to verify - maybe I overlooked something. In GenCollectorPolicy::mem_allocate_work, the first part is about allocation in young gen only (line 600, collectorPolicy.cpp). In the retry under the Heap_lock the first_only flag may be set to false under some conditions. However, the called GenCollectedHeap::attempt_allocation() then actually checks (after failing to allocate in young) whether it should allocate in old (Generation::should_allocate()). Which ultimately returns false, because Generation::supports_tlab_allocation() will return false for the old gen. Then in genCollectorPolicy.cpp:622, we end up return NULL (allocation failure) for TLABs to let the caller retry with allocation of an individual object. Thanks, ? Thomas From aph at redhat.com Wed Dec 21 15:46:18 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Dec 2016 15:46:18 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <1482322931.2730.28.camel@oracle.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> Message-ID: On 21/12/16 12:22, Thomas Schatzl wrote: > Hi Andrew, > > On Tue, 2016-12-20 at 16:42 +0000, Andrew Haley wrote: >> >> On 20/12/16 14:40, White, Derek wrote: >> >>> As far as which GCs need to worry about this goes, CMS is clearly >>> in >>> danger with this issue on weak memory model systems. I don't have a >>> definitive answer for G1. Thomas makes a good argument that in G1, >>> concurrent GC would only scan a newly allocated object if it were >>> humongous, and there are enough memory barriers around allocating a >>> humungous region that we should be safe. But there were changes >>> made >>> to G1 to use oopDesc:: klass_or_null_acquire(). See >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1a33f585a889 >>> . Perhaps these are overly conservative? >> >> After an object is allocated and before it is zeroed, the object is >> garbage. This includes the klass field, which probably is non-null. >> There is a window in time between the memory being allocated and the >> klass field being written. So, I suppose until the klass field is >> written, some memory which is about to become an array must not be >> visible to CMS. It must not be visible because it must not be >> possible for CMS to see a garbage klass field. > > s/CMS/G1? No. I traced through CMS allocation. At least, I traced through allocating a large array with CMS enabled. > At that point "top" of the region must be the same as "bottom" in this > case. To be allocated, a region must have been "Free" before that; we > set to "Free" and reset a regions' "top" to "bottom" only during STW > pause, so this must be visible. This is what I don't understand. When memory is allocated for an object, it immediately becomes visible to a concurrent collector. Is this so? If it is not so, then there is no problem which needs a fence between setting the size field and the klass field, because the object is garbage anyway. If it is so, then there is a real problem because the collector will see garbage before the size field and the klass field are written. Surely it must be one or the other. Or maybe I've found an actual bug. All I'm asking is this question which I think is very simple: when does allocated memory become visible to a concurrent collector? Is it when the memory is allocated, or is it later? If is is later, what makes it visible? > So this card will be filtered out by the gc thread and that area not > scanned, the check is at g1RemSet.cpp:668. Also see the comment at line > 659. That's G1, I think. Andrew. From thomas.schatzl at oracle.com Wed Dec 21 16:00:47 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 21 Dec 2016 17:00:47 +0100 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> Message-ID: <1482336047.2730.53.camel@oracle.com> Hi, On Wed, 2016-12-21 at 15:46 +0000, Andrew Haley wrote: > On 21/12/16 12:22, Thomas Schatzl wrote: > > > > Hi Andrew, > > > > On Tue, 2016-12-20 at 16:42 +0000, Andrew Haley wrote: > > > > > > > > > On 20/12/16 14:40, White, Derek wrote: > > > > > > > > > > > As far as which GCs need to worry about this goes, CMS is > > > > clearly in danger with this issue on weak memory model systems. > > > > I don't have a definitive answer for G1. Thomas makes a good > > > > argument that in G1, concurrent GC would only scan a newly > > > > allocated object if it were humongous, and there are enough > > > > memory barriers around allocating a humungous region that we > > > > should be safe. But there were changes made to G1 to use > > > > oopDesc:: klass_or_null_acquire(). See > > > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1a33f585a889 > > > > . Perhaps these are overly conservative? > > > After an object is allocated and before it is zeroed, the object > > > is garbage.??This includes the klass field, which probably is > > > non-null. > > > There is a window in time between the memory being allocated and > > > the klass field being written.??So, I suppose until the klass > > > field is written, some memory which is about to become an array > > > must not be visible to CMS.??It must not be visible because it > > > must not be possible for CMS to see a garbage klass field. > > s/CMS/G1? > No.??I traced through CMS allocation.??At least, I traced through > allocating a large array with CMS enabled. > That is what confused me, because the original context to me seemed to talk about G1. So my answer is applicable to G1 only, sorry. I will see if I can find out how CMS works (or is supposed to) in that regard. Thanks, ? Thomas From aph at redhat.com Wed Dec 21 16:02:18 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Dec 2016 16:02:18 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <1482336047.2730.53.camel@oracle.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> Message-ID: <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> On 21/12/16 16:00, Thomas Schatzl wrote: > That is what confused me, because the original context to me seemed to > talk about G1. So my answer is applicable to G1 only, sorry. > > I will see if I can find out how CMS works (or is supposed to) in that > regard. Thanks. This is giving me a headache. :-) Andrew. From bob.vandette at oracle.com Wed Dec 21 17:04:27 2016 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 21 Dec 2016 12:04:27 -0500 Subject: [aarch64-port-dev ] JEP 297: Unified arm32/arm64 Port Integrated into JDK9 Master Message-ID: <7BAC8A28-507C-4F09-B450-75E60864F62E@oracle.com> I am please to announce that the source changes for JEP 297: Unified arm32/arm64 Port have now been integrated into the JDK 9 Master forest (http://hg.openjdk.java.net/jdk9/jdk9). JEP URL: http://openjdk.java.net/jeps/297 This means that we made feature complete cutoff and JDK 9 will now include an open sourced hybrid 32 and 64-bit ARM port. Thanks to everyone on the aarch32, aarch64, hotspot and build teams that helped with the JEP process, reviews and testing. Bob. From edward.nevill at gmail.com Wed Dec 21 17:15:54 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 21 Dec 2016 17:15:54 +0000 Subject: [aarch64-port-dev ] JEP 297: Unified arm32/arm64 Port Integrated into JDK9 Master In-Reply-To: <7BAC8A28-507C-4F09-B450-75E60864F62E@oracle.com> References: <7BAC8A28-507C-4F09-B450-75E60864F62E@oracle.com> Message-ID: <1482340554.2303.8.camel@gmail.com> On Wed, 2016-12-21 at 12:04 -0500, Bob Vandette wrote: >? > JEP URL:????http://openjdk.java.net/jeps/297 > > This means that we made feature complete cutoff and JDK 9 will now > include an open sourced hybrid? > 32 and 64-bit ARM port. This is excellent news Bob. Thank you for all your hard work integrating this. Also, thanks to Oracle for agreeing to open source the unified arm32/arm64 port. This is a major milestone for ARM. All the best, Ed. From ci_notify at linaro.org Thu Dec 22 00:40:19 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 22 Dec 2016 00:40:19 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <879963150.1809.1482367220448.JavaMail.jenkins@ci.linaro.org> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2016/356/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/01 pass: 668; fail: 44; error: 6 Build 1: aarch64/2016/dec/21 pass: 668; fail: 44; error: 6 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/21 pass: 5,621; fail: 219; error: 45 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/01 pass: 3,091; error: 16 Build 1: aarch64/2016/dec/21 pass: 3,096; error: 11 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/03 pass: 664; fail: 44; error: 6 Build 1: aarch64/2016/nov/08 pass: 664; fail: 44; error: 6 Build 2: aarch64/2016/nov/09 pass: 664; fail: 44; error: 6 Build 3: aarch64/2016/nov/21 pass: 668; fail: 44; error: 6 Build 4: aarch64/2016/dec/01 pass: 669; fail: 43; error: 6 Build 5: aarch64/2016/dec/21 pass: 668; fail: 44; error: 6 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/21 pass: 5,618; fail: 226; error: 41 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/03 pass: 3,092; error: 15 Build 1: aarch64/2016/nov/08 pass: 3,092; error: 15 Build 2: aarch64/2016/nov/09 pass: 3,091; error: 16 Build 3: aarch64/2016/nov/21 pass: 3,095; error: 12 Build 4: aarch64/2016/dec/01 pass: 3,095; error: 12 Build 5: aarch64/2016/dec/21 pass: 3,092; error: 15 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.97x Relative performance: Server critical-jOPS (nc): 1.09x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 56.92, Server: 110.27 Client 56.92 / Client 2014-04-01 (43.00): 1.32x Server 110.27 / Server 2014-04-01 (71.00): 1.55x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-11-03 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2016/308/results/ 2016-11-21 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2016/326/results/ 2016-12-01 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2016/336/results/ 2016-12-22 pass rate: 5140/5140, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2016/356/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From ci_notify at linaro.org Fri Dec 23 10:01:57 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 23 Dec 2016 10:01:57 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <127446421.1915.1482487317581.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/357/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/06 pass: 1,309; fail: 6; error: 52 Build 1: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 2: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 3: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 4: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 6: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 7: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 8: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 9: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 10: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 11: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 12: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 Build 13: aarch64/2016/dec/20 pass: 1,283; fail: 25; error: 67 Build 14: aarch64/2016/dec/22 pass: 1,275; fail: 25; error: 75 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,189; fail: 657; error: 42 Build 1: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 2: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 3: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 4: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 5: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 6: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 7: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 8: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 9: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 10: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 11: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 12: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 Build 13: aarch64/2016/dec/20 pass: 7,215; fail: 638; error: 51 Build 14: aarch64/2016/dec/22 pass: 7,229; fail: 624; error: 55 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/06 pass: 3,769; fail: 2; error: 17 Build 1: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 2: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 3: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 4: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 5: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 6: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 7: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 8: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 9: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 10: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 11: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 12: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 Build 13: aarch64/2016/dec/20 pass: 3,784; fail: 2; error: 20 Build 14: aarch64/2016/dec/22 pass: 3,792; fail: 1; error: 20 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/06 pass: 1,310; fail: 8; error: 52 Build 1: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 2: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 3: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 4: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 5: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 6: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 7: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 8: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 9: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 10: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 11: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 12: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 Build 13: aarch64/2016/dec/20 pass: 1,285; fail: 27; error: 66 Build 14: aarch64/2016/dec/22 pass: 1,276; fail: 27; error: 75 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/29 pass: 7,218; fail: 640; error: 30 Build 1: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 2: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 3: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 4: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 5: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 6: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 7: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 8: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 9: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 10: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 11: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 12: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 Build 13: aarch64/2016/dec/20 pass: 7,231; fail: 629; error: 44 Build 14: aarch64/2016/dec/22 pass: 7,246; fail: 617; error: 45 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/06 pass: 3,764; fail: 1; error: 23 Build 1: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 2: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 3: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 4: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 5: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 6: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 7: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 8: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 9: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 10: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 11: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 12: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Build 13: aarch64/2016/dec/20 pass: 3,775; fail: 1; error: 30 Build 14: aarch64/2016/dec/22 pass: 3,785; fail: 1; error: 27 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.92x Relative performance: Server critical-jOPS (nc): 0.75x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.58, Server: 106.13 Client 70.58 / Client 2014-04-01 (43.00): 1.64x Server 106.13 / Server 2014-04-01 (71.00): 1.49x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-12-07 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/341/results/ 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ 2016-12-21 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/355/results/ 2016-12-23 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/357/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From thomas.schatzl at oracle.com Fri Dec 23 12:31:54 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 23 Dec 2016 13:31:54 +0100 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> Message-ID: <1482496314.2973.40.camel@oracle.com> Hi Andrew, On Wed, 2016-12-21 at 16:02 +0000, Andrew Haley wrote: > On 21/12/16 16:00, Thomas Schatzl wrote: > > > > That is what confused me, because the original context to me seemed > > to talk about G1. So my answer is applicable to G1 only, sorry. > > > > I will see if I can find out how CMS works (or is supposed to) in > > that regard. > Thanks.??This is giving me a headache.??:-) After some digging, I think CMS is good. Here is an attempt to explain what happens: First, the allocation and the CMS concurrent threads always synchronize using a global lock (_markBitMap.lock()). The concurrent threads (marking, precleaning, sweeping) skip over yet completely uninitialized blocks (that may have garbage in the _klass) using marks in the bitmap: if an object has been allocated during concurrent phases, the object is marked gray using three marks: one at the start, one at the end, and one at the second word. Using that bit in the second word it knows that the object inside the start and end bits may not have been initialized yet (but its klass is either NULL or valid due to locking, see below). CMS then uses these start/end bits to know the length of that block, or if that second bit does not exist, knows that the next bit on the mark bitmap must be a valid start of an object. Pointer writes to an object after allocation (when the klass must have been valid) will dirty the corresponding card and the concurrent gc threads will visit the object (then fully initialized) again. In detail, an allocating thread does something like: set klass to NULL ? [ConcurrentMarkSweepGeneration::have_lock_and_allocate() calls CompactibleFreeListSpace::allocate() which sets the klass to NULL without any synchronization yet; the klass pointer is overlaid over FreeChunk::_prev which is set to NULL; the concurrent threads will just skip that block using the mark bitmap.] lock _markBitMap.lock() set first, second and last bits of that range in the bitmap unlock _markBitmap.lock() [makes sure that Printezis bits and klass field are visible to concurrent threads; before that concurrent threads do not touch this area. JDK-8160369 fixed some issues with reading the klass field if/when CMS reads from that area] The concurrent readers always do something like: lock _markBitmap.lock(); while (more work) { ? do some work; ? yield [unlock _markBitMap.lock(), sleep, _markBitMap.lock()] } unlock _markBitmap.lock(); ?? I.e. the shared mark bitmap information seems to be properly synchronized and always usable to avoid reading junk data. There is some documentation about the use of mark bits in CMSCollector::direct_allocated(). Also, there is some more documentation on how the synchronization works above SweepClosure::do_blk_careful for the sweeper. The others are similar from what I saw. Check the uses of _markBitMap.lock() to find the respective yield methods for the various kinds of concurrent mark threads. Overall, given that TLABs are only allocated in young, so the old gen allocation always uses the runtime, which I briefly rechecked to use the proper synchronization to read the klass values, I think there is no issue. I hope this answers your question. Given this I tend to think that there is no issue here after all, but please by all means, verify this. Thanks, ? Thomas Merry Christmas and a Happy New Year! From aph at redhat.com Fri Dec 23 13:35:21 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 23 Dec 2016 13:35:21 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <1482496314.2973.40.camel@oracle.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> Message-ID: <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> On 23/12/16 12:31, Thomas Schatzl wrote: > I hope this answers your question. > > Given this I tend to think that there is no issue here after all, but > please by all means, verify this. OK. I'm going to step through to see if that is what really happens. I'm pretty sure that when I did step through I didn't see any NULLing of the klass field, but I take it from your answer that the only time this actually needs to happen is when an object is allocated by the C++ runtime code, not by the JIT-generated code or the JIT's runtime libraries, which only ever allocated in the young gen. Thanks, Andrew. From thomas.schatzl at oracle.com Fri Dec 23 13:44:07 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 23 Dec 2016 14:44:07 +0100 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> Message-ID: <1482500647.2973.63.camel@oracle.com> Hi, On Fri, 2016-12-23 at 13:35 +0000, Andrew Haley wrote: > On 23/12/16 12:31, Thomas Schatzl wrote: > > > > I hope this answers your question. > > > > Given this I tend to think that there is no issue here after all, > > but > > please by all means, verify this. > OK.??I'm going to step through to see if that is what really happens. > I'm pretty sure that when I did step through I didn't see any NULLing > of the klass field, but I take it from your answer that the only time > this actually needs to happen is when an object is allocated by the > C++ runtime code, not by the JIT-generated code or the JIT's runtime > libraries, which only ever allocated in the young gen. The important thing to consider here is that the FreeChunk data structure is overlaid over the future object. I.e. when FreeChunk::mark_not_free() is called, by nulling out _prev, it actually also nulls out the klass field of the future?object. There is actually a comment indicating exactly that in that method. Thanks, ? Thomas From ci_notify at linaro.org Sat Dec 24 10:58:07 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 24 Dec 2016 10:58:07 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <456575934.1998.1482577088374.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/358/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/07 pass: 1,309; fail: 6; error: 52 Build 1: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 2: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 3: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 4: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 5: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 6: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 7: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 8: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 9: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 10: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 11: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 Build 12: aarch64/2016/dec/20 pass: 1,283; fail: 25; error: 67 Build 13: aarch64/2016/dec/22 pass: 1,275; fail: 25; error: 75 Build 14: aarch64/2016/dec/23 pass: 1,274; fail: 25; error: 76 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/30 pass: 7,187; fail: 650; error: 51 Build 1: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 2: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 3: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 4: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 5: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 6: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 7: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 8: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 9: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 10: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 11: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 Build 12: aarch64/2016/dec/20 pass: 7,215; fail: 638; error: 51 Build 13: aarch64/2016/dec/22 pass: 7,229; fail: 624; error: 55 Build 14: aarch64/2016/dec/23 pass: 7,203; fail: 640; error: 66 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/07 pass: 3,771; fail: 1; error: 16 Build 1: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 2: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 3: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 4: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 5: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 6: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 7: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 8: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 9: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 10: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 11: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 Build 12: aarch64/2016/dec/20 pass: 3,784; fail: 2; error: 20 Build 13: aarch64/2016/dec/22 pass: 3,792; fail: 1; error: 20 Build 14: aarch64/2016/dec/23 pass: 3,781; fail: 1; error: 31 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/07 pass: 1,309; fail: 9; error: 52 Build 1: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 2: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 3: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 4: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 5: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 6: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 7: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 8: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 9: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 10: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 11: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 Build 12: aarch64/2016/dec/20 pass: 1,285; fail: 27; error: 66 Build 13: aarch64/2016/dec/22 pass: 1,276; fail: 27; error: 75 Build 14: aarch64/2016/dec/23 pass: 1,277; fail: 27; error: 74 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/nov/30 pass: 7,206; fail: 643; error: 39 Build 1: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 2: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 3: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 4: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 5: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 6: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 7: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 8: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 9: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 10: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 11: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 Build 12: aarch64/2016/dec/20 pass: 7,231; fail: 629; error: 44 Build 13: aarch64/2016/dec/22 pass: 7,246; fail: 617; error: 45 Build 14: aarch64/2016/dec/23 pass: 7,223; fail: 638; error: 48 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/07 pass: 3,764; fail: 1; error: 23 Build 1: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 2: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 3: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 4: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 5: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 6: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 7: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 8: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 9: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 10: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 11: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Build 12: aarch64/2016/dec/20 pass: 3,775; fail: 1; error: 30 Build 13: aarch64/2016/dec/22 pass: 3,785; fail: 1; error: 27 Build 14: aarch64/2016/dec/23 pass: 3,780; fail: 1; error: 32 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.92x Relative performance: Server critical-jOPS (nc): 0.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.93, Server: 105.34 Client 70.93 / Client 2014-04-01 (43.00): 1.65x Server 105.34 / Server 2014-04-01 (71.00): 1.48x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-12-08 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/342/results/ 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ 2016-12-21 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/355/results/ 2016-12-23 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/357/results/ 2016-12-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/358/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From simon at cjnash.com Wed Dec 21 07:43:18 2016 From: simon at cjnash.com (Simon Nash) Date: Wed, 21 Dec 2016 07:43:18 +0000 Subject: [aarch64-port-dev ] JEP 297: Unified arm32/arm64 Port latest Merge In-Reply-To: <1481797424.2342.8.camel@gmail.com> References: <351F8849-44F2-48D3-A6A1-D229D79AABE4@oracle.com> <1481797424.2342.8.camel@gmail.com> Message-ID: <585A3296.6000008@cjnash.com> On 15/12/2016 10:23, Edward Nevill wrote: > On Tue, 2016-12-13 at 13:16 -0500, Bob Vandette wrote: >> Here?s the latest patches for adding the Unified arm32/64 sources to the JDK 9 hotspot forest. >> >> I?ve merged up with the latest AOT and Jigsaw changes in http://hg.openjdk.java.net/jdk9/hs as of yesterday. >> >> http://cr.openjdk.java.net/~bobv/8168503-01/hotspot/webrev/ >> http://cr.openjdk.java.net/~bobv/8168503-01/jdk/webrev/ >> http://cr.openjdk.java.net/~bobv/8168503-01/top/webrev/ >> > > Looks good. I have built the hs repo with these patches and run jtreg on x86, arm64 and arm32. Here is a summary of the results. > > x86: > > hotspot: passed: 1,372; failed: 30; error: 55 > langtools: 3,773; failed: 12; error: 9 > jdk: passed: 6,378; failed: 202; error: 10 > > arm64: > > hotspot: passed: 1,315; failed: 31; error: 49 > langtools: 3,772; failed: 10; error: 10 > jdk: passed: 6,433; failed: 148; error: 8 > > arm32: > > hotspot: 1,212; failed: 50; error: 48 > langtools: passed: 3,771; failed: 14; error: 9 > jdk: passed: 6,043; failed: 442; error: 18 > > There were no failures due to fatal errors (ie, SEGV, ABORT, assert/guarantee failure etc). > > Currently running jcstress, results in approx 10 hours. > > All the best, > Ed. > > What is the current status of this? Have the necessary approvals been given for this merge to happen? Simon From simon at cjnash.com Wed Dec 21 17:56:32 2016 From: simon at cjnash.com (Simon Nash) Date: Wed, 21 Dec 2016 17:56:32 +0000 Subject: [aarch64-port-dev ] JEP 297: Unified arm32/arm64 Port Integrated into JDK9 Master In-Reply-To: <1482340554.2303.8.camel@gmail.com> References: <7BAC8A28-507C-4F09-B450-75E60864F62E@oracle.com> <1482340554.2303.8.camel@gmail.com> Message-ID: <585AC250.6090805@cjnash.com> On 21/12/2016 17:15, Edward Nevill wrote: > On Wed, 2016-12-21 at 12:04 -0500, Bob Vandette wrote: >> >> JEP URL: http://openjdk.java.net/jeps/297 >> >> This means that we made feature complete cutoff and JDK 9 will now >> include an open sourced hybrid >> 32 and 64-bit ARM port. > > This is excellent news Bob. Thank you for all your hard work > integrating this. > > Also, thanks to Oracle for agreeing to open source the unified > arm32/arm64 port. This is a major milestone for ARM. > > All the best, > Ed. > > I would also like to add my thanks to all concerned. This is a major step towards establishing Java as a fully competitive industry platform for ARM applications. Best regards, Simon From kim.barrett at oracle.com Wed Dec 21 22:39:05 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 21 Dec 2016 17:39:05 -0500 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <80b0494d-3e4c-6004-8b94-10dd7d40519c@redhat.com> References: <80b0494d-3e4c-6004-8b94-10dd7d40519c@redhat.com> Message-ID: <26F3FF78-8912-4F6B-A7E9-ECB3E5E2AAC4@oracle.com> > On Dec 20, 2016, at 5:01 AM, Andrew Dinn wrote: > > > > On 19/12/16 21:22, White, Derek wrote: >> As the "FIXME" noted, aarch64 really does need to use a store release >> in the "store_klass" macro, at least when a concurrent GC is in >> effect. >> >> BUG: https://bugs.openjdk.java.net/browse/JDK-8171449 >> >> Webrev: >> http://cr.openjdk.java.net/~drwhite/8171449/webrev.01/index.html >> >> BTW, PPC is likely to need a similar fix... > > This looks like only half the story. The stlrw is only going to be of > any relevance if code which reads the klass and klass length does so > using a ldarw (n.b. these synchronizing instructions will only be needed > if there is no other guarantee of memory synchronization between any > store and its corresponding load). > > Can you point to where in the GC code the corresponding loads occur? All of the relevant GC reads of klass and associated size should involve oopDesc::klass_or_null_acquire(). From alexander.harlap at oracle.com Sat Dec 24 15:04:37 2016 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Sat, 24 Dec 2016 10:04:37 -0500 Subject: [aarch64-port-dev ] Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated Message-ID: Please review change forJDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated Change is located at http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ It implements Per Liden fix for rechecking value of marking in progress value inside C1 g1_pre_barrier code. Also here is optimization described by Thomas Schatzl - do recheck only if patching involved. Alex From ci_notify at linaro.org Sun Dec 25 10:55:35 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 25 Dec 2016 10:55:35 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <237297632.2228.1482663336150.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/359/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/08 pass: 1,307; fail: 6; error: 54 Build 1: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 2: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 3: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 4: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 5: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 6: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 7: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 8: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 9: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 10: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 Build 11: aarch64/2016/dec/20 pass: 1,283; fail: 25; error: 67 Build 12: aarch64/2016/dec/22 pass: 1,275; fail: 25; error: 75 Build 13: aarch64/2016/dec/23 pass: 1,274; fail: 25; error: 76 Build 14: aarch64/2016/dec/24 pass: 1,273; fail: 25; error: 77 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/08 pass: 7,201; fail: 650; error: 51 Build 1: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 2: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 3: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 4: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 5: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 6: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 7: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 8: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 9: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 10: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 Build 11: aarch64/2016/dec/20 pass: 7,215; fail: 638; error: 51 Build 12: aarch64/2016/dec/22 pass: 7,229; fail: 624; error: 55 Build 13: aarch64/2016/dec/23 pass: 7,203; fail: 640; error: 66 Build 14: aarch64/2016/dec/24 pass: 7,213; fail: 635; error: 62 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/08 pass: 3,766; fail: 1; error: 21 Build 1: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 2: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 3: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 4: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 5: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 6: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 7: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 8: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 9: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 10: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 Build 11: aarch64/2016/dec/20 pass: 3,784; fail: 2; error: 20 Build 12: aarch64/2016/dec/22 pass: 3,792; fail: 1; error: 20 Build 13: aarch64/2016/dec/23 pass: 3,781; fail: 1; error: 31 Build 14: aarch64/2016/dec/24 pass: 3,786; fail: 3; error: 24 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/08 pass: 1,309; fail: 8; error: 53 Build 1: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 2: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 3: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 4: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 5: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 6: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 7: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 8: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 9: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 10: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 Build 11: aarch64/2016/dec/20 pass: 1,285; fail: 27; error: 66 Build 12: aarch64/2016/dec/22 pass: 1,276; fail: 27; error: 75 Build 13: aarch64/2016/dec/23 pass: 1,277; fail: 27; error: 74 Build 14: aarch64/2016/dec/24 pass: 1,276; fail: 27; error: 75 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/08 pass: 7,215; fail: 644; error: 43 Build 1: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 2: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 3: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 4: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 5: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 6: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 7: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 8: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 9: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 10: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 Build 11: aarch64/2016/dec/20 pass: 7,231; fail: 629; error: 44 Build 12: aarch64/2016/dec/22 pass: 7,246; fail: 617; error: 45 Build 13: aarch64/2016/dec/23 pass: 7,223; fail: 638; error: 48 Build 14: aarch64/2016/dec/24 pass: 7,215; fail: 632; error: 63 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/08 pass: 3,763; fail: 1; error: 24 Build 1: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 2: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 3: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 4: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 5: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 6: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 7: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 8: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 9: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 10: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Build 11: aarch64/2016/dec/20 pass: 3,775; fail: 1; error: 30 Build 12: aarch64/2016/dec/22 pass: 3,785; fail: 1; error: 27 Build 13: aarch64/2016/dec/23 pass: 3,780; fail: 1; error: 32 Build 14: aarch64/2016/dec/24 pass: 3,783; fail: 1; error: 29 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.92x Relative performance: Server critical-jOPS (nc): 0.80x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 68.19, Server: 102.28 Client 68.19 / Client 2014-04-01 (43.00): 1.59x Server 102.28 / Server 2014-04-01 (71.00): 1.44x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-12-09 pass rate: 6003/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/343/results/ 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ 2016-12-21 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/355/results/ 2016-12-23 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/357/results/ 2016-12-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/358/results/ 2016-12-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/359/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From aph at redhat.com Tue Dec 27 10:40:13 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 27 Dec 2016 10:40:13 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <1482500647.2973.63.camel@oracle.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> Message-ID: <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> Hi, On 23/12/16 13:44, Thomas Schatzl wrote: > On Fri, 2016-12-23 at 13:35 +0000, Andrew Haley wrote: >> On 23/12/16 12:31, Thomas Schatzl wrote: >>> >>> I hope this answers your question. >>> >>> Given this I tend to think that there is no issue here after all, >>> but >>> please by all means, verify this. >> OK. I'm going to step through to see if that is what really happens. >> I'm pretty sure that when I did step through I didn't see any NULLing >> of the klass field, but I take it from your answer that the only time >> this actually needs to happen is when an object is allocated by the >> C++ runtime code, not by the JIT-generated code or the JIT's runtime >> libraries, which only ever allocated in the young gen. > > The important thing to consider here is that the FreeChunk data > structure is overlaid over the future object. I.e. when > FreeChunk::mark_not_free() is called, by nulling out _prev, it actually > also nulls out the klass field of the future object. > > There is actually a comment indicating exactly that in that method. Yes, I see that code. I think Derek is right, and there is no bug here. Compiled code and the template interpreter allocate in the young generation, and this isn't visible to the collectors. Whenever compiled code initializes an object, the memory it overwrites is garbage. When memory is allocated in the old generation it's always in the runtime slow path, and in that case there are plenty of memory fences when the object is initialized. We could argue that we should stick to this contract with the collectors: whenever we write the klass field we should do so with a store release. But that would mean there are two or three fences for every object allocation. If we really did want to do this on AArch64, we could better by zeroing the object first, writing the length field, then storing the klass field with stlr. One fence rather than two would be better than what we do at the moment, which is storing the klass field then zeroing the object. But, as I said, I don't think that we need to. Which is why I don't think we've seen this "bug" causing mysterious crashes. Andrew. From ci_notify at linaro.org Tue Dec 27 10:46:08 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 27 Dec 2016 10:46:08 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1570252664.2389.1482835569017.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/361/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/09 pass: 1,307; fail: 6; error: 54 Build 1: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 2: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 3: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 4: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 5: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 6: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 7: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 8: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 9: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 Build 10: aarch64/2016/dec/20 pass: 1,283; fail: 25; error: 67 Build 11: aarch64/2016/dec/22 pass: 1,275; fail: 25; error: 75 Build 12: aarch64/2016/dec/23 pass: 1,274; fail: 25; error: 76 Build 13: aarch64/2016/dec/24 pass: 1,273; fail: 25; error: 77 Build 14: aarch64/2016/dec/26 pass: 1,274; fail: 25; error: 76 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/09 pass: 7,208; fail: 651; error: 43 Build 1: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 2: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 3: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 4: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 5: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 6: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 7: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 8: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 9: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 Build 10: aarch64/2016/dec/20 pass: 7,215; fail: 638; error: 51 Build 11: aarch64/2016/dec/22 pass: 7,229; fail: 624; error: 55 Build 12: aarch64/2016/dec/23 pass: 7,203; fail: 640; error: 66 Build 13: aarch64/2016/dec/24 pass: 7,213; fail: 635; error: 62 Build 14: aarch64/2016/dec/26 pass: 7,208; fail: 643; error: 60 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/09 pass: 3,769; fail: 2; error: 17 Build 1: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 2: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 3: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 4: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 5: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 6: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 7: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 8: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 9: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 Build 10: aarch64/2016/dec/20 pass: 3,784; fail: 2; error: 20 Build 11: aarch64/2016/dec/22 pass: 3,792; fail: 1; error: 20 Build 12: aarch64/2016/dec/23 pass: 3,781; fail: 1; error: 31 Build 13: aarch64/2016/dec/24 pass: 3,786; fail: 3; error: 24 Build 14: aarch64/2016/dec/26 pass: 3,781; fail: 3; error: 29 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/09 pass: 1,309; fail: 8; error: 53 Build 1: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 2: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 3: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 4: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 5: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 6: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 7: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 8: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 9: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 Build 10: aarch64/2016/dec/20 pass: 1,285; fail: 27; error: 66 Build 11: aarch64/2016/dec/22 pass: 1,276; fail: 27; error: 75 Build 12: aarch64/2016/dec/23 pass: 1,277; fail: 27; error: 74 Build 13: aarch64/2016/dec/24 pass: 1,276; fail: 27; error: 75 Build 14: aarch64/2016/dec/26 pass: 1,273; fail: 28; error: 77 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/09 pass: 7,241; fail: 627; error: 34 Build 1: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 2: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 3: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 4: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 5: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 6: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 7: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 8: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 9: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 Build 10: aarch64/2016/dec/20 pass: 7,231; fail: 629; error: 44 Build 11: aarch64/2016/dec/22 pass: 7,246; fail: 617; error: 45 Build 12: aarch64/2016/dec/23 pass: 7,223; fail: 638; error: 48 Build 13: aarch64/2016/dec/24 pass: 7,215; fail: 632; error: 63 Build 14: aarch64/2016/dec/26 pass: 7,203; fail: 656; error: 52 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/09 pass: 3,763; fail: 1; error: 24 Build 1: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 2: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 3: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 4: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 5: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 6: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 7: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 8: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 9: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Build 10: aarch64/2016/dec/20 pass: 3,775; fail: 1; error: 30 Build 11: aarch64/2016/dec/22 pass: 3,785; fail: 1; error: 27 Build 12: aarch64/2016/dec/23 pass: 3,780; fail: 1; error: 32 Build 13: aarch64/2016/dec/24 pass: 3,783; fail: 1; error: 29 Build 14: aarch64/2016/dec/26 pass: 3,785; fail: 1; error: 27 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.92x Relative performance: Server critical-jOPS (nc): 0.79x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.58, Server: 104.56 Client 70.58 / Client 2014-04-01 (43.00): 1.64x Server 104.56 / Server 2014-04-01 (71.00): 1.47x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-12-10 pass rate: 6009/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/344/results/ 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ 2016-12-21 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/355/results/ 2016-12-23 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/357/results/ 2016-12-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/358/results/ 2016-12-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/359/results/ 2016-12-27 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/361/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From aph at redhat.com Wed Dec 28 09:54:04 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 28 Dec 2016 09:54:04 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> Message-ID: <38bec92a-9a09-aeb0-d2c3-4e2622545928@redhat.com> On 27/12/16 21:21, Kim Barrett wrote: >> On Dec 27, 2016, at 5:40 AM, Andrew Haley wrote: >> If we really did want to do this on AArch64, we could better by >> zeroing the object first, writing the length field, then storing the >> klass field with stlr. One fence rather than two would be better than >> what we do at the moment, which is storing the klass field then >> zeroing the object. > > I think zeroing the object is intentionally delayed. > > In the slow path, the allocation of a raw chunk of memory is done > while holding the Heap_lock. That lock prevents other Java threads > from entering the slow path. > > Part of that raw chunk allocation makes the chunk unavailable to other > Java threads. But it also makes the chunk visible to a concurrent GC. > Hence the need to first zero out what will eventually be the klass > field. Absolutely so. I was talking about the fast path. Thank you for the explanation: none of what I'd heard before made any sense! Andrew. From kim.barrett at oracle.com Tue Dec 27 21:21:54 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 27 Dec 2016 16:21:54 -0500 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> Message-ID: > On Dec 27, 2016, at 5:40 AM, Andrew Haley wrote: > If we really did want to do this on AArch64, we could better by > zeroing the object first, writing the length field, then storing the > klass field with stlr. One fence rather than two would be better than > what we do at the moment, which is storing the klass field then > zeroing the object. I think zeroing the object is intentionally delayed. In the slow path, the allocation of a raw chunk of memory is done while holding the Heap_lock. That lock prevents other Java threads from entering the slow path. Part of that raw chunk allocation makes the chunk unavailable to other Java threads. But it also makes the chunk visible to a concurrent GC. Hence the need to first zero out what will eventually be the klass field. The concurrent GCs use this as a marker that this memory is in the process of becoming an object, but isn't sufficiently far along to look at the contents. It is important to minimize the lock duration, to allow other Java threads to enter the slow allocation path. By delaying the zeroing of the object, we're trading more memory barriers to reduce the lock duration. While locally better, reducing the number of barriers by moving the object zeroing into the lock region seems likely to be globally worse. From aph at redhat.com Wed Dec 28 10:04:16 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 28 Dec 2016 10:04:16 +0000 Subject: [aarch64-port-dev ] Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: References: Message-ID: On 24/12/16 15:04, Alexander Harlap wrote: > Change is located at http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ AArch64 part looks reasonable. Andrew. From ci_notify at linaro.org Wed Dec 28 11:29:46 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 28 Dec 2016 11:29:46 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <477710207.2419.1482924587049.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/362/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/10 pass: 1,307; fail: 6; error: 54 Build 1: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 2: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 3: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 4: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 5: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 6: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 7: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 8: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 Build 9: aarch64/2016/dec/20 pass: 1,283; fail: 25; error: 67 Build 10: aarch64/2016/dec/22 pass: 1,275; fail: 25; error: 75 Build 11: aarch64/2016/dec/23 pass: 1,274; fail: 25; error: 76 Build 12: aarch64/2016/dec/24 pass: 1,273; fail: 25; error: 77 Build 13: aarch64/2016/dec/26 pass: 1,274; fail: 25; error: 76 Build 14: aarch64/2016/dec/27 pass: 1,273; fail: 25; error: 77 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/10 pass: 7,223; fail: 643; error: 45 Build 1: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 2: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 3: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 4: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 5: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 6: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 7: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 8: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 Build 9: aarch64/2016/dec/20 pass: 7,215; fail: 638; error: 51 Build 10: aarch64/2016/dec/22 pass: 7,229; fail: 624; error: 55 Build 11: aarch64/2016/dec/23 pass: 7,203; fail: 640; error: 66 Build 12: aarch64/2016/dec/24 pass: 7,213; fail: 635; error: 62 Build 13: aarch64/2016/dec/26 pass: 7,208; fail: 643; error: 60 Build 14: aarch64/2016/dec/27 pass: 7,215; fail: 630; error: 65 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/10 pass: 3,770; fail: 1; error: 20 Build 1: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 2: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 3: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 4: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 5: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 6: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 7: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 8: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 Build 9: aarch64/2016/dec/20 pass: 3,784; fail: 2; error: 20 Build 10: aarch64/2016/dec/22 pass: 3,792; fail: 1; error: 20 Build 11: aarch64/2016/dec/23 pass: 3,781; fail: 1; error: 31 Build 12: aarch64/2016/dec/24 pass: 3,786; fail: 3; error: 24 Build 13: aarch64/2016/dec/26 pass: 3,781; fail: 3; error: 29 Build 14: aarch64/2016/dec/27 pass: 3,789; fail: 3; error: 21 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/10 pass: 1,309; fail: 8; error: 53 Build 1: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 2: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 3: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 4: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 5: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 6: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 7: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 8: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 Build 9: aarch64/2016/dec/20 pass: 1,285; fail: 27; error: 66 Build 10: aarch64/2016/dec/22 pass: 1,276; fail: 27; error: 75 Build 11: aarch64/2016/dec/23 pass: 1,277; fail: 27; error: 74 Build 12: aarch64/2016/dec/24 pass: 1,276; fail: 27; error: 75 Build 13: aarch64/2016/dec/26 pass: 1,273; fail: 28; error: 77 Build 14: aarch64/2016/dec/27 pass: 1,275; fail: 27; error: 76 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/10 pass: 7,230; fail: 639; error: 42 Build 1: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 2: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 3: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 4: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 5: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 6: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 7: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 8: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 Build 9: aarch64/2016/dec/20 pass: 7,231; fail: 629; error: 44 Build 10: aarch64/2016/dec/22 pass: 7,246; fail: 617; error: 45 Build 11: aarch64/2016/dec/23 pass: 7,223; fail: 638; error: 48 Build 12: aarch64/2016/dec/24 pass: 7,215; fail: 632; error: 63 Build 13: aarch64/2016/dec/26 pass: 7,203; fail: 656; error: 52 Build 14: aarch64/2016/dec/27 pass: 7,236; fail: 630; error: 44 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/10 pass: 3,762; fail: 1; error: 28 Build 1: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 2: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 3: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 4: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 5: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 6: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 7: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 8: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Build 9: aarch64/2016/dec/20 pass: 3,775; fail: 1; error: 30 Build 10: aarch64/2016/dec/22 pass: 3,785; fail: 1; error: 27 Build 11: aarch64/2016/dec/23 pass: 3,780; fail: 1; error: 32 Build 12: aarch64/2016/dec/24 pass: 3,783; fail: 1; error: 29 Build 13: aarch64/2016/dec/26 pass: 3,785; fail: 1; error: 27 Build 14: aarch64/2016/dec/27 pass: 3,783; fail: 2; error: 28 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.91x Relative performance: Server critical-jOPS (nc): 0.78x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.93, Server: 104.56 Client 70.93 / Client 2014-04-01 (43.00): 1.65x Server 104.56 / Server 2014-04-01 (71.00): 1.47x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-12-11 pass rate: 6008/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/345/results/ 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ 2016-12-21 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/355/results/ 2016-12-23 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/357/results/ 2016-12-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/358/results/ 2016-12-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/359/results/ 2016-12-27 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/361/results/ 2016-12-28 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/362/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From kim.barrett at oracle.com Wed Dec 28 22:53:59 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 28 Dec 2016 17:53:59 -0500 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <38bec92a-9a09-aeb0-d2c3-4e2622545928@redhat.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> <38bec92a-9a09-aeb0-d2c3-4e2622545928@redhat.com> Message-ID: > On Dec 28, 2016, at 4:54 AM, Andrew Haley wrote: > > On 27/12/16 21:21, Kim Barrett wrote: >>> On Dec 27, 2016, at 5:40 AM, Andrew Haley wrote: >>> If we really did want to do this on AArch64, we could better by >>> zeroing the object first, writing the length field, then storing the >>> klass field with stlr. One fence rather than two would be better than >>> what we do at the moment, which is storing the klass field then >>> zeroing the object. >> >> I think zeroing the object is intentionally delayed. >> >> In the slow path, the allocation of a raw chunk of memory is done >> while holding the Heap_lock. That lock prevents other Java threads >> from entering the slow path. >> >> Part of that raw chunk allocation makes the chunk unavailable to other >> Java threads. But it also makes the chunk visible to a concurrent GC. >> Hence the need to first zero out what will eventually be the klass >> field. > > Absolutely so. I was talking about the fast path. I think I see. Where you earlier said "We could argue that we should stick to this contract with the collectors: ...", you were saying one might argue that the TLAB context (fast path) should be covered by the same contract as the slow path, but then counter-argued that this would introduce more membars. And the part about zeroing the object first was a mitigation of the extra membars. Is that correct? If so, sorry I didn't get that earlier. And yes, applying the same slow-path contract to the fast path would be bad; doing so would defeat the whole point of TLAB allocation, which is to avoid all the costs arising from concurrency by using thread-local data to be explicitly non-concurrent. From kim.barrett at oracle.com Wed Dec 28 22:59:12 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 28 Dec 2016 17:59:12 -0500 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> <38bec92a-9a09-aeb0-d2c3-4e2622545928@redhat.com> Message-ID: I think where we've ended up with this discussion is that (1) Derek's proposed change should be withdrawn. (2) JDK-8171449 should be closed as not an issue. (3) There is a FIXME comment in the aarch64 store_klass definition suggesting a release_store might be needed. That comment appears to be incorrect. (4) There are comments on various uses of store_klass in TLAB contexts (for multiple platforms) saying the store_klass must be last due to ordering constraints when using concurrent GCs. Those comments appear to be doubly incorrect; existing concurrent GCs don't impose such an ordering constraint in TLAB contexts, and there are no membars (on platforms where they are needed) to ensure the suggested ordering. (5) There might be uses of store_klass that aren't in TLAB contexts. Someone should look for these to determine whether there actually are any, and whether they have any ordering constraints. If any do have real ordering constraints, then some code changes are likely needed to actually provide that ordering (perhaps an additional ordered form of store_klass). (6) It would be *really* nice to have the contracts in this area written down in some more explicit and accessible form than the code and scattered through multiple email threads. Does that look like a correct summary? From Derek.White at cavium.com Wed Dec 28 23:10:40 2016 From: Derek.White at cavium.com (White, Derek) Date: Wed, 28 Dec 2016 23:10:40 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> <38bec92a-9a09-aeb0-d2c3-4e2622545928@redhat.com> , Message-ID: <67E7616A-5691-4E4C-820F-713792C46D07@cavium.com> Hi Kim, Sounds right. I'm working on some comments and assertions to make some of this more clear. I'll get this out for review Friday or sooner. - Derek > On Dec 28, 2016, at 5:59 PM, Kim Barrett wrote: > > I think where we've ended up with this discussion is that > > (1) Derek's proposed change should be withdrawn. > > (2) JDK-8171449 should be closed as not an issue. > > (3) There is a FIXME comment in the aarch64 store_klass definition > suggesting a release_store might be needed. That comment appears to > be incorrect. > > (4) There are comments on various uses of store_klass in TLAB contexts > (for multiple platforms) saying the store_klass must be last due to > ordering constraints when using concurrent GCs. Those comments appear > to be doubly incorrect; existing concurrent GCs don't impose such an > ordering constraint in TLAB contexts, and there are no membars (on > platforms where they are needed) to ensure the suggested ordering. > > (5) There might be uses of store_klass that aren't in TLAB contexts. > Someone should look for these to determine whether there actually are > any, and whether they have any ordering constraints. If any do have > real ordering constraints, then some code changes are likely needed to > actually provide that ordering (perhaps an additional ordered form of > store_klass). > > (6) It would be *really* nice to have the contracts in this area > written down in some more explicit and accessible form than the code > and scattered through multiple email threads. > > Does that look like a correct summary? > From aph at redhat.com Thu Dec 29 09:29:08 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Dec 2016 09:29:08 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> <38bec92a-9a09-aeb0-d2c3-4e2622545928@redhat.com> Message-ID: <51ec4491-ca57-0c4e-4228-38c62d004cc9@redhat.com> On 28/12/16 22:59, Kim Barrett wrote: > Does that look like a correct summary? It does to me. I've traced through the allocations on every path that I could find. Andrew. From aph at redhat.com Thu Dec 29 09:40:21 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Dec 2016 09:40:21 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: References: <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> <38bec92a-9a09-aeb0-d2c3-4e2622545928@redhat.com> Message-ID: On 28/12/16 22:59, Kim Barrett wrote: > (3) There is a FIXME comment in the aarch64 store_klass definition > suggesting a release_store might be needed. That comment appears to > be incorrect. That comment is there because I was reading the x86 code (on which the AArch64 code is based) and I saw this comment in tlab_refill: movptr(t1, ExternalAddress((address)Universe::intArrayKlassObj_addr())); // store klass last. concurrent gcs assumes klass length is valid if // klass field is not null. store_klass(top, t1); This is when recycling the free space at the top of an old tlab. I think that this comment is wrong. Andrew. From ci_notify at linaro.org Thu Dec 29 10:54:40 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 29 Dec 2016 10:54:40 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <1036500460.2515.1483008880983.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/363/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/11 pass: 1,306; fail: 6; error: 55 Build 1: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 2: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 3: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 4: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 5: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 6: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 7: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 Build 8: aarch64/2016/dec/20 pass: 1,283; fail: 25; error: 67 Build 9: aarch64/2016/dec/22 pass: 1,275; fail: 25; error: 75 Build 10: aarch64/2016/dec/23 pass: 1,274; fail: 25; error: 76 Build 11: aarch64/2016/dec/24 pass: 1,273; fail: 25; error: 77 Build 12: aarch64/2016/dec/26 pass: 1,274; fail: 25; error: 76 Build 13: aarch64/2016/dec/27 pass: 1,273; fail: 25; error: 77 Build 14: aarch64/2016/dec/28 pass: 1,275; fail: 24; error: 78 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/11 pass: 7,198; fail: 657; error: 57 Build 1: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 2: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 3: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 4: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 5: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 6: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 7: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 Build 8: aarch64/2016/dec/20 pass: 7,215; fail: 638; error: 51 Build 9: aarch64/2016/dec/22 pass: 7,229; fail: 624; error: 55 Build 10: aarch64/2016/dec/23 pass: 7,203; fail: 640; error: 66 Build 11: aarch64/2016/dec/24 pass: 7,213; fail: 635; error: 62 Build 12: aarch64/2016/dec/26 pass: 7,208; fail: 643; error: 60 Build 13: aarch64/2016/dec/27 pass: 7,215; fail: 630; error: 65 Build 14: aarch64/2016/dec/28 pass: 7,209; fail: 636; error: 65 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 1: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 2: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 3: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 4: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 5: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 6: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 7: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 Build 8: aarch64/2016/dec/20 pass: 3,784; fail: 2; error: 20 Build 9: aarch64/2016/dec/22 pass: 3,792; fail: 1; error: 20 Build 10: aarch64/2016/dec/23 pass: 3,781; fail: 1; error: 31 Build 11: aarch64/2016/dec/24 pass: 3,786; fail: 3; error: 24 Build 12: aarch64/2016/dec/26 pass: 3,781; fail: 3; error: 29 Build 13: aarch64/2016/dec/27 pass: 3,789; fail: 3; error: 21 Build 14: aarch64/2016/dec/28 pass: 3,782; fail: 2; error: 29 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/11 pass: 1,308; fail: 8; error: 54 Build 1: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 2: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 3: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 4: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 5: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 6: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 7: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 Build 8: aarch64/2016/dec/20 pass: 1,285; fail: 27; error: 66 Build 9: aarch64/2016/dec/22 pass: 1,276; fail: 27; error: 75 Build 10: aarch64/2016/dec/23 pass: 1,277; fail: 27; error: 74 Build 11: aarch64/2016/dec/24 pass: 1,276; fail: 27; error: 75 Build 12: aarch64/2016/dec/26 pass: 1,273; fail: 28; error: 77 Build 13: aarch64/2016/dec/27 pass: 1,275; fail: 27; error: 76 Build 14: aarch64/2016/dec/28 pass: 1,274; fail: 27; error: 79 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/11 pass: 7,222; fail: 653; error: 37 Build 1: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 2: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 3: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 4: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 5: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 6: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 7: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 Build 8: aarch64/2016/dec/20 pass: 7,231; fail: 629; error: 44 Build 9: aarch64/2016/dec/22 pass: 7,246; fail: 617; error: 45 Build 10: aarch64/2016/dec/23 pass: 7,223; fail: 638; error: 48 Build 11: aarch64/2016/dec/24 pass: 7,215; fail: 632; error: 63 Build 12: aarch64/2016/dec/26 pass: 7,203; fail: 656; error: 52 Build 13: aarch64/2016/dec/27 pass: 7,236; fail: 630; error: 44 Build 14: aarch64/2016/dec/28 pass: 7,221; fail: 646; error: 43 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/11 pass: 3,766; fail: 1; error: 24 Build 1: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 2: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 3: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 4: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 5: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 6: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 7: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Build 8: aarch64/2016/dec/20 pass: 3,775; fail: 1; error: 30 Build 9: aarch64/2016/dec/22 pass: 3,785; fail: 1; error: 27 Build 10: aarch64/2016/dec/23 pass: 3,780; fail: 1; error: 32 Build 11: aarch64/2016/dec/24 pass: 3,783; fail: 1; error: 29 Build 12: aarch64/2016/dec/26 pass: 3,785; fail: 1; error: 27 Build 13: aarch64/2016/dec/27 pass: 3,783; fail: 2; error: 28 Build 14: aarch64/2016/dec/28 pass: 3,784; fail: 1; error: 28 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.92x Relative performance: Server critical-jOPS (nc): 0.80x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 72.02, Server: 105.34 Client 72.02 / Client 2014-04-01 (43.00): 1.67x Server 105.34 / Server 2014-04-01 (71.00): 1.48x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-12-12 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/346/results/ 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ 2016-12-21 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/355/results/ 2016-12-23 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/357/results/ 2016-12-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/358/results/ 2016-12-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/359/results/ 2016-12-27 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/361/results/ 2016-12-28 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/362/results/ 2016-12-29 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/363/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/ From Derek.White at cavium.com Fri Dec 30 23:13:36 2016 From: Derek.White at cavium.com (White, Derek) Date: Fri, 30 Dec 2016 23:13:36 +0000 Subject: [aarch64-port-dev ] RFR(s): 8171449" [aarch64] store_klass needs to use store release In-Reply-To: <67E7616A-5691-4E4C-820F-713792C46D07@cavium.com> References: <5360f187-fc05-8d76-62c3-b342c773a637@redhat.com> <1482225262.2831.4.camel@oracle.com> <2cab52e2-b7b9-38e5-70d2-bcf226983b14@redhat.com> <1482229260.2831.48.camel@oracle.com> <33a42c9e-453e-0b71-d0ba-f7d734ea2d19@redhat.com> <1482232161.2831.76.camel@oracle.com> <09a1cdb2-a5a1-75df-f191-2b83cb617f00@redhat.com> <1482322931.2730.28.camel@oracle.com> <1482336047.2730.53.camel@oracle.com> <64be2f1a-85b1-9735-daa7-526573214f14@redhat.com> <1482496314.2973.40.camel@oracle.com> <2efb17b4-ad67-ca68-8818-843862e0a85a@redhat.com> <1482500647.2973.63.camel@oracle.com> <4add583a-1c36-ac76-e405-1b3eb0e68bb0@redhat.com> <38bec92a-9a09-aeb0-d2c3-4e2622545928@redhat.com> , <67E7616A-5691-4E4C-820F-713792C46D07@cavium.com> Message-ID: Thanks you all for the great discussion. This bug has been closed. A new bug has been opened to handle the issue of better documentation and assertions: https://bugs.openjdk.java.net/browse/JDK-8172157 "Tighten up contract between concurrent GCs and runtime regarding object allocation and header initialization". - Derek -----Original Message----- From: White, Derek Sent: Wednesday, December 28, 2016 6:11 PM To: Kim Barrett Cc: Andrew Haley ; Thomas Schatzl ; aarch64-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(s): 8171449" [aarch64] store_klass needs to use store release Hi Kim, Sounds right. I'm working on some comments and assertions to make some of this more clear. I'll get this out for review Friday or sooner. - Derek > On Dec 28, 2016, at 5:59 PM, Kim Barrett wrote: > > I think where we've ended up with this discussion is that > > (1) Derek's proposed change should be withdrawn. > > (2) JDK-8171449 should be closed as not an issue. > > (3) There is a FIXME comment in the aarch64 store_klass definition > suggesting a release_store might be needed. That comment appears to > be incorrect. > > (4) There are comments on various uses of store_klass in TLAB contexts > (for multiple platforms) saying the store_klass must be last due to > ordering constraints when using concurrent GCs. Those comments appear > to be doubly incorrect; existing concurrent GCs don't impose such an > ordering constraint in TLAB contexts, and there are no membars (on > platforms where they are needed) to ensure the suggested ordering. > > (5) There might be uses of store_klass that aren't in TLAB contexts. > Someone should look for these to determine whether there actually are > any, and whether they have any ordering constraints. If any do have > real ordering constraints, then some code changes are likely needed to > actually provide that ordering (perhaps an additional ordered form of > store_klass). > > (6) It would be *really* nice to have the contracts in this area > written down in some more explicit and accessible form than the code > and scattered through multiple email threads. > > Does that look like a correct summary? > From ci_notify at linaro.org Sat Dec 31 11:08:45 2016 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 31 Dec 2016 11:08:45 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 9 on AArch64 Message-ID: <70707717.2653.1483182525531.JavaMail.jenkins@ci.linaro.org> 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/jdk9/openjdk-jtreg-nightly-tests/summary/2016/365/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/12 pass: 1,307; fail: 6; error: 54 Build 1: aarch64/2016/dec/14 pass: 1,310; fail: 7; error: 58 Build 2: aarch64/2016/dec/15 pass: 1,309; fail: 6; error: 60 Build 3: aarch64/2016/dec/16 pass: 1,304; fail: 6; error: 65 Build 4: aarch64/2016/dec/17 pass: 1,305; fail: 6; error: 64 Build 5: aarch64/2016/dec/18 pass: 1,304; fail: 6; error: 65 Build 6: aarch64/2016/dec/19 pass: 1,286; fail: 25; error: 64 Build 7: aarch64/2016/dec/20 pass: 1,283; fail: 25; error: 67 Build 8: aarch64/2016/dec/22 pass: 1,275; fail: 25; error: 75 Build 9: aarch64/2016/dec/23 pass: 1,274; fail: 25; error: 76 Build 10: aarch64/2016/dec/24 pass: 1,273; fail: 25; error: 77 Build 11: aarch64/2016/dec/26 pass: 1,274; fail: 25; error: 76 Build 12: aarch64/2016/dec/27 pass: 1,273; fail: 25; error: 77 Build 13: aarch64/2016/dec/28 pass: 1,275; fail: 24; error: 78 Build 14: aarch64/2016/dec/30 pass: 1,272; fail: 25; error: 80 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/12 pass: 7,223; fail: 639; error: 51 Build 1: aarch64/2016/dec/14 pass: 7,218; fail: 639; error: 58 Build 2: aarch64/2016/dec/15 pass: 7,224; fail: 642; error: 51 Build 3: aarch64/2016/dec/16 pass: 7,191; fail: 647; error: 54 Build 4: aarch64/2016/dec/17 pass: 7,206; fail: 647; error: 48 Build 5: aarch64/2016/dec/18 pass: 7,199; fail: 653; error: 49 Build 6: aarch64/2016/dec/19 pass: 7,196; fail: 653; error: 51 Build 7: aarch64/2016/dec/20 pass: 7,215; fail: 638; error: 51 Build 8: aarch64/2016/dec/22 pass: 7,229; fail: 624; error: 55 Build 9: aarch64/2016/dec/23 pass: 7,203; fail: 640; error: 66 Build 10: aarch64/2016/dec/24 pass: 7,213; fail: 635; error: 62 Build 11: aarch64/2016/dec/26 pass: 7,208; fail: 643; error: 60 Build 12: aarch64/2016/dec/27 pass: 7,215; fail: 630; error: 65 Build 13: aarch64/2016/dec/28 pass: 7,209; fail: 636; error: 65 Build 14: aarch64/2016/dec/30 pass: 7,234; fail: 619; error: 57 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/12 pass: 3,771; fail: 1; error: 19 Build 1: aarch64/2016/dec/14 pass: 3,776; fail: 1; error: 19 Build 2: aarch64/2016/dec/15 pass: 3,779; fail: 2; error: 20 Build 3: aarch64/2016/dec/16 pass: 3,771; fail: 1; error: 32 Build 4: aarch64/2016/dec/17 pass: 3,783; fail: 2; error: 23 Build 5: aarch64/2016/dec/18 pass: 3,787; fail: 1; error: 20 Build 6: aarch64/2016/dec/19 pass: 3,782; fail: 3; error: 23 Build 7: aarch64/2016/dec/20 pass: 3,784; fail: 2; error: 20 Build 8: aarch64/2016/dec/22 pass: 3,792; fail: 1; error: 20 Build 9: aarch64/2016/dec/23 pass: 3,781; fail: 1; error: 31 Build 10: aarch64/2016/dec/24 pass: 3,786; fail: 3; error: 24 Build 11: aarch64/2016/dec/26 pass: 3,781; fail: 3; error: 29 Build 12: aarch64/2016/dec/27 pass: 3,789; fail: 3; error: 21 Build 13: aarch64/2016/dec/28 pass: 3,782; fail: 2; error: 29 Build 14: aarch64/2016/dec/30 pass: 3,786; fail: 1; error: 26 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/12 pass: 1,307; fail: 8; error: 55 Build 1: aarch64/2016/dec/14 pass: 1,313; fail: 8; error: 57 Build 2: aarch64/2016/dec/15 pass: 1,309; fail: 8; error: 61 Build 3: aarch64/2016/dec/16 pass: 1,308; fail: 8; error: 62 Build 4: aarch64/2016/dec/17 pass: 1,307; fail: 8; error: 63 Build 5: aarch64/2016/dec/18 pass: 1,306; fail: 8; error: 64 Build 6: aarch64/2016/dec/19 pass: 1,289; fail: 27; error: 62 Build 7: aarch64/2016/dec/20 pass: 1,285; fail: 27; error: 66 Build 8: aarch64/2016/dec/22 pass: 1,276; fail: 27; error: 75 Build 9: aarch64/2016/dec/23 pass: 1,277; fail: 27; error: 74 Build 10: aarch64/2016/dec/24 pass: 1,276; fail: 27; error: 75 Build 11: aarch64/2016/dec/26 pass: 1,273; fail: 28; error: 77 Build 12: aarch64/2016/dec/27 pass: 1,275; fail: 27; error: 76 Build 13: aarch64/2016/dec/28 pass: 1,274; fail: 27; error: 79 Build 14: aarch64/2016/dec/30 pass: 1,273; fail: 27; error: 80 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/12 pass: 7,221; fail: 644; error: 48 Build 1: aarch64/2016/dec/14 pass: 7,232; fail: 635; error: 48 Build 2: aarch64/2016/dec/15 pass: 7,239; fail: 637; error: 41 Build 3: aarch64/2016/dec/16 pass: 7,207; fail: 642; error: 43 Build 4: aarch64/2016/dec/17 pass: 7,222; fail: 635; error: 44 Build 5: aarch64/2016/dec/18 pass: 7,230; fail: 626; error: 45 Build 6: aarch64/2016/dec/19 pass: 7,216; fail: 641; error: 43 Build 7: aarch64/2016/dec/20 pass: 7,231; fail: 629; error: 44 Build 8: aarch64/2016/dec/22 pass: 7,246; fail: 617; error: 45 Build 9: aarch64/2016/dec/23 pass: 7,223; fail: 638; error: 48 Build 10: aarch64/2016/dec/24 pass: 7,215; fail: 632; error: 63 Build 11: aarch64/2016/dec/26 pass: 7,203; fail: 656; error: 52 Build 12: aarch64/2016/dec/27 pass: 7,236; fail: 630; error: 44 Build 13: aarch64/2016/dec/28 pass: 7,221; fail: 646; error: 43 Build 14: aarch64/2016/dec/30 pass: 7,228; fail: 629; error: 53 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2016/dec/12 pass: 3,765; fail: 1; error: 25 Build 1: aarch64/2016/dec/14 pass: 3,770; fail: 1; error: 25 Build 2: aarch64/2016/dec/15 pass: 3,777; fail: 1; error: 23 Build 3: aarch64/2016/dec/16 pass: 3,776; fail: 1; error: 27 Build 4: aarch64/2016/dec/17 pass: 3,785; fail: 1; error: 22 Build 5: aarch64/2016/dec/18 pass: 3,778; fail: 1; error: 29 Build 6: aarch64/2016/dec/19 pass: 3,781; fail: 2; error: 25 Build 7: aarch64/2016/dec/20 pass: 3,775; fail: 1; error: 30 Build 8: aarch64/2016/dec/22 pass: 3,785; fail: 1; error: 27 Build 9: aarch64/2016/dec/23 pass: 3,780; fail: 1; error: 32 Build 10: aarch64/2016/dec/24 pass: 3,783; fail: 1; error: 29 Build 11: aarch64/2016/dec/26 pass: 3,785; fail: 1; error: 27 Build 12: aarch64/2016/dec/27 pass: 3,783; fail: 2; error: 28 Build 13: aarch64/2016/dec/28 pass: 3,784; fail: 1; error: 28 Build 14: aarch64/2016/dec/30 pass: 3,783; fail: 1; error: 29 Previous results can be found here: http://openjdk.linaro.org/jdk9/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 0.92x Relative performance: Server critical-jOPS (nc): 0.83x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 69.19, Server: 103.79 Client 69.19 / Client 2014-04-01 (43.00): 1.61x Server 103.79 / Server 2014-04-01 (71.00): 1.46x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk9/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2016-12-13 pass rate: 5981/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/347/results/ 2016-12-15 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/349/results/ 2016-12-16 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/350/results/ 2016-12-17 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/351/results/ 2016-12-18 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/352/results/ 2016-12-19 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/353/results/ 2016-12-20 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/354/results/ 2016-12-21 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/355/results/ 2016-12-23 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/357/results/ 2016-12-24 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/358/results/ 2016-12-25 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/359/results/ 2016-12-27 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/361/results/ 2016-12-28 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/362/results/ 2016-12-29 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/363/results/ 2016-12-31 pass rate: 6050/6050, results: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/2016/365/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk9/jcstress-nightly-runs/