From edward.nevill at gmail.com Mon Nov 2 09:06:59 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 02 Nov 2015 09:06:59 +0000 Subject: [aarch64-port-dev ] JTREG, SPECjbb2013 and Hadoop/Terasort results for OpenJDK 8 on AArch64 Message-ID: <1446455219.29642.1.camel@mint> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 10 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/summary/2015/302/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/may/29 pass: 605; fail: 55; error: 2 Build 1: aarch64/2015/jun/02 pass: 606; fail: 54; error: 2 Build 2: aarch64/2015/jul/02 pass: 636; fail: 45; error: 5 Build 3: aarch64/2015/jul/08 pass: 636; fail: 45; error: 5 Build 4: aarch64/2015/jul/21 pass: 637; fail: 45; error: 5 Build 5: aarch64/2015/sep/04 pass: 636; fail: 46; error: 5 Build 6: aarch64/2015/sep/08 pass: 636; fail: 46; error: 5 Build 7: aarch64/2015/oct/22 pass: 637; fail: 45; error: 5 Build 8: aarch64/2015/oct/27 pass: 637; fail: 45; error: 5 Build 9: aarch64/2015/oct/29 pass: 637; fail: 45; error: 5 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/may/29 pass: 5,350; fail: 217; error: 24 Build 1: aarch64/2015/jun/02 pass: 5,353; fail: 219; error: 19 Build 2: aarch64/2015/jul/02 pass: 5,499; fail: 230; error: 20 Build 3: aarch64/2015/jul/08 pass: 5,485; fail: 242; error: 22 Build 4: aarch64/2015/jul/21 pass: 5,502; fail: 233; error: 18 Build 5: aarch64/2015/sep/04 pass: 5,477; fail: 254; error: 22 Build 6: aarch64/2015/sep/08 pass: 5,477; fail: 254; error: 22 Build 7: aarch64/2015/oct/22 pass: 5,482; fail: 254; error: 17 Build 8: aarch64/2015/oct/27 pass: 5,472; fail: 259; error: 22 Build 9: aarch64/2015/oct/29 pass: 5,503; fail: 229; error: 21 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/may/29 pass: 3,062; error: 11 Build 1: aarch64/2015/jun/02 pass: 3,054; fail: 4; error: 15 Build 2: aarch64/2015/jul/02 pass: 3,076; error: 15 Build 3: aarch64/2015/jul/08 pass: 3,080; error: 11 Build 4: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 5: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 6: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 7: aarch64/2015/oct/22 pass: 3,077; error: 14 Build 8: aarch64/2015/oct/27 pass: 3,081; error: 10 Build 9: aarch64/2015/oct/29 pass: 3,079; error: 12 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/may/29 pass: 628; fail: 32; error: 2 Build 1: aarch64/2015/jun/02 pass: 626; fail: 33; error: 3 Build 2: aarch64/2015/jul/02 pass: 644; fail: 37; error: 5 Build 3: aarch64/2015/jul/08 pass: 644; fail: 37; error: 5 Build 4: aarch64/2015/jul/21 pass: 645; fail: 37; error: 5 Build 5: aarch64/2015/sep/04 pass: 645; fail: 37; error: 5 Build 6: aarch64/2015/sep/08 pass: 645; fail: 37; error: 5 Build 7: aarch64/2015/oct/22 pass: 644; fail: 38; error: 5 Build 8: aarch64/2015/oct/27 pass: 644; fail: 38; error: 5 Build 9: aarch64/2015/oct/29 pass: 645; fail: 37; error: 5 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/may/29 pass: 5,358; fail: 209; error: 24 Build 1: aarch64/2015/jun/02 pass: 5,357; fail: 213; error: 21 Build 2: aarch64/2015/jul/02 pass: 5,510; fail: 215; error: 24 Build 3: aarch64/2015/jul/08 pass: 5,506; fail: 221; error: 22 Build 4: aarch64/2015/jul/21 pass: 5,512; fail: 217; error: 24 Build 5: aarch64/2015/sep/04 pass: 5,471; fail: 257; error: 25 Build 6: aarch64/2015/sep/08 pass: 5,471; fail: 257; error: 25 Build 7: aarch64/2015/oct/22 pass: 5,489; fail: 241; error: 23 Build 8: aarch64/2015/oct/27 pass: 5,495; fail: 234; error: 24 Build 9: aarch64/2015/oct/29 pass: 5,521; fail: 209; error: 23 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/may/29 pass: 3,063; fail: 1; error: 9 Build 1: aarch64/2015/jun/02 pass: 3,064; error: 9 Build 2: aarch64/2015/jul/02 pass: 3,078; error: 13 Build 3: aarch64/2015/jul/08 pass: 3,083; error: 8 Build 4: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 5: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 6: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 7: aarch64/2015/oct/22 pass: 3,082; fail: 2; error: 7 Build 8: aarch64/2015/oct/27 pass: 3,083; error: 8 Build 9: aarch64/2015/oct/29 pass: 3,081; error: 10 Previous results can be found here: http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/index.html SPECjbb2013 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2013 composite tests and compares the performance against the baseline performance of the server compiler taken on 2014-04-01. In accordance with [1], the SPECjbb2013 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.11x Relative performance: Server critical-jOPS (nc): 1.58x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/SPECjbb2013-1.00-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: 48.67, Server: 82.54 Client 48.67 / Client 2014-04-01 (43.00): 1.13x Server 82.54 / Server 2014-04-01 (71.00): 1.16x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 10 days. 2015-05-29 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/149/results/ 2015-06-02 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/153/results/ 2015-07-02 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/183/results/ 2015-07-08 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/189/results/ 2015-07-21 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/202/results/ 2015-09-04 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/247/results/ 2015-09-08 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/251/results/ 2015-10-22 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/295/results/ 2015-10-27 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/300/results/ 2015-10-29 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/302/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jcstress-nightly-runs/ From gnu.andrew at redhat.com Mon Nov 2 17:06:51 2015 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 02 Nov 2015 17:06:51 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u60/hotspot: Correct bad #elif in abstractInterpreter.hpp, resulting from ff13d8140756 Message-ID: <201511021706.tA2H6pAq024771@aojmv0008.oracle.com> Changeset: 83f5fdfd56ec Author: andrew Date: 2015-11-02 17:05 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/rev/83f5fdfd56ec Correct bad #elif in abstractInterpreter.hpp, resulting from ff13d8140756 ! src/share/vm/interpreter/abstractInterpreter.hpp From gnu.andrew at redhat.com Mon Nov 2 17:18:27 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 2 Nov 2015 12:18:27 -0500 (EST) Subject: [aarch64-port-dev ] Bad elif in AArch64 8u and 8u60 branches In-Reply-To: <732008115.1083270.1446484319061.JavaMail.zimbra@redhat.com> Message-ID: <1945730862.1086493.1446484707810.JavaMail.zimbra@redhat.com> It seems that: changeset: 8561:ff13d8140756 user: enevill date: Mon Sep 14 21:40:39 2015 +0000 summary: Fix mismerge when merging up to jdk8u60-b21 introduced a bad #elif conditional in abstractInterpeter.hpp, as reported by: https://bugzilla.redhat.com/show_bug.cgi?id=1276959 The mistake can be clearly be seen by comparing the AArch64 8u60 version of the file with the one I merged myself in IcedTea: $ diff -u {,../../icedtea8/hotspot/}src/share/vm/interpreter/abstractInterpreter.hpp --- src/share/vm/interpreter/abstractInterpreter.hpp 2015-09-18 01:09:48.089880065 +0100 +++ ../../icedtea8/hotspot/src/share/vm/interpreter/abstractInterpreter.hpp 2015-10-01 01:04:00.823520919 +0100 @@ -34,7 +34,7 @@ # include INTERP_MASM_MD_HPP #elif defined TARGET_ARCH_x86 # include "interp_masm_x86.hpp" -#elif TARGET_ARCH_MODEL_aarch64 +#elif defined TARGET_ARCH_MODEL_aarch64 # include "interp_masm_aarch64.hpp" #elif defined TARGET_ARCH_MODEL_sparc # include "interp_masm_sparc.hpp" I've pushed this to the affected trees as a trivial fix. http://hg.openjdk.java.net/aarch64-port/jdk8u60/hotspot/rev/83f5fdfd56ec -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From edward.nevill at gmail.com Tue Nov 3 09:11:57 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 03 Nov 2015 09:11:57 +0000 Subject: [aarch64-port-dev ] Project proposal: AArch32 port In-Reply-To: <1446040701.26259.11.camel@gmx.com> References: <1444830648.7802.34.camel@mylittlepony.linaroharston> <5628A5D2.40909@oracle.com> <1445518014.29998.4.camel@mylittlepony.linaroharston> <562A2DBB.9000404@oracle.com> <1445607702.28722.19.camel@mint> <1446040701.26259.11.camel@gmx.com> Message-ID: <1446541917.18905.12.camel@mylittlepony.linaroharston> On Wed, 2015-10-28 at 13:58 +0000, Joseph Joyce wrote: > Hi Ed and Dalibor, > > There's no code in there from other open source projects. As far as I > can remember the only code from elsewhere was an algorithm for > division, which came from > http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252div.txt > The code was modified a bit to work for the assembler, the url from > which it came is mentioned in the source (MacroAssembler::divide32). If > this is a problem I can easily replace the code with a call out to a C > (or Ed suggested using the algorithm from the ARM32-Microjit). > > I have now signed and sent the OCA (today) and would like to continue > contributing to this project. If I could be added to the committers that > would be great. Hi Joseph, That's great news. I therefore propose Joseph Joyce as an additional committer for the aarch32 project. I have had a look at the divide routine in the template interpreter and the original by Graeme Williams. I do not believe this should be an issue as your implementation of the algorithm is completely different. For a start yours is written in C calling the MacroAssembler methods to generate the code, whereas his is written in some sort of BASIC assembler. So although the algorithm is the same the implementation is different and AIUI it is the implementation that is copyrighted. Dalibor: If you are happy with this may I proceed to a CFV for the aarch32 project. Thanks, Ed. From edward.nevill at gmail.com Tue Nov 3 10:47:01 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 03 Nov 2015 10:47:01 +0000 Subject: [aarch64-port-dev ] RFR: Some 32 bit shifts still being anded with 0x3f instead of 0x1f. Message-ID: <1446547621.18905.16.camel@mylittlepony.linaroharston> Hi, Some 32 bit shifts are still being anded with 0x3f instead of 0x1f. This seems to have been caused by aarch64_ad.m4 not being run. I have rerun aarch64_ad.m4. http://cr.openjdk.java.net/~enevill/jdk8_shifts/webrev OK to push? Ed. From adinn at redhat.com Tue Nov 3 11:10:03 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 3 Nov 2015 11:10:03 +0000 Subject: [aarch64-port-dev ] RFR: Some 32 bit shifts still being anded with 0x3f instead of 0x1f. In-Reply-To: <1446547621.18905.16.camel@mylittlepony.linaroharston> References: <1446547621.18905.16.camel@mylittlepony.linaroharston> Message-ID: <5638960B.1060600@redhat.com> On 03/11/15 10:47, Edward Nevill wrote: > Hi, > > Some 32 bit shifts are still being anded with 0x3f instead of 0x1f. > > This seems to have been caused by aarch64_ad.m4 not being run. > > I have rerun aarch64_ad.m4. > > http://cr.openjdk.java.net/~enevill/jdk8_shifts/webrev > > OK to push? Yes, looks ok to me. regards, Andrew Dinn ----------- From dalibor.topic at oracle.com Tue Nov 3 13:57:18 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 3 Nov 2015 14:57:18 +0100 Subject: [aarch64-port-dev ] Project proposal: AArch32 port In-Reply-To: <1446541917.18905.12.camel@mylittlepony.linaroharston> References: <1444830648.7802.34.camel@mylittlepony.linaroharston> <5628A5D2.40909@oracle.com> <1445518014.29998.4.camel@mylittlepony.linaroharston> <562A2DBB.9000404@oracle.com> <1445607702.28722.19.camel@mint> <1446040701.26259.11.camel@gmx.com> <1446541917.18905.12.camel@mylittlepony.linaroharston> Message-ID: <5638BD3E.5040209@oracle.com> Thanks, Edward & Joseph - no objections from me on proceeding to the next step. I'll take a look at the incoming OCA queue to see where we are with processing Joseph's OCA, and let you both know once it's processed. cheers, dalibor topic On 03.11.2015 10:11, Edward Nevill wrote: > On Wed, 2015-10-28 at 13:58 +0000, Joseph Joyce wrote: >> Hi Ed and Dalibor, >> >> There's no code in there from other open source projects. As far as I >> can remember the only code from elsewhere was an algorithm for >> division, which came from >> http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252div.txt >> The code was modified a bit to work for the assembler, the url from >> which it came is mentioned in the source (MacroAssembler::divide32). If >> this is a problem I can easily replace the code with a call out to a C >> (or Ed suggested using the algorithm from the ARM32-Microjit). >> >> I have now signed and sent the OCA (today) and would like to continue >> contributing to this project. If I could be added to the committers that >> would be great. > > Hi Joseph, > > That's great news. I therefore propose Joseph Joyce as an additional > committer for the aarch32 project. > > I have had a look at the divide routine in the template interpreter and > the original by Graeme Williams. I do not believe this should be an > issue as your implementation of the algorithm is completely different. > For a start yours is written in C calling the MacroAssembler methods to > generate the code, whereas his is written in some sort of BASIC > assembler. So although the algorithm is the same the implementation is > different and AIUI it is the implementation that is copyrighted. > > Dalibor: If you are happy with this may I proceed to a CFV for the > aarch32 project. > > Thanks, > Ed. > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From edward.nevill at gmail.com Tue Nov 3 14:02:34 2015 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Tue, 03 Nov 2015 14:02:34 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: Some 32 bit shifts still being anded with 0x3f instead of 0x1f. Message-ID: <201511031402.tA3E2Yko007343@aojmv0008.oracle.com> Changeset: 2115e6f0cbee Author: enevill Date: 2015-11-03 10:39 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/2115e6f0cbee Some 32 bit shifts still being anded with 0x3f instead of 0x1f. ! src/cpu/aarch64/vm/aarch64.ad From edward.nevill at gmail.com Tue Nov 3 16:36:58 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 03 Nov 2015 16:36:58 +0000 Subject: [aarch64-port-dev ] RFR: Backports from JDK8 to JDK7 Message-ID: <1446568618.24670.8.camel@mylittlepony.linaroharston> Hi, Please review the following backports from JDK8 to JDK7 (icedtea7-forest). http://people.linaro.org/~edward.nevill/jdk7-backports-1510 See summary of the changesets below. Thanks, Ed. --- CUT HERE --- changeset: 6378:75d1c4168925 tag: tip user: aph date: Tue Sep 29 17:01:37 2015 +0000 files: src/cpu/aarch64/vm/assembler_aarch64.cpp src/cpu/aarch64/vm/assembler_aarch64.hpp description: 8138575: Improve generated code for profile counters Reviewed-by: kvn changeset: 6377:ad277cc2ef09 user: aph date: Wed Sep 30 13:23:46 2015 +0000 files: src/cpu/aarch64/vm/c2_globals_aarch64.hpp description: 8138641: Disable C2 peephole by default for aarch64 Reviewed-by: roland Contributed-by: felix.yang at linaro.org changeset: 6376:9739ea27122a user: enevill date: Wed Sep 16 13:50:57 2015 +0000 files: src/cpu/aarch64/vm/aarch64.ad description: 8136615: aarch64: elide DecodeN when followed by CmpP 0 Summary: remove DecodeN when comparing a narrow oop with 0 Reviewed-by: kvn, adinn changeset: 6375:065c4ead59c3 user: adinn date: Wed Aug 26 17:13:59 2015 +0100 files: src/cpu/aarch64/vm/aarch64.ad description: 8134322: AArch64: Fix several errors in C2 biased locking implementation Summary: Several errors in C2 biased locking require fixing Reviewed-by: kvn Contributed-by: hui.shi at linaro.org changeset: 6374:7b194a9b9fa1 user: enevill date: Thu Aug 20 09:40:08 2015 +0000 files: src/cpu/aarch64/vm/aarch64.ad src/cpu/aarch64/vm/aarch64_ad.m4 description: 8133842: aarch64: C2 generates illegal instructions with int shifts >=32 Summary: Fix logical operatations combined with shifts >= 32 Reviewed-by: duke changeset: 6373:027348ed6e01 user: enevill date: Tue Aug 18 12:40:22 2015 +0000 files: src/cpu/aarch64/vm/assembler_aarch64.cpp src/cpu/aarch64/vm/assembler_aarch64.hpp src/cpu/aarch64/vm/interp_masm_aarch6 4.cpp src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp description: 8133352: aarch64: generates constrained unpredictable instructions Summary: Fix generation of unpredictable STXR Rs, Rt, [Rn] with Rs == Rt Reviewed-by: kvn, aph, adinn changeset: 6372:25ce0dcaaebe user: enevill date: Thu Jul 16 14:16:44 2015 +0000 files: src/cpu/aarch64/vm/assembler_aarch64.cpp src/cpu/aarch64/vm/assembler_aarch64.hpp description: 8131483: aarch64: illegal stlxr instructions Summary: Do not generate stlxX with Ws == Xn Reviewed-by: kvn, aph changeset: 6371:37ec298f263d user: enevill date: Wed May 27 09:02:08 2015 +0000 files: src/cpu/aarch64/vm/globals_aarch64.hpp src/cpu/aarch64/vm/templateTable_aarch64.cpp description: 8081289: aarch64: add support for RewriteFrequentPairs in interpreter Summary: Add support for RewriteFrequentPairs Reviewed-by: roland Contributed-by: alexander.alexeev at caviumnetworks.com --- CUT HERE --- From adinn at redhat.com Tue Nov 3 16:47:25 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 3 Nov 2015 16:47:25 +0000 Subject: [aarch64-port-dev ] RFR: Backports from JDK8 to JDK7 In-Reply-To: <1446568618.24670.8.camel@mylittlepony.linaroharston> References: <1446568618.24670.8.camel@mylittlepony.linaroharston> Message-ID: <5638E51D.7060209@redhat.com> On 03/11/15 16:36, Edward Nevill wrote: > Hi, > > Please review the following backports from JDK8 to JDK7 (icedtea7-forest). > > http://people.linaro.org/~edward.nevill/jdk7-backports-1510 > > See summary of the changesets below. They all look good. I assume they compile and run ok? :-) regards, Andrew Dinn ----------- From edward.nevill at gmail.com Wed Nov 4 08:58:28 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 04 Nov 2015 08:58:28 +0000 Subject: [aarch64-port-dev ] RFR: Backports from JDK8 to JDK7 In-Reply-To: <5638E51D.7060209@redhat.com> References: <1446568618.24670.8.camel@mylittlepony.linaroharston> <5638E51D.7060209@redhat.com> Message-ID: <1446627508.32758.1.camel@mylittlepony.linaroharston> On Tue, 2015-11-03 at 16:47 +0000, Andrew Dinn wrote: > > On 03/11/15 16:36, Edward Nevill wrote: > > Hi, > > > > Please review the following backports from JDK8 to JDK7 (icedtea7-forest). > > > > http://people.linaro.org/~edward.nevill/jdk7-backports-1510 > > > > See summary of the changesets below. > > They all look good. I assume they compile and run ok? :-) Yes. jtreg results for hotspot and langtools are the same before and after Hotspot: Test results: passed: 294; failed: 11 Langtools: Test results: passed: 1,971; failed: 1; error: 2 Regards, Ed. From adinn at redhat.com Wed Nov 4 10:18:52 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 4 Nov 2015 10:18:52 +0000 Subject: [aarch64-port-dev ] RFR: Backports from JDK8 to JDK7 In-Reply-To: <1446627508.32758.1.camel@mylittlepony.linaroharston> References: <1446568618.24670.8.camel@mylittlepony.linaroharston> <5638E51D.7060209@redhat.com> <1446627508.32758.1.camel@mylittlepony.linaroharston> Message-ID: <5639DB8C.6060103@redhat.com> On 04/11/15 08:58, Edward Nevill wrote: > On Tue, 2015-11-03 at 16:47 +0000, Andrew Dinn wrote: >> >> On 03/11/15 16:36, Edward Nevill wrote: >>> Hi, >>> >>> Please review the following backports from JDK8 to JDK7 (icedtea7-forest). >>> >>> http://people.linaro.org/~edward.nevill/jdk7-backports-1510 >>> >>> See summary of the changesets below. >> >> They all look good. I assume they compile and run ok? :-) > > Yes. jtreg results for hotspot and langtools are the same before and after > > Hotspot: Test results: passed: 294; failed: 11 > Langtools: Test results: passed: 1,971; failed: 1; error: 2 Ok, push the changes! regards, Andrew Dinn ----------- From edward.nevill at gmail.com Wed Nov 4 17:18:25 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 04 Nov 2015 17:18:25 +0000 Subject: [aarch64-port-dev ] jdk8: random null pointer exceptions from javac Message-ID: <1446657505.6419.36.camel@mylittlepony.linaroharston> Hi, For some time I have been observing random, infrequent null pointer exceptions in javac. These were not repeatable but seemed to happen about once every 10 builds of OpenJDK. I think I have found the cause. Backing out the the following changeset causes the problem to go away. changeset: 8153:394a87600c41 user: enevill date: Fri Apr 24 11:01:37 2015 +0000 files: src/cpu/aarch64/vm/aarch64.ad src/cpu/aarch64/vm/frame_aarch64.inline.hpp description: 8075930: AARCH64: Use FP Register in C2 Summary: modify to allow C2 to allocate FP (R29) as a general register Reviewed-by: aph, kvn, dlong Now this change allows C2 to allocate FP for integer only registers. It is not supposed to allow C2 to allocate FP for pointers because FP is not included in the register class no_special_ptr_reg. However I observe the following output from C2. 0x000003ff71023b6c: bl 0x000003ff700b23c0 ; OopMap{rfp=NarrowOop [0]=Oop [8]=Oop [16]=Oop [24]=Oop [32]=Oop off=432} ;*invokevirtual accept So iRegINoSp() in aarch64.ad is // Integer 32 bit Register not Special operand iRegINoSp() %{ constraint(ALLOC_IN_RC(no_special_reg32)); match(RegI); op_cost(0); format %{ %} interface(REG_INTER); %} Where no_special_reg32 is just a general integer register (which includes FP). Now I have zero confidence that the GC stack walking code correctly unwinds FP and finds the NarrowOop therein. I have created a patch which creates a new register class no_special_ptrN_reg which excludes FP and used that in iRegINoSp instead. Patch at http://people.linaro.org/~edward.nevill/patches/narrowptr.patch I have since done 100 builds of OpenJDK without a failure. Is this the correct fix? Or should we try to do the stack unwinding code correctly so it finds ptrs in FP? Regards, Ed. From aph at redhat.com Wed Nov 4 18:18:11 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 4 Nov 2015 18:18:11 +0000 Subject: [aarch64-port-dev ] jdk8: random null pointer exceptions from javac In-Reply-To: <1446657505.6419.36.camel@mylittlepony.linaroharston> References: <1446657505.6419.36.camel@mylittlepony.linaroharston> Message-ID: <563A4BE3.5040003@redhat.com> On 11/04/2015 05:18 PM, Edward Nevill wrote: > For some time I have been observing random, infrequent null pointer > exceptions in javac. These were not repeatable but seemed to happen > about once every 10 builds of OpenJDK. > > I think I have found the cause. Backing out the the following > changeset causes the problem to go away. I'd love to see something more concrete. As far as I can tell you're simply preventing the register allocator from putting a narrow OOP in FP. But why only narrow OOPs? DO you have any grounds for believing this is correct? And what about JDK9? Andrew. From dean.long at oracle.com Wed Nov 4 20:55:34 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 4 Nov 2015 12:55:34 -0800 Subject: [aarch64-port-dev ] jdk8: random null pointer exceptions from javac In-Reply-To: <1446657505.6419.36.camel@mylittlepony.linaroharston> References: <1446657505.6419.36.camel@mylittlepony.linaroharston> Message-ID: <563A70C6.4090903@oracle.com> If aarch64 behaves the same way as x86, then shouldn't frame::update_map_with_saved_link() make sure FP is in the oopmap? Is the NarrowOop in question generated by a MachTemp by any chance? The problem you describe reminds me of JDK-8051805. dl On 11/4/2015 9:18 AM, Edward Nevill wrote: > Hi, > > For some time I have been observing random, infrequent null pointer exceptions in javac. These were not repeatable but seemed to happen about once every 10 builds of OpenJDK. > > I think I have found the cause. Backing out the the following changeset causes the problem to go away. > > changeset: 8153:394a87600c41 > user: enevill > date: Fri Apr 24 11:01:37 2015 +0000 > files: src/cpu/aarch64/vm/aarch64.ad src/cpu/aarch64/vm/frame_aarch64.inline.hpp > description: > 8075930: AARCH64: Use FP Register in C2 > Summary: modify to allow C2 to allocate FP (R29) as a general register > Reviewed-by: aph, kvn, dlong > > Now this change allows C2 to allocate FP for integer only registers. It is not supposed to allow C2 to allocate FP for pointers because FP is not included in the register class no_special_ptr_reg. > > However I observe the following output from C2. > > 0x000003ff71023b6c: bl 0x000003ff700b23c0 ; OopMap{rfp=NarrowOop [0]=Oop [8]=Oop [16]=Oop [24]=Oop [32]=Oop off=432} > ;*invokevirtual accept > > So iRegINoSp() in aarch64.ad is > > // Integer 32 bit Register not Special > operand iRegINoSp() > %{ > constraint(ALLOC_IN_RC(no_special_reg32)); > match(RegI); > op_cost(0); > format %{ %} > interface(REG_INTER); > %} > > Where no_special_reg32 is just a general integer register (which includes FP). > > Now I have zero confidence that the GC stack walking code correctly unwinds FP and finds the NarrowOop therein. > > I have created a patch which creates a new register class no_special_ptrN_reg which excludes FP and used that in iRegINoSp instead. > > Patch at > > http://people.linaro.org/~edward.nevill/patches/narrowptr.patch > > I have since done 100 builds of OpenJDK without a failure. > > Is this the correct fix? Or should we try to do the stack unwinding code correctly so it finds ptrs in FP? > > Regards, > Ed. > > From adinn at redhat.com Thu Nov 5 09:25:06 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 5 Nov 2015 09:25:06 +0000 Subject: [aarch64-port-dev ] jdk8: random null pointer exceptions from javac In-Reply-To: <1446657505.6419.36.camel@mylittlepony.linaroharston> References: <1446657505.6419.36.camel@mylittlepony.linaroharston> Message-ID: <563B2072.3050505@redhat.com> On 04/11/15 17:18, Edward Nevill wrote: Ok, so let me try to summarize what you are saying to be sure I have understood correctly: 1. These changes apply to jdk8 (because the bug has been seen in jdk8). 2. You are changing the definition of the output allocation operand iRegNNoSP to use a register class which excludes rfp. 3. This stops it being treated like iRegINoSp which allows integer outputs to be generated in rfp. 4. It also puts iRegNNoSP on a par with iRegPNoSP which also uses a register class that excludes rfp. 5. And the reason for doing this is that you think the GC fails to find oops when they are saved in rfp. Is that correct? Is so then I am still unsure why this same problem does not arise on jdk9. The definition for iRegNNoSp in jdk9 uses a register class which conditionally includes rfp iff PreserveFramePointer is true. So, in jdk9 narrow oops can be stored in rfp when PreserveFramePointer is true. Why do we not see the same problem on jdk9? Is there a disparity in the GC behaviour which means this works on jdk9? Or is it just that the default for PreserveFramePointer is false so we never see the problem? regards, Andrew Dinn ----------- From edward.nevill at gmail.com Thu Nov 5 10:56:39 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 05 Nov 2015 10:56:39 +0000 Subject: [aarch64-port-dev ] jdk8: random null pointer exceptions from javac In-Reply-To: <563B2072.3050505@redhat.com> References: <1446657505.6419.36.camel@mylittlepony.linaroharston> <563B2072.3050505@redhat.com> Message-ID: <1446720999.18082.21.camel@mylittlepony.linaroharston> On Thu, 2015-11-05 at 09:25 +0000, Andrew Dinn wrote: > On 04/11/15 17:18, Edward Nevill wrote: > > 1. These changes apply to jdk8 (because the bug has been seen in jdk8). Correct. I observe it in jdk8 because that is what I use to build jdk9. > 2. You are changing the definition of the output allocation operand > iRegNNoSP to use a register class which excludes rfp. Correct. > 3. This stops it being treated like iRegINoSp which allows integer > outputs to be generated in rfp. Correct. > 4. It also puts iRegNNoSP on a par with iRegPNoSP which also uses a > register class that excludes rfp. Correct. > 5. And the reason for doing this is that you think the GC fails to find > oops when they are saved in rfp. Correct. > Is that correct? Is so then I am still unsure why this same problem does > not arise on jdk9. We do. I have just replicated it on jdk9, but only if I use -XX:+UseParallelGC, with the default G1GC it seems to work fine, as does jdk8 if you use -XX:+UseG1GC. > The definition for iRegNNoSp in jdk9 uses a register class which > conditionally includes rfp iff PreserveFramePointer is true. So, in jdk9 > narrow oops can be stored in rfp when PreserveFramePointer is true. No. PreserveFramePointer means FP must be preserved as a genuine frame pointer and is therefore not available for register allocation. > Why do we not see the same problem on jdk9? > > Is there a disparity in the GC behaviour which means this works on jdk9? Yes. Its a different GC. I only observe the problem with ParallelGC. This does not mean that the problem is not there with G1GG, it is a random, infrequent bug so it may be sitting there waiting with G1GC. All the best, Ed. From adinn at redhat.com Thu Nov 5 11:13:49 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 5 Nov 2015 11:13:49 +0000 Subject: [aarch64-port-dev ] jdk8: random null pointer exceptions from javac In-Reply-To: <1446720999.18082.21.camel@mylittlepony.linaroharston> References: <1446657505.6419.36.camel@mylittlepony.linaroharston> <563B2072.3050505@redhat.com> <1446720999.18082.21.camel@mylittlepony.linaroharston> Message-ID: <563B39ED.5040802@redhat.com> On 05/11/15 10:56, Edward Nevill wrote: > On Thu, 2015-11-05 at 09:25 +0000, Andrew Dinn wrote: >> On 04/11/15 17:18, Edward Nevill wrote: >> > . . . >> >> Is there a disparity in the GC behaviour which means this works on >> jdk9? > > Yes. Its a different GC. I only observe the problem with ParallelGC. > This does not mean that the problem is not there with G1GG, it is a > random, infrequent bug so it may be sitting there waiting with G1GC. Ok, that is all clear now. So, your patch purports to fix a symptom rather than resolve the root (oh, please!) cause. i.e. that the GC fails to scan oops saved in the frame pointer register. Much as the fix is nice to have adopting it makes it unlikely that we will find out whether (and if so, why) the GC is broken. I'd very much like to have this fix now. So perhaps we need to commit it and also raise the rfp oop checking issue with gc devs in order to see whether we can revert to using rfp for oop spills at some later date. regards, Andrew Dinn ----------- From aph at redhat.com Thu Nov 5 12:23:37 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 5 Nov 2015 12:23:37 +0000 Subject: [aarch64-port-dev ] jdk8: random null pointer exceptions from javac In-Reply-To: <563B39ED.5040802@redhat.com> References: <1446657505.6419.36.camel@mylittlepony.linaroharston> <563B2072.3050505@redhat.com> <1446720999.18082.21.camel@mylittlepony.linaroharston> <563B39ED.5040802@redhat.com> Message-ID: <563B4A49.2040502@redhat.com> On 11/05/2015 11:13 AM, Andrew Dinn wrote: > I'd very much > like to have this fix now. So perhaps we need to commit it I very strongly disagree. We must find the bug. Andrew. From hui.shi at linaro.org Thu Nov 5 13:23:42 2015 From: hui.shi at linaro.org (Hui Shi) Date: Thu, 5 Nov 2015 21:23:42 +0800 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: Message-ID: Thanks Roland! I wrote a test case and put it together with fix in http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ In hotspot/test/compiler/stable/TestStableMemoryBarrier.java, stable field?s object allocation doesn?t dominate method exit. This will trigger assertion when verify dominance. This issue doesn?t exist in current code, can be exposed when MemBarPrecedent is added for stable field write?s MemBarRelease node (with following patch). --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 12:34:27 2015 +0000 +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 15:02:31 2015 +0800 @@ -313,9 +313,8 @@ // Preserve allocation ptr to create precedent edge to it in membar // generated on exit from constructor. - if (C->eliminate_boxing() && - adr_type->isa_oopptr() && adr_type->is_oopptr()->is_ptr_to_boxed_value() && - AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { + if (AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { set_alloc_with_final(obj); } } Run with debug build on linux amd64 platform ?jtreg/bin/jtreg hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? Assertion can be reproduced. *** Use 167 isn't dominated by def 170 *** # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/loopnode.cpp:3235 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), pid=23461, tid=23513 # assert(!had_error) failed: bad dominance # # JRE version: OpenJDK Runtime Environment (9.0) (build 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) # Java VM: OpenJDK 64-Bit Server VM (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, compiled mode, tiered, compressed oops, g1 gc, linux-amd64) # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) # Unsupported internal testing APIs have been used. # An error report file with more information is saved as: # /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log Regards Shi Hui On 31 October 2015 at 00:04, Roland Westrelin wrote: > > webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ > > Thanks for re-submitting this. > So you?re fixing an existing bug in the process. Nice. We usually need a > test case for every bug fix. Can you write such a test case that triggers > that bug. test/compiler/stable has example regression test cases for > @Stable. > > Roland. > > From vladimir.x.ivanov at oracle.com Thu Nov 5 14:01:31 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 5 Nov 2015 17:01:31 +0300 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: Message-ID: <563B613B.9070701@oracle.com> Thanks for the test case! You don't need TestStableMemoryBarrier, since isStableEnabled and isServerWithStable aren't used anywere. After you eliminate it, you can use @run main/bootclasspath. For example, see [1]. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java On 11/5/15 4:23 PM, Hui Shi wrote: > Thanks Roland! > > I wrote a test case and put it together with fix in > http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ > In hotspot/test/compiler/stable/TestStableMemoryBarrier.java, stable > field?s object allocation doesn?t dominate method exit. This will > trigger assertion when verify dominance. This issue doesn?t exist in > current code, can be exposed when MemBarPrecedent is added for stable > field write?s MemBarRelease node (with following patch). > > --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 12:34:27 2015 +0000 > +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 15:02:31 2015 +0800 > @@ -313,9 +313,8 @@ > // Preserve allocation ptr to create precedent edge to it in membar > // generated on exit from constructor. > - if (C->eliminate_boxing() && > - adr_type->isa_oopptr() && > adr_type->is_oopptr()->is_ptr_to_boxed_value() && > - AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { > + if (AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { > set_alloc_with_final(obj); > } > } > > Run with debug build on linux amd64 platform ?jtreg/bin/jtreg > hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? Assertion > can be reproduced. > *** Use 167 isn't dominated by def 170 *** > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/loopnode.cpp:3235 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), > pid=23461, tid=23513 > # assert(!had_error) failed: bad dominance > # > # JRE version: OpenJDK Runtime Environment (9.0) (build > 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) > # Java VM: OpenJDK 64-Bit Server VM > (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, compiled mode, > tiered, compressed oops, g1 gc, linux-amd64) > # Core dump will be written. Default location: Core dumps may be > processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to > /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) > # > Unsupported internal testing APIs have been used. > # An error report file with more information is saved as: > # /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log > > > Regards > Shi Hui > > On 31 October 2015 at 00:04, Roland Westrelin > > wrote: > > > webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ > > Thanks for re-submitting this. > So you?re fixing an existing bug in the process. Nice. We usually > need a test case for every bug fix. Can you write such a test case > that triggers that bug. test/compiler/stable has example regression > test cases for @Stable. > > Roland. > > From edward.nevill at gmail.com Thu Nov 5 15:59:24 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 05 Nov 2015 15:59:24 +0000 Subject: [aarch64-port-dev ] jdk9: guarantee failure in javac Message-ID: <1446739164.23752.15.camel@mylittlepony.linaroharston> Hi, I am seeing the following guarantee failure with jdk9 javac. # Internal Error (assembler_aarch64.hpp:223), pid=42005, tid=1827 # guarantee(chk == -1 || chk == 0) failed: Field too big for insn I have trapped this in gdb and the problem is that an adrp to the byte map base is becoming out of range when the code buffer is being relocated. Here is a snapshot from gdb #5 0x000003ffb5fbefbc in MacroAssembler::pd_patch_instruction_size ( branch=0x3ffa664b088 "\353\251\200\220`\001\n\213\n", target=0x3fea6600000 "") at /home/ed/new_jdk9/dev/hotspot/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp:137 137 Instruction_aarch64::spatch(branch, 23, 5, offset); (gdb) list 132 assert(offset_lo == 0, "offset must be 0 for polling page or byte map base"); 133 } 134 } 135 int offset_lo = offset & 3; 136 offset >>= 2; 137 Instruction_aarch64::spatch(branch, 23, 5, offset); 138 Instruction_aarch64::patch(branch, 30, 29, offset_lo); 139 } else if (Instruction_aarch64::extract(insn, 31, 21) == 0b11010010100) { 140 u_int64_t dest = (u_int64_t)target; 141 // Move wide constant (gdb) p/x branch $27 = 0x3ffa664b088 (gdb) x/10i 0x3ffa664b088-20 0x3ffa664b074: ldr w24, [x26,#16] 0x3ffa664b078: sxtb w29, w21 0x3ffa664b07c: str w13, [x22,#16] 0x3ffa664b080: cbz x10, 0x3ffa664b100 0x3ffa664b084: lsr x10, x11, #9 0x3ffa664b088: adrp x11, 0x3fea7b87000 <<<< Instruction being patched 0x3ffa664b08c: add x0, x11, x10 0x3ffa664b090: ldrsb w10, [x0] 0x3ffa664b094: cmp w10, #0x20 0x3ffa664b098: b.eq 0x3ffa664b100 (gdb) p/x target <<<< Byte map base $28 = 0x3fea6600000 (gdb) p/x 0x3ffa664b088-0x3fea6600000 $29 = 0x10004b088 <<<<< Offset > 4G So, how do we address this? 1) Use lea, but that is 3 instructions (movz, movk, movk) 2) Allocate a permanent register for byte map base 3) Something else? I am leaning towards 2. We have plenty of callee save registers. And do we need to do the same thing with the polling page? Thanks for your help, Ed. From hui.shi at linaro.org Sun Nov 8 14:12:57 2015 From: hui.shi at linaro.org (Hui Shi) Date: Sun, 8 Nov 2015 22:12:57 +0800 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: <563B613B.9070701@oracle.com> References: <563B613B.9070701@oracle.com> Message-ID: Thanks Vladimir! Yes, isStableEnabled and isServerWithStable variable can be deleted from test case. New patch in http://cr.openjdk.java.net/~hshi/8139758/webrev_v4/ Keep "othervm" in tag same with other StableTest and use @run main/othervm/bootclasspath Regards Shi Hui On 5 November 2015 at 22:01, Vladimir Ivanov wrote: > Thanks for the test case! > > You don't need TestStableMemoryBarrier, since isStableEnabled and > isServerWithStable aren't used anywere. > > After you eliminate it, you can use @run main/bootclasspath. For example, > see [1]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java > > > On 11/5/15 4:23 PM, Hui Shi wrote: > >> Thanks Roland! >> >> I wrote a test case and put it together with fix in >> http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ >> In hotspot/test/compiler/stable/TestStableMemoryBarrier.java, stable >> field?s object allocation doesn?t dominate method exit. This will >> trigger assertion when verify dominance. This issue doesn?t exist in >> current code, can be exposed when MemBarPrecedent is added for stable >> field write?s MemBarRelease node (with following patch). >> >> --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 12:34:27 2015 +0000 >> +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 15:02:31 2015 +0800 >> @@ -313,9 +313,8 @@ >> // Preserve allocation ptr to create precedent edge to it in membar >> // generated on exit from constructor. >> - if (C->eliminate_boxing() && >> - adr_type->isa_oopptr() && >> adr_type->is_oopptr()->is_ptr_to_boxed_value() && >> - AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { >> + if (AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { >> set_alloc_with_final(obj); >> } >> } >> >> Run with debug build on linux amd64 platform ?jtreg/bin/jtreg >> hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? Assertion >> can be reproduced. >> *** Use 167 isn't dominated by def 170 *** >> # To suppress the following error report, specify this argument >> # after -XX: or in .hotspotrc: SuppressErrorAt=/loopnode.cpp:3235 >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error >> >> (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), >> pid=23461, tid=23513 >> # assert(!had_error) failed: bad dominance >> # >> # JRE version: OpenJDK Runtime Environment (9.0) (build >> 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) >> # Java VM: OpenJDK 64-Bit Server VM >> (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, compiled mode, >> tiered, compressed oops, g1 gc, linux-amd64) >> # Core dump will be written. Default location: Core dumps may be >> processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to >> /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) >> # >> Unsupported internal testing APIs have been used. >> # An error report file with more information is saved as: >> # /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log >> >> >> Regards >> Shi Hui >> >> On 31 October 2015 at 00:04, Roland Westrelin >> > wrote: >> >> > webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ >> >> Thanks for re-submitting this. >> So you?re fixing an existing bug in the process. Nice. We usually >> need a test case for every bug fix. Can you write such a test case >> that triggers that bug. test/compiler/stable has example regression >> test cases for @Stable. >> >> Roland. >> >> >> From gil at azul.com Mon Nov 9 02:39:50 2015 From: gil at azul.com (Gil Tene) Date: Mon, 9 Nov 2015 02:39:50 +0000 Subject: [aarch64-port-dev ] Project proposal: AArch32 port In-Reply-To: <1446541917.18905.12.camel@mylittlepony.linaroharston> References: <1444830648.7802.34.camel@mylittlepony.linaroharston> <5628A5D2.40909@oracle.com> <1445518014.29998.4.camel@mylittlepony.linaroharston> <562A2DBB.9000404@oracle.com> <1445607702.28722.19.camel@mint> <1446040701.26259.11.camel@gmx.com> <1446541917.18905.12.camel@mylittlepony.linaroharston> Message-ID: I'd like to voice both my own and Azul's enthusiastic support for this new aarch32 project. We will be happy to participate and contribute code & resources, including multiple additional committers. ? Gil. > On Nov 3, 2015, at 1:11 AM, Edward Nevill wrote: > > On Wed, 2015-10-28 at 13:58 +0000, Joseph Joyce wrote: >> Hi Ed and Dalibor, >> >> There's no code in there from other open source projects. As far as I >> can remember the only code from elsewhere was an algorithm for >> division, which came from >> http://www.chiark.greenend.org.uk/~theom/riscos/docs/ultimate/a252div.txt >> The code was modified a bit to work for the assembler, the url from >> which it came is mentioned in the source (MacroAssembler::divide32). If >> this is a problem I can easily replace the code with a call out to a C >> (or Ed suggested using the algorithm from the ARM32-Microjit). >> >> I have now signed and sent the OCA (today) and would like to continue >> contributing to this project. If I could be added to the committers that >> would be great. > > Hi Joseph, > > That's great news. I therefore propose Joseph Joyce as an additional > committer for the aarch32 project. > > I have had a look at the divide routine in the template interpreter and > the original by Graeme Williams. I do not believe this should be an > issue as your implementation of the algorithm is completely different. > For a start yours is written in C calling the MacroAssembler methods to > generate the code, whereas his is written in some sort of BASIC > assembler. So although the algorithm is the same the implementation is > different and AIUI it is the implementation that is copyrighted. > > Dalibor: If you are happy with this may I proceed to a CFV for the > aarch32 project. > > Thanks, > Ed. > > From edward.nevill at gmail.com Tue Nov 10 10:42:47 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 10 Nov 2015 10:42:47 +0000 Subject: [aarch64-port-dev ] CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <563B6C9B.4070900@redhat.com> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> <563B290B.6040703@redhat.com> <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> <563B6C9B.4070900@redhat.com> Message-ID: <1447152167.14377.24.camel@mylittlepony.linaroharston> On Thu, 2015-11-05 at 14:50 +0000, Andrew Haley wrote: > On 11/05/2015 01:25 PM, Bob Vandette wrote: > > This eliminates the possibility of using the Hotspot JIT (Just-in- > > time compiler) but since the Hotspot template interpreter is also > > dynamically generated, we can?t use that form of the interpreter. > > We have enhanced our closed ARM ports to statically generate the > > interpreter for iOS but since these sources are not available in the > > open source forest, we?ll use Zero initially to provide a working > > solution for the Mobile project. I welcome the maintainers of the > > open aarch64 port to enhance that port to enable static code > > generation of your interpreter so that we won?t have to use Zero. > > The shared code changes required for static code generation has > > already been integrated into the JDK9 master sources. > > OK, thanks. It's definitely worth us having a look at that. One possibility would be to use a JIT (C1, C2 or the ARM microJIT) to compile to some intermediate representation which would be more amenable to interpretation. I am thinking of an intermediate representation where each opcode/operand pair is 128 bits and the dispatch code is simply. ldp Ropcode, Roperand, [Rpc], #16 br Ropcode IE. The opecode is simply the address of a static routine to handle that opcode. So, for example you code fold the sequence iload N iload M iadd istore O to a single opcode &iadd_three_op where and are encoded in the 2nd 64 bit word. If you further allowed for some simple register allocation (as per the ARM microJIT) with 4 registers assigned to the top 4 stack locations and 4 registers assigned to 4 locals (probably, but not necessarily local_0 to local_3) then the above sequence could be reduced to &iadd_O_M_N IE there would be a dedicated opcode for oadd O, M, N which simply does mov Ropcode, Roperand ; no operand, so operand becomes next opcode ldr Roperand, [Rpc], #8 add RO, RM, RN ; do the op br Ropcode I think it would be possible to get quite good performance using this technique, especially if you could statically compile longer code sequences based on profiling information. All the best, Ed. From aph at redhat.com Tue Nov 10 18:28:17 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 10 Nov 2015 18:28:17 +0000 Subject: [aarch64-port-dev ] CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <1447152167.14377.24.camel@mylittlepony.linaroharston> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> <563B290B.6040703@redhat.com> <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> <563B6C9B.4070900@redhat.com> <1447152167.14377.24.camel@mylittlepony.linaroharston> Message-ID: <56423741.3090104@redhat.com> On 10/11/15 10:42, Edward Nevill wrote: > On Thu, 2015-11-05 at 14:50 +0000, Andrew Haley wrote: >> On 11/05/2015 01:25 PM, Bob Vandette wrote: >>> This eliminates the possibility of using the Hotspot JIT (Just-in- >>> time compiler) but since the Hotspot template interpreter is also >>> dynamically generated, we can?t use that form of the interpreter. >>> We have enhanced our closed ARM ports to statically generate the >>> interpreter for iOS but since these sources are not available in the >>> open source forest, we?ll use Zero initially to provide a working >>> solution for the Mobile project. I welcome the maintainers of the >>> open aarch64 port to enhance that port to enable static code >>> generation of your interpreter so that we won?t have to use Zero. >>> The shared code changes required for static code generation has >>> already been integrated into the JDK9 master sources. >> >> OK, thanks. It's definitely worth us having a look at that. > > One possibility would be to use a JIT (C1, C2 or the ARM microJIT) to > compile to some intermediate representation which would be more amenable > to interpretation. > > I am thinking of an intermediate representation where each > opcode/operand pair is 128 bits and the dispatch code is simply. > > ldp Ropcode, Roperand, [Rpc], #16 > br Ropcode > > IE. The opecode is simply the address of a static routine to handle that > opcode. i.e. direct threaded code. > I think it would be possible to get quite good performance using this > technique, especially if you could statically compile longer code > sequences based on profiling information. Maybe, but I suspect it would be easier to write a JIT (C1 or C2) back-end for this machine. I expect that the real problem performance-wise would be that you'd blow out the Dcache. Andrew. From bob.vandette at oracle.com Tue Nov 10 20:35:14 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 10 Nov 2015 15:35:14 -0500 Subject: [aarch64-port-dev ] CFV: New Project: Mobile: JDK Ports to Modern Mobile Platforms In-Reply-To: <1447152167.14377.24.camel@mylittlepony.linaroharston> References: <20150929164407.GI3157@redhat.com> <5F00A8A5-A66D-4739-AE9F-AB3BE96C22AC@oracle.com> <563B290B.6040703@redhat.com> <69AD961F-A252-42A9-86F7-8E0ACBB264DE@oracle.com> <563B6C9B.4070900@redhat.com> <1447152167.14377.24.camel@mylittlepony.linaroharston> Message-ID: > On Nov 10, 2015, at 5:42 AM, Edward Nevill wrote: > > On Thu, 2015-11-05 at 14:50 +0000, Andrew Haley wrote: >> On 11/05/2015 01:25 PM, Bob Vandette wrote: >>> This eliminates the possibility of using the Hotspot JIT (Just-in- >>> time compiler) but since the Hotspot template interpreter is also >>> dynamically generated, we can?t use that form of the interpreter. >>> We have enhanced our closed ARM ports to statically generate the >>> interpreter for iOS but since these sources are not available in the >>> open source forest, we?ll use Zero initially to provide a working >>> solution for the Mobile project. I welcome the maintainers of the >>> open aarch64 port to enhance that port to enable static code >>> generation of your interpreter so that we won?t have to use Zero. >>> The shared code changes required for static code generation has >>> already been integrated into the JDK9 master sources. >> >> OK, thanks. It's definitely worth us having a look at that. This sounds a bit like RewriteByteCodes and RewriteFrequentParis taken to the extreem. This would be a useful general Hotspot enhancement if it weren?t for the fact that interpreter performance matters less and less each day. With TieredCompilation and the our eventual AOT implementation, we?ll be spending less time interpreting. As a performance improvement for iOS it might be worth doing on it?s own but if we were to implement something like this, why not go straight to Ahead-of-time compilation that leverages existing JITs. You have to be careful what you compile but you can get a nice performance improvement with very little code generation. Bob. > > One possibility would be to use a JIT (C1, C2 or the ARM microJIT) to > compile to some intermediate representation which would be more amenable > to interpretation. > > I am thinking of an intermediate representation where each > opcode/operand pair is 128 bits and the dispatch code is simply. > > ldp Ropcode, Roperand, [Rpc], #16 > br Ropcode > > IE. The opecode is simply the address of a static routine to handle that > opcode. > > So, for example you code fold the sequence > > iload N > iload M > iadd > istore O > > to a single opcode > > &iadd_three_op > > where and are encoded in the 2nd 64 bit word. > > If you further allowed for some simple register allocation (as per the > ARM microJIT) with 4 registers assigned to the top 4 stack locations and > 4 registers assigned to 4 locals (probably, but not necessarily local_0 > to local_3) then the above sequence could be reduced to > > &iadd_O_M_N > > IE there would be a dedicated opcode for oadd O, M, N which simply does > > mov Ropcode, Roperand ; no operand, so operand becomes next opcode > ldr Roperand, [Rpc], #8 > add RO, RM, RN ; do the op > br Ropcode > > I think it would be possible to get quite good performance using this > technique, especially if you could statically compile longer code > sequences based on profiling information. > > All the best, > Ed. > > From hui.shi at linaro.org Fri Nov 13 13:53:11 2015 From: hui.shi at linaro.org (Hui Shi) Date: Fri, 13 Nov 2015 21:53:11 +0800 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <563B613B.9070701@oracle.com> Message-ID: Would some one help review this patch? Regards Hui On 8 November 2015 at 22:12, Hui Shi wrote: > Thanks Vladimir! > > Yes, isStableEnabled and isServerWithStable variable can be deleted from > test case. > > New patch in http://cr.openjdk.java.net/~hshi/8139758/webrev_v4/ > > Keep "othervm" in tag same with other StableTest and use @run > main/othervm/bootclasspath > > Regards > Shi Hui > > On 5 November 2015 at 22:01, Vladimir Ivanov > wrote: > >> Thanks for the test case! >> >> You don't need TestStableMemoryBarrier, since isStableEnabled and >> isServerWithStable aren't used anywere. >> >> After you eliminate it, you can use @run main/bootclasspath. For example, >> see [1]. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java >> >> >> On 11/5/15 4:23 PM, Hui Shi wrote: >> >>> Thanks Roland! >>> >>> I wrote a test case and put it together with fix in >>> http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ >>> In hotspot/test/compiler/stable/TestStableMemoryBarrier.java, stable >>> field?s object allocation doesn?t dominate method exit. This will >>> trigger assertion when verify dominance. This issue doesn?t exist in >>> current code, can be exposed when MemBarPrecedent is added for stable >>> field write?s MemBarRelease node (with following patch). >>> >>> --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 12:34:27 2015 +0000 >>> +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 15:02:31 2015 +0800 >>> @@ -313,9 +313,8 @@ >>> // Preserve allocation ptr to create precedent edge to it in membar >>> // generated on exit from constructor. >>> - if (C->eliminate_boxing() && >>> - adr_type->isa_oopptr() && >>> adr_type->is_oopptr()->is_ptr_to_boxed_value() && >>> - AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { >>> + if (AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { >>> set_alloc_with_final(obj); >>> } >>> } >>> >>> Run with debug build on linux amd64 platform ?jtreg/bin/jtreg >>> hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? Assertion >>> can be reproduced. >>> *** Use 167 isn't dominated by def 170 *** >>> # To suppress the following error report, specify this argument >>> # after -XX: or in .hotspotrc: SuppressErrorAt=/loopnode.cpp:3235 >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error >>> >>> (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), >>> pid=23461, tid=23513 >>> # assert(!had_error) failed: bad dominance >>> # >>> # JRE version: OpenJDK Runtime Environment (9.0) (build >>> 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) >>> # Java VM: OpenJDK 64-Bit Server VM >>> (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, compiled mode, >>> tiered, compressed oops, g1 gc, linux-amd64) >>> # Core dump will be written. Default location: Core dumps may be >>> processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to >>> /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) >>> # >>> Unsupported internal testing APIs have been used. >>> # An error report file with more information is saved as: >>> # /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log >>> >>> >>> Regards >>> Shi Hui >>> >>> On 31 October 2015 at 00:04, Roland Westrelin >>> > >>> wrote: >>> >>> > webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ >>> >>> Thanks for re-submitting this. >>> So you?re fixing an existing bug in the process. Nice. We usually >>> need a test case for every bug fix. Can you write such a test case >>> that triggers that bug. test/compiler/stable has example regression >>> test cases for @Stable. >>> >>> Roland. >>> >>> >>> > From roland.westrelin at oracle.com Fri Nov 13 13:56:09 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 13 Nov 2015 14:56:09 +0100 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <563B613B.9070701@oracle.com> Message-ID: <270B4FC1-1ECD-44F5-A6C8-6AAEECD5D681@oracle.com> > Would some one help review this patch? Sorry Hui, forgot about that one. That looks good to me. I will have it go through testing and if it looks good I?ll push it (I?ll maybe tweak the comments a bit). Roland. > > Regards > Hui > > On 8 November 2015 at 22:12, Hui Shi wrote: > Thanks Vladimir! > > Yes, isStableEnabled and isServerWithStable variable can be deleted from test case. > > New patch in http://cr.openjdk.java.net/~hshi/8139758/webrev_v4/ > > Keep "othervm" in tag same with other StableTest and use @run main/othervm/bootclasspath > > Regards > Shi Hui > > On 5 November 2015 at 22:01, Vladimir Ivanov wrote: > Thanks for the test case! > > You don't need TestStableMemoryBarrier, since isStableEnabled and isServerWithStable aren't used anywere. > > After you eliminate it, you can use @run main/bootclasspath. For example, see [1]. > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java > > > On 11/5/15 4:23 PM, Hui Shi wrote: > Thanks Roland! > > I wrote a test case and put it together with fix in > http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ > In hotspot/test/compiler/stable/TestStableMemoryBarrier.java, stable > field?s object allocation doesn?t dominate method exit. This will > trigger assertion when verify dominance. This issue doesn?t exist in > current code, can be exposed when MemBarPrecedent is added for stable > field write?s MemBarRelease node (with following patch). > > --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 12:34:27 2015 +0000 > +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 15:02:31 2015 +0800 > @@ -313,9 +313,8 @@ > // Preserve allocation ptr to create precedent edge to it in membar > // generated on exit from constructor. > - if (C->eliminate_boxing() && > - adr_type->isa_oopptr() && > adr_type->is_oopptr()->is_ptr_to_boxed_value() && > - AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { > + if (AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { > set_alloc_with_final(obj); > } > } > > Run with debug build on linux amd64 platform ?jtreg/bin/jtreg > hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? Assertion > can be reproduced. > *** Use 167 isn't dominated by def 170 *** > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/loopnode.cpp:3235 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), > pid=23461, tid=23513 > # assert(!had_error) failed: bad dominance > # > # JRE version: OpenJDK Runtime Environment (9.0) (build > 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) > # Java VM: OpenJDK 64-Bit Server VM > (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, compiled mode, > tiered, compressed oops, g1 gc, linux-amd64) > # Core dump will be written. Default location: Core dumps may be > processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to > /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) > # > Unsupported internal testing APIs have been used. > # An error report file with more information is saved as: > # /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log > > > Regards > Shi Hui > > On 31 October 2015 at 00:04, Roland Westrelin > > wrote: > > > webrev: http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ > > Thanks for re-submitting this. > So you?re fixing an existing bug in the process. Nice. We usually > need a test case for every bug fix. Can you write such a test case > that triggers that bug. test/compiler/stable has example regression > test cases for @Stable. > > Roland. > > > > From vladimir.x.ivanov at oracle.com Fri Nov 13 14:22:42 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 13 Nov 2015 17:22:42 +0300 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <563B613B.9070701@oracle.com> Message-ID: <5645F232.1040608@oracle.com> Sorry, Hui. I planned to write you, but bogged down in other activities. I suggest to do some additional cleanups in the test. After you switch to bootclasspath these lines shouldn't be needed: 31 * @run main ClassFileInstaller 32 * java/lang/invoke/TestStableMemoryBarrier 33 * java/lang/invoke/TestStableMemoryBarrier$NotDominate Also, othervm is redundant for bootclasspath: 35 * @run main/othervm/bootclasspath -Xcomp -XX:CompileOnly=::testCompile 36 * java.lang.invoke.TestStableMemoryBarrier Best regards, Vladimir Ivanov On 11/13/15 4:53 PM, Hui Shi wrote: > Would some one help review this patch? > > Regards > Hui > > On 8 November 2015 at 22:12, Hui Shi > wrote: > > Thanks Vladimir! > > Yes, isStableEnabled and isServerWithStable variable can be deleted > from test case. > > New patch in http://cr.openjdk.java.net/~hshi/8139758/webrev_v4/ > > Keep "othervm" in tag same with other StableTest and use @run > main/othervm/bootclasspath > > Regards > Shi Hui > > On 5 November 2015 at 22:01, Vladimir Ivanov > > > wrote: > > Thanks for the test case! > > You don't need TestStableMemoryBarrier, since isStableEnabled > and isServerWithStable aren't used anywere. > > After you eliminate it, you can use @run main/bootclasspath. For > example, see [1]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java > > > On 11/5/15 4:23 PM, Hui Shi wrote: > > Thanks Roland! > > I wrote a test case and put it together with fix in > http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ > In > hotspot/test/compiler/stable/TestStableMemoryBarrier.java, > stable > field?s object allocation doesn?t dominate method exit. This > will > trigger assertion when verify dominance. This issue doesn?t > exist in > current code, can be exposed when MemBarPrecedent is added > for stable > field write?s MemBarRelease node (with following patch). > > --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 12:34:27 > 2015 +0000 > +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 15:02:31 > 2015 +0800 > @@ -313,9 +313,8 @@ > // Preserve allocation ptr to create precedent edge > to it in membar > // generated on exit from constructor. > - if (C->eliminate_boxing() && > - adr_type->isa_oopptr() && > adr_type->is_oopptr()->is_ptr_to_boxed_value() && > - AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { > + if (AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { > set_alloc_with_final(obj); > } > } > > Run with debug build on linux amd64 platform ?jtreg/bin/jtreg > hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? > Assertion > can be reproduced. > *** Use 167 isn't dominated by def 170 *** > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: > SuppressErrorAt=/loopnode.cpp:3235 > # > # A fatal error has been detected by the Java Runtime > Environment: > # > # Internal Error > (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), > pid=23461, tid=23513 > # assert(!had_error) failed: bad dominance > # > # JRE version: OpenJDK Runtime Environment (9.0) (build > 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) > # Java VM: OpenJDK 64-Bit Server VM > (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, compiled > mode, > tiered, compressed oops, g1 gc, linux-amd64) > # Core dump will be written. Default location: Core dumps may be > processed with "/usr/share/apport/apport %p %s %c %P" (or > dumping to > /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) > # > Unsupported internal testing APIs have been used. > # An error report file with more information is saved as: > # > /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log > > > Regards > Shi Hui > > On 31 October 2015 at 00:04, Roland Westrelin > > >> wrote: > > > webrev: > http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ > > Thanks for re-submitting this. > So you?re fixing an existing bug in the process. Nice. > We usually > need a test case for every bug fix. Can you write such > a test case > that triggers that bug. test/compiler/stable has > example regression > test cases for @Stable. > > Roland. > > > > From hui.shi at linaro.org Fri Nov 13 15:30:54 2015 From: hui.shi at linaro.org (Hui Shi) Date: Fri, 13 Nov 2015 23:30:54 +0800 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: <5645F232.1040608@oracle.com> References: <563B613B.9070701@oracle.com> <5645F232.1040608@oracle.com> Message-ID: Thanks Vladimir & Roland! Test is cleaned up and new patch in http://cr.openjdk.java.net/~hshi/8139758/webrev_v5/ BTW, What is the advantage to write test in "@run main/bootclasspath" form? There still some tests written as "@run main/othervm -Xbootclasspath/a:." under hotspot/test. Regards Hui On 13 November 2015 at 22:22, Vladimir Ivanov wrote: > Sorry, Hui. I planned to write you, but bogged down in other activities. > > I suggest to do some additional cleanups in the test. > > After you switch to bootclasspath these lines shouldn't be needed: > 31 * @run main ClassFileInstaller > 32 * java/lang/invoke/TestStableMemoryBarrier > 33 * java/lang/invoke/TestStableMemoryBarrier$NotDominate > > Also, othervm is redundant for bootclasspath: > 35 * @run main/othervm/bootclasspath -Xcomp > -XX:CompileOnly=::testCompile > 36 * java.lang.invoke.TestStableMemoryBarrier > > Best regards, > Vladimir Ivanov > > On 11/13/15 4:53 PM, Hui Shi wrote: > >> Would some one help review this patch? >> >> Regards >> Hui >> >> On 8 November 2015 at 22:12, Hui Shi > > wrote: >> >> Thanks Vladimir! >> >> Yes, isStableEnabled and isServerWithStable variable can be deleted >> from test case. >> >> New patch in http://cr.openjdk.java.net/~hshi/8139758/webrev_v4/ >> >> Keep "othervm" in tag same with other StableTest and use @run >> main/othervm/bootclasspath >> >> Regards >> Shi Hui >> >> On 5 November 2015 at 22:01, Vladimir Ivanov >> > >> >> wrote: >> >> Thanks for the test case! >> >> You don't need TestStableMemoryBarrier, since isStableEnabled >> and isServerWithStable aren't used anywere. >> >> After you eliminate it, you can use @run main/bootclasspath. For >> example, see [1]. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java >> >> >> On 11/5/15 4:23 PM, Hui Shi wrote: >> >> Thanks Roland! >> >> I wrote a test case and put it together with fix in >> http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ >> In >> hotspot/test/compiler/stable/TestStableMemoryBarrier.java, >> stable >> field?s object allocation doesn?t dominate method exit. This >> will >> trigger assertion when verify dominance. This issue doesn?t >> exist in >> current code, can be exposed when MemBarPrecedent is added >> for stable >> field write?s MemBarRelease node (with following patch). >> >> --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 12:34:27 >> 2015 +0000 >> +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 15:02:31 >> 2015 +0800 >> @@ -313,9 +313,8 @@ >> // Preserve allocation ptr to create precedent edge >> to it in membar >> // generated on exit from constructor. >> - if (C->eliminate_boxing() && >> - adr_type->isa_oopptr() && >> adr_type->is_oopptr()->is_ptr_to_boxed_value() && >> - AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { >> + if (AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) { >> set_alloc_with_final(obj); >> } >> } >> >> Run with debug build on linux amd64 platform ?jtreg/bin/jtreg >> hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? >> Assertion >> can be reproduced. >> *** Use 167 isn't dominated by def 170 *** >> # To suppress the following error report, specify this >> argument >> # after -XX: or in .hotspotrc: >> SuppressErrorAt=/loopnode.cpp:3235 >> # >> # A fatal error has been detected by the Java Runtime >> Environment: >> # >> # Internal Error >> >> (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), >> pid=23461, tid=23513 >> # assert(!had_error) failed: bad dominance >> # >> # JRE version: OpenJDK Runtime Environment (9.0) (build >> 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) >> # Java VM: OpenJDK 64-Bit Server VM >> (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, compiled >> mode, >> tiered, compressed oops, g1 gc, linux-amd64) >> # Core dump will be written. Default location: Core dumps may >> be >> processed with "/usr/share/apport/apport %p %s %c %P" (or >> dumping to >> /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) >> # >> Unsupported internal testing APIs have been used. >> # An error report file with more information is saved as: >> # >> >> /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log >> >> >> Regards >> Shi Hui >> >> On 31 October 2015 at 00:04, Roland Westrelin >> > >> > >> wrote: >> >> > webrev: >> http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ >> >> Thanks for re-submitting this. >> So you?re fixing an existing bug in the process. Nice. >> We usually >> need a test case for every bug fix. Can you write such >> a test case >> that triggers that bug. test/compiler/stable has >> example regression >> test cases for @Stable. >> >> Roland. >> >> >> >> >> From vladimir.x.ivanov at oracle.com Fri Nov 13 20:37:58 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 13 Nov 2015 23:37:58 +0300 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: References: <563B613B.9070701@oracle.com> <5645F232.1040608@oracle.com> Message-ID: <56464A26.5090800@oracle.com> On 11/13/15 6:30 PM, Hui Shi wrote: > Thanks Vladimir & Roland! > > Test is cleaned up and new patch in > http://cr.openjdk.java.net/~hshi/8139758/webrev_v5/ Looks good. I think "@build TestStableMemoryBarrier" is redundant (sorry for not noticing that before), but no need to send new webrev for that. > BTW, What is the advantage to write test in "@runmain/bootclasspath" > form? There still some tests written as "@run > main/othervm -Xbootclasspath/a:." under hotspot/test. As I remember, @run bootclasspath works only if the test resides in a single source file. If there are multiple Java sources involved, you have to use @build + ClassFileInstall + @run /othervm -Xbootclasspath/a. Best regards, Vladimir Ivanov > > Regards > Hui > > On 13 November 2015 at 22:22, Vladimir Ivanov > > wrote: > > Sorry, Hui. I planned to write you, but bogged down in other activities. > > I suggest to do some additional cleanups in the test. > > After you switch to bootclasspath these lines shouldn't be needed: > 31 * @run main ClassFileInstaller > 32 * java/lang/invoke/TestStableMemoryBarrier > 33 * java/lang/invoke/TestStableMemoryBarrier$NotDominate > > Also, othervm is redundant for bootclasspath: > 35 * @run main/othervm/bootclasspath -Xcomp > -XX:CompileOnly=::testCompile > 36 * java.lang.invoke.TestStableMemoryBarrier > > Best regards, > Vladimir Ivanov > > On 11/13/15 4:53 PM, Hui Shi wrote: > > Would some one help review this patch? > > Regards > Hui > > On 8 November 2015 at 22:12, Hui Shi > >> wrote: > > Thanks Vladimir! > > Yes, isStableEnabled and isServerWithStable variable can be > deleted > from test case. > > New patch in > http://cr.openjdk.java.net/~hshi/8139758/webrev_v4/ > > Keep "othervm" in tag same with other StableTest and use @run > main/othervm/bootclasspath > > Regards > Shi Hui > > On 5 November 2015 at 22:01, Vladimir Ivanov > > >> > > wrote: > > Thanks for the test case! > > You don't need TestStableMemoryBarrier, since > isStableEnabled > and isServerWithStable aren't used anywere. > > After you eliminate it, you can use @run > main/bootclasspath. For > example, see [1]. > > Best regards, > Vladimir Ivanov > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java > > > On 11/5/15 4:23 PM, Hui Shi wrote: > > Thanks Roland! > > I wrote a test case and put it together with fix in > http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ > In > > hotspot/test/compiler/stable/TestStableMemoryBarrier.java, > stable > field?s object allocation doesn?t dominate method > exit. This > will > trigger assertion when verify dominance. This issue > doesn?t > exist in > current code, can be exposed when MemBarPrecedent > is added > for stable > field write?s MemBarRelease node (with following > patch). > > --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 > 12:34:27 > 2015 +0000 > +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 > 15:02:31 > 2015 +0800 > @@ -313,9 +313,8 @@ > // Preserve allocation ptr to create > precedent edge > to it in membar > // generated on exit from constructor. > - if (C->eliminate_boxing() && > - adr_type->isa_oopptr() && > adr_type->is_oopptr()->is_ptr_to_boxed_value() && > - AllocateNode::Ideal_allocation(obj, &_gvn) > != NULL) { > + if (AllocateNode::Ideal_allocation(obj, &_gvn) > != NULL) { > set_alloc_with_final(obj); > } > } > > Run with debug build on linux amd64 platform > ?jtreg/bin/jtreg > > hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? > Assertion > can be reproduced. > *** Use 167 isn't dominated by def 170 *** > # To suppress the following error report, specify > this argument > # after -XX: or in .hotspotrc: > SuppressErrorAt=/loopnode.cpp:3235 > # > # A fatal error has been detected by the Java Runtime > Environment: > # > # Internal Error > > (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), > pid=23461, tid=23513 > # assert(!had_error) failed: bad dominance > # > # JRE version: OpenJDK Runtime Environment (9.0) (build > 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) > # Java VM: OpenJDK 64-Bit Server VM > (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, > compiled > mode, > tiered, compressed oops, g1 gc, linux-amd64) > # Core dump will be written. Default location: Core > dumps may be > processed with "/usr/share/apport/apport %p %s %c > %P" (or > dumping to > > /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) > # > Unsupported internal testing APIs have been used. > # An error report file with more information is > saved as: > # > > /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log > > > Regards > Shi Hui > > On 31 October 2015 at 00:04, Roland Westrelin > > > > > >>> wrote: > > > webrev: > http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ > > Thanks for re-submitting this. > So you?re fixing an existing bug in the > process. Nice. > We usually > need a test case for every bug fix. Can you > write such > a test case > that triggers that bug. test/compiler/stable has > example regression > test cases for @Stable. > > Roland. > > > > > From hui.shi at linaro.org Sat Nov 14 08:17:32 2015 From: hui.shi at linaro.org (Hui Shi) Date: Sat, 14 Nov 2015 16:17:32 +0800 Subject: [aarch64-port-dev ] [REDO] Elide more final field's write memory barrier with escape analysis result In-Reply-To: <56464A26.5090800@oracle.com> References: <563B613B.9070701@oracle.com> <5645F232.1040608@oracle.com> <56464A26.5090800@oracle.com> Message-ID: Thanks! Regards Hui On 14 November 2015 at 04:37, Vladimir Ivanov wrote: > > > On 11/13/15 6:30 PM, Hui Shi wrote: > >> Thanks Vladimir & Roland! >> >> Test is cleaned up and new patch in >> http://cr.openjdk.java.net/~hshi/8139758/webrev_v5/ >> > Looks good. > > I think "@build TestStableMemoryBarrier" is redundant (sorry for not > noticing that before), but no need to send new webrev for that. > > BTW, What is the advantage to write test in "@runmain/bootclasspath" >> form? There still some tests written as "@run >> main/othervm -Xbootclasspath/a:." under hotspot/test. >> > As I remember, @run bootclasspath works only if the test resides in a > single source file. If there are multiple Java sources involved, you have > to use @build + ClassFileInstall + @run /othervm -Xbootclasspath/a. > > Best regards, > Vladimir Ivanov > > >> Regards >> Hui >> >> On 13 November 2015 at 22:22, Vladimir Ivanov >> > >> wrote: >> >> Sorry, Hui. I planned to write you, but bogged down in other >> activities. >> >> I suggest to do some additional cleanups in the test. >> >> After you switch to bootclasspath these lines shouldn't be needed: >> 31 * @run main ClassFileInstaller >> 32 * java/lang/invoke/TestStableMemoryBarrier >> 33 * >> java/lang/invoke/TestStableMemoryBarrier$NotDominate >> >> Also, othervm is redundant for bootclasspath: >> 35 * @run main/othervm/bootclasspath -Xcomp >> -XX:CompileOnly=::testCompile >> 36 * java.lang.invoke.TestStableMemoryBarrier >> >> Best regards, >> Vladimir Ivanov >> >> On 11/13/15 4:53 PM, Hui Shi wrote: >> >> Would some one help review this patch? >> >> Regards >> Hui >> >> On 8 November 2015 at 22:12, Hui Shi > >> >> wrote: >> >> Thanks Vladimir! >> >> Yes, isStableEnabled and isServerWithStable variable can be >> deleted >> from test case. >> >> New patch in >> http://cr.openjdk.java.net/~hshi/8139758/webrev_v4/ >> >> Keep "othervm" in tag same with other StableTest and use @run >> main/othervm/bootclasspath >> >> Regards >> Shi Hui >> >> On 5 November 2015 at 22:01, Vladimir Ivanov >> > >> > >> >> >> >> wrote: >> >> Thanks for the test case! >> >> You don't need TestStableMemoryBarrier, since >> isStableEnabled >> and isServerWithStable aren't used anywere. >> >> After you eliminate it, you can use @run >> main/bootclasspath. For >> example, see [1]. >> >> Best regards, >> Vladimir Ivanov >> >> [1] >> >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/tip/test/compiler/unsafe/UnsafeGetConstantField.java >> >> >> On 11/5/15 4:23 PM, Hui Shi wrote: >> >> Thanks Roland! >> >> I wrote a test case and put it together with fix in >> http://cr.openjdk.java.net/~hshi/8139758/webrev_v3/ >> In >> >> hotspot/test/compiler/stable/TestStableMemoryBarrier.java, >> stable >> field?s object allocation doesn?t dominate method >> exit. This >> will >> trigger assertion when verify dominance. This issue >> doesn?t >> exist in >> current code, can be exposed when MemBarPrecedent >> is added >> for stable >> field write?s MemBarRelease node (with following >> patch). >> >> --- a/src/share/vm/opto/parse3.cpp Mon Nov 02 >> 12:34:27 >> 2015 +0000 >> +++ b/src/share/vm/opto/parse3.cpp Wed Nov 04 >> 15:02:31 >> 2015 +0800 >> @@ -313,9 +313,8 @@ >> // Preserve allocation ptr to create >> precedent edge >> to it in membar >> // generated on exit from constructor. >> - if (C->eliminate_boxing() && >> - adr_type->isa_oopptr() && >> adr_type->is_oopptr()->is_ptr_to_boxed_value() && >> - AllocateNode::Ideal_allocation(obj, &_gvn) >> != NULL) { >> + if (AllocateNode::Ideal_allocation(obj, &_gvn) >> != NULL) { >> set_alloc_with_final(obj); >> } >> } >> >> Run with debug build on linux amd64 platform >> ?jtreg/bin/jtreg >> >> hotspot/test/compiler/stable/TestStableMemoryBarrier.java ? >> Assertion >> can be reproduced. >> *** Use 167 isn't dominated by def 170 *** >> # To suppress the following error report, specify >> this argument >> # after -XX: or in .hotspotrc: >> SuppressErrorAt=/loopnode.cpp:3235 >> # >> # A fatal error has been detected by the Java Runtime >> Environment: >> # >> # Internal Error >> >> >> (/home/shihui/jdk9-hs-comp/src/jdk9/hotspot/src/share/vm/opto/loopnode.cpp:3235), >> pid=23461, tid=23513 >> # assert(!had_error) failed: bad dominance >> # >> # JRE version: OpenJDK Runtime Environment (9.0) >> (build >> 1.9.0-internal-debug-shihui_2015_10_20_07_17-b00) >> # Java VM: OpenJDK 64-Bit Server VM >> (1.9.0-internal-debug-shihui_2015_10_20_07_17-b00, >> compiled >> mode, >> tiered, compressed oops, g1 gc, linux-amd64) >> # Core dump will be written. Default location: Core >> dumps may be >> processed with "/usr/share/apport/apport %p %s %c >> %P" (or >> dumping to >> >> /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/core.23461) >> # >> Unsupported internal testing APIs have been used. >> # An error report file with more information is >> saved as: >> # >> >> >> /home/shihui/jdk9-hs-comp/src/jdk9/JTwork/scratch/hs_err_pid23461.log >> >> >> Regards >> Shi Hui >> >> On 31 October 2015 at 00:04, Roland Westrelin >> > >> > > >> > >> > >>> wrote: >> >> > webrev: >> http://cr.openjdk.java.net/~hshi/8139758/webrev_v2/ >> >> Thanks for re-submitting this. >> So you?re fixing an existing bug in the >> process. Nice. >> We usually >> need a test case for every bug fix. Can you >> write such >> a test case >> that triggers that bug. test/compiler/stable has >> example regression >> test cases for @Stable. >> >> Roland. >> >> >> >> >> >> From edward.nevill at gmail.com Tue Nov 17 09:56:24 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 17 Nov 2015 09:56:24 +0000 Subject: [aarch64-port-dev ] RFR: 8143067: aarch64: guarantee failure in javac (adrp out of range in relocation) Message-ID: <1447754184.32670.16.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8143067/webrev JIRA Issuel: https://bugs.openjdk.java.net/browse/JDK-8143067 The issue is described in more detail in the JIRA issue but basically adrp instructions are becoming out of range during code relocation. This is happening with -Xmx4G (or greater). The problem is the existing code for adrp() does if (offset out of range) { generate other code to form address } else { generate adrp } Unfortunately this not work if the adrp subsequently becomes out of range due to code relocation, and this cannot be fixed up in a relocation because it will require more than 1 instruction. The solution I have adopted is to add a new method far_adrp() which must be used if the adrp may be out of range of a single adrp instruction. The existing adrp() has been modified to guarantee that the offset is in range. far_adrp() generates either adrp Rn, symbol nop if the symbol is initially within range or adrp Rn, ; fill in bits 0..31 in Rn mov Rn, <2nd part> << 32 ; fill in bits 32..47 If the symbol subsequently becomes out of range because of a code relocation the nop in the first form is rewritten as a movk in the 2nd form. Tested with jtreg hotspot and langtools Hotspot before: Test results: passed: 927; failed: 6; error: 11 Hotspot after: Test results: passed: 928; failed: 5; error: 11 Langtools before and after: Test results: passed: 3,326; error: 2 If have also tested it with jtreg/jdk to ensure there were no fatal errors and tested jtreg/hotspot with a fastdebug version to check the fix does not cause any assert failure. Thanks for your help, Ed. From daniel.stewart at linaro.org Wed Nov 18 16:48:48 2015 From: daniel.stewart at linaro.org (Daniel Stewart) Date: Wed, 18 Nov 2015 11:48:48 -0500 Subject: [aarch64-port-dev ] Patch for uninitialized variables Message-ID: The latest jdk9 doesn't build due to uninitialized variables. It appears that warnings as errors was recently turned on. This patch initializes the variables that were causing issues, allowing hotspot to build. Patch at: http://people.linaro.org/~daniel.stewart/uninitialized.patch Regards, Daniel -- Daniel Stewart From aph at redhat.com Wed Nov 18 17:00:48 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Nov 2015 17:00:48 +0000 Subject: [aarch64-port-dev ] Patch for uninitialized variables In-Reply-To: References: Message-ID: <564CAEC0.8090902@redhat.com> On 11/18/2015 04:48 PM, Daniel Stewart wrote: > The latest jdk9 doesn't build due to uninitialized variables. It appears > that warnings as errors was recently turned on. This patch initializes the > variables that were causing issues, allowing hotspot to build. > > Patch at: > http://people.linaro.org/~daniel.stewart/uninitialized.patch This is a patch for upstream, so it will have to be submitted there along with a bug report. However, I would note that the warnings I've looked at are all bogus, and doing stuff just to shut the compiler up doesn't strike me as very helpful. We might be able to define ShouldNotReachHere so that it is treated by the compiler as __attribute__((noreturn)). I'm not sure that this will fix everything but IMHO it's better than a bunch of unnecessary code. BTW, I guess you know you can build with --disable-warnings-as-errors. Andrew. From aph at redhat.com Wed Nov 18 17:03:53 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Nov 2015 17:03:53 +0000 Subject: [aarch64-port-dev ] Patch for uninitialized variables In-Reply-To: <564CAEC0.8090902@redhat.com> References: <564CAEC0.8090902@redhat.com> Message-ID: <564CAF79.8070208@redhat.com> On 11/18/2015 05:00 PM, Andrew Haley wrote: > We might be able to define ShouldNotReachHere so that it is treated by > the compiler as __attribute__((noreturn)). I'm not sure that this > will fix everything but IMHO it's better than a bunch of unnecessary > code. Or, if that doesn't work, move the initialization after the ShouldNotReachHere(). At least that way it doesn't pollute the rest of the code. Andrew. From vladimir.kozlov at oracle.com Fri Nov 20 00:12:12 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Nov 2015 16:12:12 -0800 Subject: [aarch64-port-dev ] RFR: 8143067: aarch64: guarantee failure in javac (adrp out of range in relocation) In-Reply-To: <1447754184.32670.16.camel@mylittlepony.linaroharston> References: <1447754184.32670.16.camel@mylittlepony.linaroharston> Message-ID: <564E655C.1030804@oracle.com> Looks good to me. Thanks, Vladimir On 11/17/15 1:56 AM, Edward Nevill wrote: > Hi, > > Please review the following webrev > > http://cr.openjdk.java.net/~enevill/8143067/webrev > > JIRA Issuel: https://bugs.openjdk.java.net/browse/JDK-8143067 > > The issue is described in more detail in the JIRA issue but basically > adrp instructions are becoming out of range during code relocation. This > is happening with -Xmx4G (or greater). > > The problem is the existing code for adrp() does > > if (offset out of range) { > generate other code to form address > } else { > generate adrp > } > > Unfortunately this not work if the adrp subsequently becomes out of > range due to code relocation, and this cannot be fixed up in a > relocation because it will require more than 1 instruction. > > The solution I have adopted is to add a new method far_adrp() which must > be used if the adrp may be out of range of a single adrp instruction. > The existing adrp() has been modified to guarantee that the offset is in > range. > > far_adrp() generates either > > adrp Rn, symbol > nop > > if the symbol is initially within range or > > adrp Rn, ; fill in bits 0..31 in Rn > mov Rn, <2nd part> << 32 ; fill in bits 32..47 > > If the symbol subsequently becomes out of range because of a code > relocation the nop in the first form is rewritten as a movk in the 2nd > form. > > Tested with jtreg hotspot and langtools > > Hotspot before: Test results: passed: 927; failed: 6; error: 11 > Hotspot after: Test results: passed: 928; failed: 5; error: 11 > > Langtools before and after: Test results: passed: 3,326; error: 2 > > If have also tested it with jtreg/jdk to ensure there were no fatal > errors and tested jtreg/hotspot with a fastdebug version to check the > fix does not cause any assert failure. > > Thanks for your help, > Ed. > > From hui.shi at linaro.org Fri Nov 20 14:07:36 2015 From: hui.shi at linaro.org (Hui Shi) Date: Fri, 20 Nov 2015 22:07:36 +0800 Subject: [aarch64-port-dev ] RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire Message-ID: Hi, Could someone help review and sponsor this fix for aarch64 runtime? Bug: https://bugs.openjdk.java.net/browse/JDK-8143285 webrev: http://cr.openjdk.java.net/~hshi/8143285/webrev/ In InterpreterMacroAssembler::get_cache_and_index_and_bytecode_at_bcp, rewrite bytecode in ConstantPoolCacheEntry._indices is read with ldrw on aarch64. Following loads (for example ConstantPoolCacheEntry._flags and field offset) might finish before ConstantPoolCacheEntry._indices load and get unexpected values. ConstantPoolCacheEntry._indices is read and write with load acquire and store release in all other places. It also need load acquire here to guarantee read correct field offset and flags from ConstantPoolCacheEntry. getfield emplate interpreter code before fix 0x0000007f780a2aa4: ldrh w3, [x22,#1] 0x0000007f780a2aa8: add x2, x26, x3, lsl #5 0x0000007f780a2aac: ldr w19, [x2,#16] 0x0000007f780a2ab0: ubfx x19, x19, #16, #8 0x0000007f780a2ab4: cmp x19, #0xb4 0x0000007f780a2ab8: b.eq 0x0000007f780a2ba4 0x0000007f780a2ba4: ldr x19, [x2,#32] // read field offset, not ordered with rewrite byte code load 0x0000007f780a2ba8: ldr w0, [x2,#40] // read flags, not ordered with rewrite byte code load 0x0000007f780a2bac: ldr x4, [x20],#8 getfield template interpreter code after fix 0x0000007f900a2ba8: add x2, x26, x3, lsl #5 0x0000007f900a2bac: add x19, x2, #0x10 0x0000007f900a2bb0: ldar w19, [x19] 0x0000007f900a2bb4: ubfx x19, x19, #16, #8 0x0000007f900a2bb8: cmp x19, #0xb4 0x0000007f900a2bbc: b.eq 0x0000007f900a2ca8 0x0000007f780a2ba4: ldr x19, [x2,#32] // read offset, ordered with rewrite byte code load 0x0000007f780a2ba8: ldr w0, [x2,#40] // read flags?ordered with rewrite byte code load 0x0000007f780a2bac: ldr x4, [x20],#8 This problem causes template interpreter code for getfield gets wrong ConstantPoolCacheEntry._flags with uninitialized tos state. As uninitialized tos is "0" same with "btos", this is a little bit confusing when debug (at first uninitialized tos is 0 and it doesn?t trigger error in first execution of getfield, it triggers error in other thread when try to patch byte code with different value), is it possible to use some magic number here indicate the uninitialized "tos state" in _flags? For example 0xf, and it can trigger "bad state" error at first wrong palce. Regards Shi Hui From aph at redhat.com Sat Nov 21 10:42:02 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 21 Nov 2015 10:42:02 +0000 Subject: [aarch64-port-dev ] RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire In-Reply-To: References: Message-ID: <56504A7A.6030307@redhat.com> The patch looks good. I suggest some minor changes. // n.b. unlike x86 cache alreeady includes the index offset Please correct to "already" This ldrw(bytecode, Address(cache, ConstantPoolCache::base_offset() + ConstantPoolCacheEntry::indices_offset())); could simply be changed to lea(bytecode, Address(cache, ConstantPoolCache::base_offset() + ConstantPoolCacheEntry::indices_offset())); ldarw(bytecode, bytecode); which would be more idiomatic for this port. It generates the same code. Andrew. From edward.nevill at gmail.com Mon Nov 23 15:07:11 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 23 Nov 2015 15:07:11 +0000 Subject: [aarch64-port-dev ] RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire In-Reply-To: References: Message-ID: <1448291231.9605.9.camel@mint> On Fri, 2015-11-20 at 22:07 +0800, Hui Shi wrote: > Hi, > > Could someone help review and sponsor this fix for aarch64 runtime? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143285 > webrev: http://cr.openjdk.java.net/~hshi/8143285/webrev/ Hi Shi Hui, Thanks for finding this. Do you think this should be predicated on 'UseBarriersForVolatile' IE. if (UseBarrieresForVolatile) { } else { / } This seems to be the only code in the Template Interpreter or C1 that uses acquire release. The only place acquire release is used otherwise is in C2. Do you think we should just use membar to fix this problem and then as a separate issue look at whether we augment the membars in Template Interpreter / C1 to load acquire / store release when possible. Thanks for looking into this, Ed. From aph at redhat.com Mon Nov 23 15:15:16 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 Nov 2015 15:15:16 +0000 Subject: [aarch64-port-dev ] RFR(S): aarch64 Fix loading ConstantPoolCacheEntry._indices with load acquire In-Reply-To: <1448291231.9605.9.camel@mint> References: <1448291231.9605.9.camel@mint> Message-ID: <56532D84.4080805@redhat.com> On 11/23/2015 03:07 PM, Edward Nevill wrote: > > On Fri, 2015-11-20 at 22:07 +0800, Hui Shi wrote: >> Hi, >> >> Could someone help review and sponsor this fix for aarch64 runtime? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8143285 >> webrev: http://cr.openjdk.java.net/~hshi/8143285/webrev/ > > Hi Shi Hui, > > Thanks for finding this. > > Do you think this should be predicated on 'UseBarriersForVolatile' No, this is fine. This isn't a Java volatile, it's VM-internal. AArch64 ldar/stlr work just fine for it on all hardware. > IE. > > if (UseBarrieresForVolatile) { > > } else { > / > } > > This seems to be the only code in the Template Interpreter or C1 > that uses acquire release. The only place acquire release is used > otherwise is in C2. > > Do you think we should just use membar to fix this problem and then > as a separate issue look at whether we augment the membars in > Template Interpreter / C1 to load acquire / store release when > possible. No, this is fine. The wider question of changing the Template Interpreter / C1 to load acquire / store release can wait. I think it's just moving the furniture around for no good reason. Andrew. From hui.shi at linaro.org Tue Nov 24 13:23:33 2015 From: hui.shi at linaro.org (Hui Shi) Date: Tue, 24 Nov 2015 21:23:33 +0800 Subject: [aarch64-port-dev ] RFR: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire Message-ID: Hi, Could someone help review and sponsor more runtime fix for aarch64? bug: https://bugs.openjdk.java.net/browse/JDK-8143584 webrev: http://cr.openjdk.java.net/~hshi/8143584/webrev/ This also fix some random crash in template interpreter. One of the crash test is langtools/test/tools/javac/TestLambdaToMethodStats.java. The symptom is: in checkcast, klass being checked is not valid klass pointer and trigger segmentation fault. The root cause is on aarch64 it miss load acquire when trying to read tag in constant pool before load resolved klass. Resolved class load might finish before tag load. Code for checkcast before fix 0x7f8409a5a0: add x8, x3, #0x4 0x7f8409a5a4: ldrb w1, [x8,x19] // load tag 0x7f8409a5a8: cmp x1, #0x7 __ cmp(r1, JVM_CONSTANT_Class); 0x7f8409a62c: mov x3, x0 0x7f8409a630: add x0, x2, x19, uxtx #3 0x7f8409a634: ldr x0, [x0,#80] 0x7f8409a638: ldr w19, [x3,#8] // load resolved class 0x7f8409a63c: eor x19, x19, #0x800000000 // x19 hold klass being checked Load resolved class might finish before load tag and read incorrect value. Fix is using load acquire when load tag. These tags are updated with release store in ConstantPool::release_tag_at_put (which uses OrderAccess::release_store), tags need be loaded with load acquire instruction ensure later resolved class load get correct klass. Fix is using load acquire when load tag and compare. After fix: 0x0000007f8009a6a4: add x8, x8, x19 0x0000007f8009a6a8: ldarb w1, [x8] 0x0000007f8009a6ac: cmp x1, #0x7 0x0000007f8009a6b0: b.eq 0x0000007f8009a730 ?. 0x0000007f8009a730: mov x3, x0 0x0000007f8009a734: add x0, x2, x19, uxtx #3 0x0000007f8009a738: ldr x0, [x0,#80] 0x0000007f8009a73c: ldr w19, [x3,#8] 0x0000007f8009a740: eor x19, x19, #0x800000000 Checking similar places for aarch64 runtime, more places needs similar fix: 1. Instanceof is similar with checkcast 2. "ldc", similar with load resolved class in checkcast, need load acquire when loading tag in constant pool 3. "new" loads tag for resolved class. 4. "new" Loads and checks class initialized status, class init status update is guarded with orderaccess::storestore, need guarantee order between load class initialize status and load "instance_size in InstanceKlass". 5. C1 runtime checks if class initialize status when generate code for fast_new_instance_init_check_id, similar with "new". Regards Shi Hui From aph at redhat.com Tue Nov 24 14:05:07 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 24 Nov 2015 14:05:07 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire In-Reply-To: References: Message-ID: <56546E93.8080106@redhat.com> On 11/24/2015 01:23 PM, Hui Shi wrote: > Checking similar places for aarch64 runtime, more places needs similar fix: > 1. Instanceof is similar with checkcast > 2. "ldc", similar with load resolved class in checkcast, need load acquire > when loading tag in constant pool > 3. "new" loads tag for resolved class. > 4. "new" Loads and checks class initialized status, class init status > update is guarded with orderaccess::storestore, need guarantee order > between load class initialize status and load "instance_size in > InstanceKlass". > 5. C1 runtime checks if class initialize status when generate code for > fast_new_instance_init_check_id, similar with "new". I'm looking at 4, the InstanceKlass::init_state change: @@ -3326,7 +3328,8 @@ // make sure klass is initialized & doesn't have finalizer // make sure klass is fully initialized - __ ldrb(rscratch1, Address(r4, InstanceKlass::init_state_offset())); + __ lea(rscratch1, Address(r4, InstanceKlass::init_state_offset())); + __ ldarb(rscratch1, rscratch1); __ cmp(rscratch1, InstanceKlass::fully_initialized); __ br(Assembler::NE, slow_case); While this looks reasonable enough, the init_state accessors in InstanceKlass don't seem to use fences. Therefore, as far as I can see, the set_init_state (fully_initialized) doesn't have a happens-before relationship with the load of init_state above. This is in eager_initialize_impl(): // linking successfull, mark class as initialized this_k->set_init_state (fully_initialized); this_k->fence_and_clear_init_lock(); Note that the call to fence_and_clear_init_lock() (which contains a storestore) is *after* the set_init_state(). If set_init_state() needs to synchronize with the reading code, a storestore must come *before* set_init_state() is called. The rest look OK. Andrew. From edward.nevill at gmail.com Wed Nov 25 10:22:28 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 25 Nov 2015 10:22:28 +0000 Subject: [aarch64-port-dev ] Support large codecache for JDK8 In-Reply-To: <54FEC76B.40400@redhat.com> References: <54FEC76B.40400@redhat.com> Message-ID: <1448446948.31528.9.camel@mylittlepony.linaroharston> Hi Andrew, Did this patch ever make it into jdk8 (and/or jdk7)? One of our partners has reported problems with the Apace BigTop build which uses JDK 7 and sets -XX:ReservedCodeCacheSize=512M. The problem seems to be a BL going out of range. All the best, Ed. On Tue, 2015-03-10 at 10:28 +0000, Andrew Dinn wrote: > Attached for review is a patch which adds large codecache support to > jdk8 (jdk7 version will be next). > > It passes basic smoke tests (java hello, javac Hello.java, netbeans > build and run simple project). > > Ok to push? > > regards, > > > Andrew Dinn > ----------- > # HG changeset patch # User adinn # Date 1425980888 0 # Tue Mar 10 09:48:08 2015 +0000 # Node ID 2486a66bb7e7b7e013050fbf8b2924b8149ebaad # Parent a747c1771e54e289f478387bd74ae34660f388ee Support for large code caches From hui.shi at linaro.org Wed Nov 25 11:28:47 2015 From: hui.shi at linaro.org (Hui Shi) Date: Wed, 25 Nov 2015 19:28:47 +0800 Subject: [aarch64-port-dev ] RFR: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire In-Reply-To: <56546E93.8080106@redhat.com> References: <56546E93.8080106@redhat.com> Message-ID: Thanks Andrew! You're right. StoreStore is added after class initialization status setting. Load acquire for class initialization status check should be unnecessary even on aarch64. InstanceKlass._layout_helper is written in ClassFileParser::parseClassFile when resolving class and create InstanceKlass. InstanceKlass._init_state is updated in InstanceKlass::set_initialization_state_and_notify_impl when initializing class. They can happen in different threads in my understanding. InstanceKlass? content (for fields like _layout_helper) should be correct for all reference no matter class is initialized or not after class resolutions. I haven't find explicit code synchronize InstanceKlass' content. In SystemDictionary::load_instance_class, it uses MutexLocker and this might help. new webrev in http://cr.openjdk.java.net/~hshi/8143584/webrev_v2/ Regards Shi Hui On 24 November 2015 at 22:05, Andrew Haley wrote: > On 11/24/2015 01:23 PM, Hui Shi wrote: > > > Checking similar places for aarch64 runtime, more places needs similar > fix: > > 1. Instanceof is similar with checkcast > > 2. "ldc", similar with load resolved class in checkcast, need load > acquire > > when loading tag in constant pool > > 3. "new" loads tag for resolved class. > > 4. "new" Loads and checks class initialized status, class init status > > update is guarded with orderaccess::storestore, need guarantee order > > between load class initialize status and load "instance_size in > > InstanceKlass". > > 5. C1 runtime checks if class initialize status when generate code for > > fast_new_instance_init_check_id, similar with "new". > > I'm looking at 4, the InstanceKlass::init_state change: > > @@ -3326,7 +3328,8 @@ > > // make sure klass is initialized & doesn't have finalizer > // make sure klass is fully initialized > - __ ldrb(rscratch1, Address(r4, InstanceKlass::init_state_offset())); > + __ lea(rscratch1, Address(r4, InstanceKlass::init_state_offset())); > + __ ldarb(rscratch1, rscratch1); > __ cmp(rscratch1, InstanceKlass::fully_initialized); > __ br(Assembler::NE, slow_case); > > While this looks reasonable enough, the init_state accessors in > InstanceKlass don't seem to use fences. Therefore, as far as I can > see, the set_init_state (fully_initialized) doesn't have a > happens-before relationship with the load of init_state above. > > This is in eager_initialize_impl(): > > // linking successfull, mark class as initialized > this_k->set_init_state (fully_initialized); > this_k->fence_and_clear_init_lock(); > > Note that the call to fence_and_clear_init_lock() (which contains a > storestore) is *after* the set_init_state(). If set_init_state() > needs to synchronize with the reading code, a storestore must come > *before* set_init_state() is called. > > The rest look OK. > > Andrew. > From aph at redhat.com Wed Nov 25 12:09:07 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Nov 2015 12:09:07 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire In-Reply-To: References: <56546E93.8080106@redhat.com> Message-ID: <5655A4E3.6070505@redhat.com> On 11/25/2015 11:28 AM, Hui Shi wrote: > > I haven't find explicit code synchronize InstanceKlass' content. In > SystemDictionary::load_instance_class, it uses MutexLocker and this might > help. We don't need to synchronize in TemplateTable::_new because Klass::layout_helper saves the slow_path flag in the least significant bit. If we find that layout_helper is not valid we'll take the slow path and acquire the lock. > new webrev in http://cr.openjdk.java.net/~hshi/8143584/webrev_v2/ That looks OK. Thanks, Andrew. From adinn at redhat.com Wed Nov 25 12:50:33 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 25 Nov 2015 12:50:33 +0000 Subject: [aarch64-port-dev ] Support large codecache for JDK8 In-Reply-To: <1448446948.31528.9.camel@mylittlepony.linaroharston> References: <54FEC76B.40400@redhat.com> <1448446948.31528.9.camel@mylittlepony.linaroharston> Message-ID: <5655AE99.4080505@redhat.com> On 25/11/15 10:22, Edward Nevill wrote: > Did this patch ever make it into jdk8 (and/or jdk7)? One of our > partners has reported problems with the Apace BigTop build which uses > JDK 7 and sets -XX:ReservedCodeCacheSize=512M. The problem seems to > be a BL going out of range. No, it's not in. I think it got left pending because of other things that were going on and then was forgotten about. I guess we ought to rework it (assuming it needs work to cater for changes in the interim) and push to 8 and then also backport it to 7. regards, Andrew Dinn From hui.shi at linaro.org Wed Nov 25 13:21:03 2015 From: hui.shi at linaro.org (Hui Shi) Date: Wed, 25 Nov 2015 21:21:03 +0800 Subject: [aarch64-port-dev ] RFR: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire In-Reply-To: <5655A4E3.6070505@redhat.com> References: <56546E93.8080106@redhat.com> <5655A4E3.6070505@redhat.com> Message-ID: Thanks! Yes, I see layout_helper is initialized with slow_path flag in InstanceKlass constructor. // Set temporary value until parseClassFile updates it with the real instance // size. set_layout_helper(Klass::instance_layout_helper(0, true)); Regards Shi Hui On 25 November 2015 at 20:09, Andrew Haley wrote: > On 11/25/2015 11:28 AM, Hui Shi wrote: > > > > I haven't find explicit code synchronize InstanceKlass' content. In > > SystemDictionary::load_instance_class, it uses MutexLocker and this might > > help. > > We don't need to synchronize in TemplateTable::_new because > Klass::layout_helper saves the slow_path flag in the least significant > bit. If we find that layout_helper is not valid we'll take the slow > path and acquire the lock. > > > new webrev in http://cr.openjdk.java.net/~hshi/8143584/webrev_v2/ > > That looks OK. > > Thanks, > > Andrew. > > > From edward.nevill at gmail.com Wed Nov 25 13:58:51 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 25 Nov 2015 13:58:51 +0000 Subject: [aarch64-port-dev ] RFR: Backports to jdk8 Message-ID: <1448459931.15761.7.camel@mylittlepony.linaroharston> Hi, Please review the following backports from JDK 9 to JDK 8. http://cr.openjdk.java.net/~enevill/jdk8_backports_1511 Tested with jtreg hotspot and langtools. Results the same before and after. Hotspot: Test results: passed: 674; failed: 17; error: 3 Langtools: Test results: passed: 3,091 Below is a summary of the changesets. Thanks, Ed. --- ed at arm64:~/jdk8/jdk8/hotspot$ hg outgoing comparing with ssh://enevill at hg.openjdk.java.net/aarch64-port/jdk8/hotspot running ssh enevill at hg.openjdk.java.net 'hg -R aarch64-port/jdk8/hotspot serve --stdio' searching for changes changeset: 8572:3b837e8988b5 user: aph date: Tue Sep 08 14:08:58 2015 +0100 files: src/cpu/aarch64/vm/aarch64.ad description: 8135157: DMB elimination in AArch64 C2 synchronization implementation Summary: Reduce memory barrier usage in C2 fast lock and unlock. Reviewed-by: kvn Contributed-by: wei.tang at linaro.org, aph at redhat.com changeset: 8573:85e9169ff89c user: aph date: Wed Nov 04 13:38:38 2015 +0100 files: src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp description: 8138966: Intermittent SEGV running ParallelGC Summary: Add necessary memory fences so that the parallel threads are unable to observe partially filled block tables. Reviewed-by: tschatzl changeset: 8574:3b4d83989d8e user: enevill date: Thu Nov 19 15:15:20 2015 +0000 files: src/cpu/aarch64/vm/macroAssembler_aarch64.cpp description: 8143067: aarch64: guarantee failure in javac Summary: Fix adrp going out of range during code relocation Reviewed-by: aph, kvn changeset: 8575:d74991e8f574 tag: tip user: hshi date: Tue Nov 24 09:02:26 2015 +0000 files: src/cpu/aarch64/vm/interp_masm_aarch64.cpp description: 8143285: aarch64: Missing load acquire when checking if ConstantPoolCacheEntry is resolved Reviewed-by: roland, aph --- From adinn at redhat.com Wed Nov 25 14:10:48 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 25 Nov 2015 14:10:48 +0000 Subject: [aarch64-port-dev ] RFR: Backports to jdk8 In-Reply-To: <1448459931.15761.7.camel@mylittlepony.linaroharston> References: <1448459931.15761.7.camel@mylittlepony.linaroharston> Message-ID: <5655C168.3020805@redhat.com> On 25/11/15 13:58, Edward Nevill wrote: > Please review the following backports from JDK 9 to JDK 8. > > http://cr.openjdk.java.net/~enevill/jdk8_backports_1511 > > Tested with jtreg hotspot and langtools. Results the same before and after. > > Hotspot: Test results: passed: 674; failed: 17; error: 3 > Langtools: Test results: passed: 3,091 All looks good to me. regards, Andrew Dinn ----------- From edward.nevill at gmail.com Wed Nov 25 15:44:50 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 25 Nov 2015 15:44:50 +0000 Subject: [aarch64-port-dev ] RFR: aarch64: backports to JDK 7 Message-ID: <1448466290.16878.5.camel@mylittlepony.linaroharston> Hi, Please review the following backports to JDK 7 http://cr.openjdk.java.net/~enevill/jdk7_backports_1511/ Tested with jtreg hotspot & langtools. Results the same before and after. Hotspot: Test results: passed: 297; failed: 12; error: 2 Langtools: Test results: passed: 1,971; failed: 1; error: 2 Summary of the changesets below. Thanks, Ed. --- enevill at arm64:~/icedtea7-forest/hotspot$ hg outgoing comparing with ssh://enevill at icedtea.classpath.org/hg/icedtea7-forest/hotspot running ssh enevill at icedtea.classpath.org 'hg -R hg/icedtea7-forest/hotspot serve --stdio' searching for changes changeset: 6380:5b6efbae9fea user: aph date: Wed Nov 04 13:38:38 2015 +0100 files: src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp description: 8138966: Intermittent SEGV running ParallelGC Summary: Add necessary memory fences so that the parallel threads are unable to observe partially filled block tables. Reviewed-by: tschatzl changeset: 6381:c7679d143590 user: enevill date: Thu Nov 19 15:15:20 2015 +0000 files: src/cpu/aarch64/vm/assembler_aarch64.cpp description: 8143067: aarch64: guarantee failure in javac Summary: Fix adrp going out of range during code relocation Reviewed-by: aph, kvn changeset: 6382:eeb4a3ec4563 tag: tip user: hshi date: Tue Nov 24 09:02:26 2015 +0000 files: src/cpu/aarch64/vm/interp_masm_aarch64.cpp description: 8143285: aarch64: Missing load acquire when checking if ConstantPoolCacheEntry is resolved Reviewed-by: roland, aph --- From edward.nevill at gmail.com Thu Nov 26 09:43:02 2015 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Thu, 26 Nov 2015 09:43:02 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8/hotspot: 4 new changesets Message-ID: <201511260943.tAQ9h2fN008925@aojmv0008.oracle.com> Changeset: 3b837e8988b5 Author: aph Date: 2015-09-08 14:08 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/3b837e8988b5 8135157: DMB elimination in AArch64 C2 synchronization implementation Summary: Reduce memory barrier usage in C2 fast lock and unlock. Reviewed-by: kvn Contributed-by: wei.tang at linaro.org, aph at redhat.com ! src/cpu/aarch64/vm/aarch64.ad Changeset: 85e9169ff89c Author: aph Date: 2015-11-04 13:38 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/85e9169ff89c 8138966: Intermittent SEGV running ParallelGC Summary: Add necessary memory fences so that the parallel threads are unable to observe partially filled block tables. Reviewed-by: tschatzl ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 3b4d83989d8e Author: enevill Date: 2015-11-19 15:15 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/3b4d83989d8e 8143067: aarch64: guarantee failure in javac Summary: Fix adrp going out of range during code relocation Reviewed-by: aph, kvn ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Changeset: d74991e8f574 Author: hshi Date: 2015-11-24 09:02 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/rev/d74991e8f574 8143285: aarch64: Missing load acquire when checking if ConstantPoolCacheEntry is resolved Reviewed-by: roland, aph ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp From hui.shi at linaro.org Thu Nov 26 12:59:17 2015 From: hui.shi at linaro.org (Hui Shi) Date: Thu, 26 Nov 2015 20:59:17 +0800 Subject: [aarch64-port-dev ] RFR: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire In-Reply-To: References: <56546E93.8080106@redhat.com> <5655A4E3.6070505@redhat.com> Message-ID: As Andrew still in JDK9 reviewer nomination process :) Could I have an official reviewer and sponsor for this aarch64 runtime change? Regards Hui On 25 November 2015 at 21:21, Hui Shi wrote: > Thanks! > > Yes, I see layout_helper is initialized with slow_path flag in InstanceKlass > constructor. > > // Set temporary value until parseClassFile updates it with the real > instance > // size. > set_layout_helper(Klass::instance_layout_helper(0, true)); > > Regards > Shi Hui > > On 25 November 2015 at 20:09, Andrew Haley wrote: > >> On 11/25/2015 11:28 AM, Hui Shi wrote: >> > >> > I haven't find explicit code synchronize InstanceKlass' content. In >> > SystemDictionary::load_instance_class, it uses MutexLocker and this >> might >> > help. >> >> We don't need to synchronize in TemplateTable::_new because >> Klass::layout_helper saves the slow_path flag in the least significant >> bit. If we find that layout_helper is not valid we'll take the slow >> path and acquire the lock. >> >> > new webrev in http://cr.openjdk.java.net/~hshi/8143584/webrev_v2/ >> >> That looks OK. >> >> Thanks, >> >> Andrew. >> >> >> > From roland.westrelin at oracle.com Thu Nov 26 14:37:19 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 26 Nov 2015 15:37:19 +0100 Subject: [aarch64-port-dev ] RFR: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire In-Reply-To: References: <56546E93.8080106@redhat.com> <5655A4E3.6070505@redhat.com> Message-ID: <39C44A98-F6EE-4D1F-8572-7858CA7FB9B7@oracle.com> > new webrev in http://cr.openjdk.java.net/~hshi/8143584/webrev_v2/ That looks good to me. Roland. From edward.nevill at gmail.com Thu Nov 26 14:47:33 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 26 Nov 2015 14:47:33 +0000 Subject: [aarch64-port-dev ] RFR: JDK-8143584 Aarch64: Load constant pool tag and class status with load acquire In-Reply-To: <39C44A98-F6EE-4D1F-8572-7858CA7FB9B7@oracle.com> References: <56546E93.8080106@redhat.com> <5655A4E3.6070505@redhat.com> <39C44A98-F6EE-4D1F-8572-7858CA7FB9B7@oracle.com> Message-ID: <1448549253.2283.4.camel@mylittlepony.linaroharston> On Thu, 2015-11-26 at 15:37 +0100, Roland Westrelin wrote: > > new webrev in http://cr.openjdk.java.net/~hshi/8143584/webrev_v2/ > > That looks good to me. > > Roland. Thanks Roland, I'll prepare a changeset and push it to hs-rt, Ed. From aph at redhat.com Thu Nov 26 14:50:42 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Nov 2015 14:50:42 +0000 Subject: [aarch64-port-dev ] Support large codecache for JDK8 In-Reply-To: <5655AE99.4080505@redhat.com> References: <54FEC76B.40400@redhat.com> <1448446948.31528.9.camel@mylittlepony.linaroharston> <5655AE99.4080505@redhat.com> Message-ID: <56571C42.2020502@redhat.com> On 11/25/2015 12:50 PM, Andrew Dinn wrote: > On 25/11/15 10:22, Edward Nevill wrote: >> Did this patch ever make it into jdk8 (and/or jdk7)? One of our >> partners has reported problems with the Apace BigTop build which uses >> JDK 7 and sets -XX:ReservedCodeCacheSize=512M. The problem seems to >> be a BL going out of range. > > No, it's not in. I think it got left pending because of other things > that were going on and then was forgotten about. I guess we ought to > rework it (assuming it needs work to cater for changes in the interim) > and push to 8 and then also backport it to 7. I think this patch is very nearly a clone of http://hg.openjdk.java.net/aarch64-port/jdk9/hotspot/rev/5a92ef3b79a5 The main difference is, I think, the setting of CODE_CACHE_SIZE_LIMIT. I am very keen not to see divergence in this area if at all possible, so this looks okay. I don't think it's been changed much. Ed, does the Apace BigTop build suffer with default ReservedCodeCacheSize? I'vebeen wanting to find out if a larger code cache outweighs the overhead of trampolines. Andrew. From aph at redhat.com Thu Nov 26 15:40:20 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Nov 2015 15:40:20 +0000 Subject: [aarch64-port-dev ] =?utf-8?b?5Zue5aSN77yaIFJGUjogSkRLLTgxNDM1?= =?utf-8?q?84_Aarch64=3A_Load_constant_pooltag_and_class_status_with_load_?= =?utf-8?q?acquire?= In-Reply-To: References: <5655A4E3.6070505@redhat.com> <56546E93.8080106@redhat.com> Message-ID: <565727E4.7050009@redhat.com> On 11/26/2015 10:39 AM, hui.shi wrote: > Could I have an official reviewer and sponsor for this aarch64 runtime change? Pushed. Next time, please do an "hg commit" with proper comments before generating the webrev. Thanks, Andrew. From felix.yang at linaro.org Sat Nov 28 15:05:51 2015 From: felix.yang at linaro.org (Felix Yang) Date: Sat, 28 Nov 2015 23:05:51 +0800 Subject: [aarch64-port-dev ] [RFR] openjdk aarch64: jdk/test/com/sun/net/httpserver/Test6a.java fails with --enable-unlimited-crypto Message-ID: Hi, Could someone help review and sponsor this runtime fix for aarch64? Bug: https://bugs.openjdk.java.net/browse/JDK-8144201 Webrev: http://cr.openjdk.java.net/~fyang/8144201/webrev.00 The test fails on aarch64 platform using openjdk8/9 configured with --enable-unlimited-crypto. Reported error message: Execution failed: `main' threw exception: java.io.IOException: Error writing request body to server. And the test passes with -XX:TieredStopAtLevel=3 or -XX:-UseAESIntrinsics option. After narrowing down, I find the bug is caused by the _cipherBlockChaining_decryptAESCrypt StubRoutine. The proposed patch fixes an obvious typo in this StubRoutine. Passed JTreg regression test(using openjdk8 built with --enable-unlimited-crypto). Is it OK to push? Fei, Thanks for your help. From edward.nevill at gmail.com Mon Nov 30 09:12:52 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 30 Nov 2015 09:12:52 +0000 Subject: [aarch64-port-dev ] JTREG, SPECjbb2013 and Hadoop/Terasort results for OpenJDK 8 on AArch64 Message-ID: <1448874772.13261.1.camel@mint> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 10 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/summary/2015/331/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 636; fail: 45; error: 5 Build 1: aarch64/2015/jul/08 pass: 636; fail: 45; error: 5 Build 2: aarch64/2015/jul/21 pass: 637; fail: 45; error: 5 Build 3: aarch64/2015/sep/04 pass: 636; fail: 46; error: 5 Build 4: aarch64/2015/sep/08 pass: 636; fail: 46; error: 5 Build 5: aarch64/2015/oct/22 pass: 637; fail: 45; error: 5 Build 6: aarch64/2015/oct/27 pass: 637; fail: 45; error: 5 Build 7: aarch64/2015/oct/29 pass: 637; fail: 45; error: 5 Build 8: aarch64/2015/nov/04 pass: 637; fail: 45; error: 5 Build 9: aarch64/2015/nov/27 pass: 637; fail: 45; error: 5 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 5,499; fail: 230; error: 20 Build 1: aarch64/2015/jul/08 pass: 5,485; fail: 242; error: 22 Build 2: aarch64/2015/jul/21 pass: 5,502; fail: 233; error: 18 Build 3: aarch64/2015/sep/04 pass: 5,477; fail: 254; error: 22 Build 4: aarch64/2015/sep/08 pass: 5,477; fail: 254; error: 22 Build 5: aarch64/2015/oct/22 pass: 5,482; fail: 254; error: 17 Build 6: aarch64/2015/oct/27 pass: 5,472; fail: 259; error: 22 Build 7: aarch64/2015/oct/29 pass: 5,503; fail: 229; error: 21 Build 8: aarch64/2015/nov/04 pass: 5,503; fail: 228; error: 22 Build 9: aarch64/2015/nov/27 pass: 5,506; fail: 227; error: 20 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 3,076; error: 15 Build 1: aarch64/2015/jul/08 pass: 3,080; error: 11 Build 2: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 3: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 4: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 5: aarch64/2015/oct/22 pass: 3,077; error: 14 Build 6: aarch64/2015/oct/27 pass: 3,081; error: 10 Build 7: aarch64/2015/oct/29 pass: 3,079; error: 12 Build 8: aarch64/2015/nov/04 pass: 3,080; error: 11 Build 9: aarch64/2015/nov/27 pass: 3,078; error: 13 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 644; fail: 37; error: 5 Build 1: aarch64/2015/jul/08 pass: 644; fail: 37; error: 5 Build 2: aarch64/2015/jul/21 pass: 645; fail: 37; error: 5 Build 3: aarch64/2015/sep/04 pass: 645; fail: 37; error: 5 Build 4: aarch64/2015/sep/08 pass: 645; fail: 37; error: 5 Build 5: aarch64/2015/oct/22 pass: 644; fail: 38; error: 5 Build 6: aarch64/2015/oct/27 pass: 644; fail: 38; error: 5 Build 7: aarch64/2015/oct/29 pass: 645; fail: 37; error: 5 Build 8: aarch64/2015/nov/04 pass: 643; fail: 39; error: 5 Build 9: aarch64/2015/nov/27 pass: 643; fail: 38; error: 6 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 5,510; fail: 215; error: 24 Build 1: aarch64/2015/jul/08 pass: 5,506; fail: 221; error: 22 Build 2: aarch64/2015/jul/21 pass: 5,512; fail: 217; error: 24 Build 3: aarch64/2015/sep/04 pass: 5,471; fail: 257; error: 25 Build 4: aarch64/2015/sep/08 pass: 5,471; fail: 257; error: 25 Build 5: aarch64/2015/oct/22 pass: 5,489; fail: 241; error: 23 Build 6: aarch64/2015/oct/27 pass: 5,495; fail: 234; error: 24 Build 7: aarch64/2015/oct/29 pass: 5,521; fail: 209; error: 23 Build 8: aarch64/2015/nov/04 pass: 5,509; fail: 222; error: 22 Build 9: aarch64/2015/nov/27 pass: 5,517; fail: 214; error: 22 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2015/jul/02 pass: 3,078; error: 13 Build 1: aarch64/2015/jul/08 pass: 3,083; error: 8 Build 2: aarch64/2015/jul/21 pass: 3,081; error: 10 Build 3: aarch64/2015/sep/04 pass: 3,078; error: 13 Build 4: aarch64/2015/sep/08 pass: 3,078; error: 13 Build 5: aarch64/2015/oct/22 pass: 3,082; fail: 2; error: 7 Build 6: aarch64/2015/oct/27 pass: 3,083; error: 8 Build 7: aarch64/2015/oct/29 pass: 3,081; error: 10 Build 8: aarch64/2015/nov/04 pass: 3,080; fail: 1; error: 10 Build 9: aarch64/2015/nov/27 pass: 3,079; error: 12 Previous results can be found here: http://openjdk.linaro.org/openjdk8-jtreg-nightly-tests/index.html SPECjbb2013 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2013 composite tests and compares the performance against the baseline performance of the server compiler taken on 2014-04-01. In accordance with [1], the SPECjbb2013 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.13x Relative performance: Server critical-jOPS (nc): 1.53x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/SPECjbb2013-1.00-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: 49.18, Server: 89.9 Client 49.18 / Client 2014-04-01 (43.00): 1.14x Server 89.9 / Server 2014-04-01 (71.00): 1.27x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 10 days. 2015-07-02 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/183/results/ 2015-07-08 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/189/results/ 2015-07-21 pass rate: 11556/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/202/results/ 2015-09-04 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/247/results/ 2015-09-08 pass rate: 11555/11556, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/251/results/ 2015-10-22 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/295/results/ 2015-10-27 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/300/results/ 2015-10-29 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/302/results/ 2015-11-04 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/308/results/ 2015-11-27 pass rate: 11558/11558, results: http://openjdk.linaro.org/jcstress-nightly-runs/2015/331/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jcstress-nightly-runs/ From edward.nevill at gmail.com Mon Nov 30 09:16:20 2015 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 30 Nov 2015 09:16:20 +0000 Subject: [aarch64-port-dev ] [RFR] openjdk aarch64: jdk/test/com/sun/net/httpserver/Test6a.java fails with --enable-unlimited-crypto In-Reply-To: References: Message-ID: <1448874980.13261.2.camel@mint> On Sat, 2015-11-28 at 23:05 +0800, Felix Yang wrote: > Hi, > > Could someone help review and sponsor this runtime fix for aarch64? > Bug: https://bugs.openjdk.java.net/browse/JDK-8144201 > Webrev: http://cr.openjdk.java.net/~fyang/8144201/webrev.00 Looks good. I'm sorry, I believe I was responsible for the typo. Regards, Ed.