From long.chen at linaro.org Wed Apr 6 12:51:00 2016 From: long.chen at linaro.org (Long Chen) Date: Wed, 6 Apr 2016 20:51:00 +0800 Subject: [aarch64-port-dev ] RFR: aarch64: Add Arrays.fill stub code Message-ID: Hi Please review this patch for generating stub code for ArrayFill on aarch64 platform. Performance test case: http://people.linaro.org/~long.chen/ArrayFill/ArrayFill.java Testing result: http://people.linaro.org/~long.chen/ArrayFill/ArrayFill.html Patch: http://people.linaro.org/~long.chen/ArrayFill/ArrayFill.patch At same time, refactoring ClearArrayNode's code generation, as it can be used by Array fill too. Following up I would like to propose a patch to use DC ZVA for large array zeroing. Jtreg tested and no regression. Regards! From gnu.andrew at redhat.com Wed Apr 6 15:57:49 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 6 Apr 2016 11:57:49 -0400 (EDT) Subject: [aarch64-port-dev ] RFR: 8u77 In-Reply-To: <56FBF41C.80305@ubuntu.com> References: <2000051970.14808112.1459219770013.JavaMail.zimbra@redhat.com> <56FA459C.7010106@redhat.com> <1905475899.15244885.1459266279486.JavaMail.zimbra@redhat.com> <56FBC84A.4010408@ubuntu.com> <56FBCE1B.3080206@redhat.com> <56FBF41C.80305@ubuntu.com> Message-ID: <908200361.19581872.1459958269256.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 30.03.2016 15:01, Andrew Haley wrote: > > On 03/30/2016 01:36 PM, Matthias Klose wrote: > >> this broke builds configured with --disable-precompiled-headers: > > > > No it didn't. > > it did. The very same build without this flag succeeded. > > > There was no change to HotSpot at all. > > $ diff -urN hotspot-aarch64-jdk8u72-b15 hotspot-aarch64-jdk8u77-b03| diffstat > |less > .hg_archival.txt | > 4 > .hgtags | > 2 > src/cpu/aarch64/vm/aarch64.ad | > 6125 > +++++++--- > src/cpu/aarch64/vm/assembler_aarch64.cpp | > 5 > src/cpu/aarch64/vm/assembler_aarch64.hpp | > 32 > src/cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp | > 32 > src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp | > 39 > src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.hpp | > 8 > src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp | > 4 > src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.hpp | > 1 > src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp | > 59 > src/cpu/aarch64/vm/c2_globals_aarch64.hpp | > 2 > src/cpu/aarch64/vm/compiledIC_aarch64.cpp | > 6 > src/cpu/aarch64/vm/globalDefinitions_aarch64.hpp | > 4 > src/cpu/aarch64/vm/globals_aarch64.hpp | > 12 > src/cpu/aarch64/vm/icBuffer_aarch64.cpp | > 21 > src/cpu/aarch64/vm/interp_masm_aarch64.cpp | > 23 > src/cpu/aarch64/vm/macroAssembler_aarch64.cpp | > 323 > src/cpu/aarch64/vm/macroAssembler_aarch64.hpp | > 118 > src/cpu/aarch64/vm/methodHandles_aarch64.cpp | > 4 > src/cpu/aarch64/vm/nativeInst_aarch64.cpp | > 141 > src/cpu/aarch64/vm/nativeInst_aarch64.hpp | > 75 > src/cpu/aarch64/vm/relocInfo_aarch64.cpp | > 29 > src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp | > 239 > src/cpu/aarch64/vm/stubGenerator_aarch64.cpp | > 6 > src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp | > 4 > src/cpu/aarch64/vm/templateTable_aarch64.cpp | > 12 > src/cpu/aarch64/vm/vm_version_aarch64.cpp | > 8 > src/cpu/aarch64/vm/vtableStubs_aarch64.cpp | > 2 > src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp | > 9 > src/share/vm/adlc/formssel.cpp | > 3 > src/share/vm/gc_implementation/g1/g1CodeCacheRemSet.cpp | > 4 > src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp | > 7 > src/share/vm/opto/callnode.hpp | > 14 > src/share/vm/opto/graphKit.cpp | > 2 > src/share/vm/opto/macro.cpp | > 8 > src/share/vm/opto/memnode.cpp | > 4 > src/share/vm/runtime/arguments.cpp | > 12 > src/share/vm/utilities/globalDefinitions.hpp | > 5 > test/compiler/codegen/8144028/BitTests.java | > 164 > 40 files changed, 5660 insertions(+), 1912 deletions(-) > > > Matthias > > Those changes are from aarch64-jdk8u72-b15 -> aarch64-jdk8u72-b16 and nothing to do with the u77 update. -- 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 From aph at redhat.com Wed Apr 6 16:01:19 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Apr 2016 17:01:19 +0100 Subject: [aarch64-port-dev ] RFR: aarch64: Add Arrays.fill stub code In-Reply-To: References: Message-ID: <570532CF.1050903@redhat.com> On 04/06/2016 01:51 PM, Long Chen wrote: > Please review this patch for generating stub code for ArrayFill on aarch64 > platform. > > Performance test case: > http://people.linaro.org/~long.chen/ArrayFill/ArrayFill.java > Testing result: http://people.linaro.org/~long.chen/ArrayFill/ArrayFill.html > Patch: http://people.linaro.org/~long.chen/ArrayFill/ArrayFill.patch > > At same time, refactoring ClearArrayNode's code generation, as it can be > used by Array fill too. Looks good. Minor nit: + // Generate stub for disjoint fill. If "aligned" is true, the + // "to" address is assumed to be heapword aligned. "disjoint" doesn't make any sense here. > Following up I would like to propose a patch to use DC ZVA for large array > zeroing. OK. I haven't seen much advantage to using DC ZVA, but I'm prepared to listen. Andrew. From aph at redhat.com Wed Apr 6 17:52:10 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Apr 2016 18:52:10 +0100 Subject: [aarch64-port-dev ] RFR: aarch64: Add Arrays.fill stub code In-Reply-To: <570532CF.1050903@redhat.com> References: <570532CF.1050903@redhat.com> Message-ID: <57054CCA.1080900@redhat.com> On 04/06/2016 05:01 PM, Andrew Haley wrote: > On 04/06/2016 01:51 PM, Long Chen wrote: > > >> Following up I would like to propose a patch to use DC ZVA for large array >> zeroing. > > OK. I haven't seen much advantage to using DC ZVA, but I'm > prepared to listen. I just discovered that GCC turns this while (count-- > 0) { *to++ = v; } into a call to a memset() with does DC ZVA. So we have been using DC ZVA in many places in the VM already. Go figure. :-) Andrew. From aph at redhat.com Thu Apr 7 14:25:26 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Apr 2016 15:25:26 +0100 Subject: [aarch64-port-dev ] RFR: aarch64: Add Arrays.fill stub code In-Reply-To: References: <570532CF.1050903@redhat.com> <57054CCA.1080900@redhat.com> Message-ID: <57066DD6.9030508@redhat.com> On 04/07/2016 02:53 PM, Long Chen wrote: > Thanks Adnrew! > > It doesn't make sense for "disjoint fill", comment fixed in http://people.linaro.org/~long.chen/ArrayFill/ArrayFill_v2.patch OK. Andrew. From felix.yang at linaro.org Thu Apr 7 15:01:37 2016 From: felix.yang at linaro.org (Felix Yang) Date: Thu, 7 Apr 2016 23:01:37 +0800 Subject: [aarch64-port-dev ] RFR: 8153713 : aarch64: improve short array clearing using store pair Message-ID: Hi, Please review webrev: http://cr.openjdk.java.net/~fyang/8153713/webrev.00/ JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8153713 Currently, C2 compiler generate independent stores to clear short arrays whose size is no bigger than parameter InitArrayShortSize (refer to ClearArrayNode::Ideal function). For the aarch64 port, we have store pair instruction which can zero two memory words at a time and this will be good for code size and maybe performance for some micro-archs. For Spark Terasort, an extra of 550 stp (xzr, xzr) instructions are generated with the patch, which mean about 2KB reduction in codesize. Tested with JTreg hotspot, langtools and jdk. Is it OK? Thanks, Felix From aph at redhat.com Thu Apr 7 15:33:39 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Apr 2016 16:33:39 +0100 Subject: [aarch64-port-dev ] RFR: aarch64: Add Arrays.fill stub code In-Reply-To: <57066DD6.9030508@redhat.com> References: <570532CF.1050903@redhat.com> <57054CCA.1080900@redhat.com> <57066DD6.9030508@redhat.com> Message-ID: <57067DD3.1090503@redhat.com> On 04/07/2016 03:25 PM, Andrew Haley wrote: > On 04/07/2016 02:53 PM, Long Chen wrote: >> Thanks Adnrew! >> >> It doesn't make sense for "disjoint fill", comment fixed in http://people.linaro.org/~long.chen/ArrayFill/ArrayFill_v2.patch > > OK. By the way, patches which are anywhere other than cr.openjdk.java.net will not be accepted. Please create a webrev and put it there. Andrew. From aph at redhat.com Thu Apr 7 15:35:14 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Apr 2016 16:35:14 +0100 Subject: [aarch64-port-dev ] RFR: 8153713 : aarch64: improve short array clearing using store pair In-Reply-To: References: Message-ID: <57067E32.3010403@redhat.com> On 04/07/2016 04:01 PM, Felix Yang wrote: > Please review webrev: http://cr.openjdk.java.net/~fyang/8153713/webrev.00/ > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8153713 > > Currently, C2 compiler generate independent stores to clear > short arrays whose size is no bigger than parameter > InitArrayShortSize (refer to ClearArrayNode::Ideal function). > For the aarch64 port, we have store pair instruction which can > zero two memory words at a time and this will be good for code > size and maybe performance for some micro-archs. > > For Spark Terasort, an extra of 550 stp (xzr, xzr) instructions > are generated with the patch, which mean about 2KB reduction in > codesize. > > Tested with JTreg hotspot, langtools and jdk. Is it OK? It looks reasonable. It's rather a big slab of code for aarch64.ad, and I think that it should be in MacroAssembler. Long Chen created MacroAssembler::zero_words, and you should create an overload of zero_words which takes a constant int as an argument. Andrew. From edward.nevill at gmail.com Thu Apr 7 22:45:31 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 7 Apr 2016 23:45:31 +0100 Subject: [aarch64-port-dev ] RFR: aarch64: Add Arrays.fill stub code In-Reply-To: <57067DD3.1090503@redhat.com> References: <570532CF.1050903@redhat.com> <57054CCA.1080900@redhat.com> <57066DD6.9030508@redhat.com> <57067DD3.1090503@redhat.com> Message-ID: On Thu, Apr 7, 2016 at 4:33 PM, Andrew Haley wrote: > On 04/07/2016 03:25 PM, Andrew Haley wrote: > > On 04/07/2016 02:53 PM, Long Chen wrote: > >> Thanks Adnrew! > >> > >> It doesn't make sense for "disjoint fill", comment fixed in > http://people.linaro.org/~long.chen/ArrayFill/ArrayFill_v2.patch > > > > OK. > > By the way, patches which are anywhere other than cr.openjdk.java.net > will not be accepted. Please create a webrev and put it there. > What I meant to say was, I would be happy to author this patch for Long Chen http://cr.openjdk.java.net/~enevill/8153797/webrev/ and lets work on getting Long Chen author status so he can author his own patches. OK to push? Ed. From aph at redhat.com Fri Apr 8 08:16:02 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Apr 2016 09:16:02 +0100 Subject: [aarch64-port-dev ] RFR: aarch64: Add Arrays.fill stub code In-Reply-To: References: <570532CF.1050903@redhat.com> <57054CCA.1080900@redhat.com> <57066DD6.9030508@redhat.com> <57067DD3.1090503@redhat.com> Message-ID: <570768C2.2070106@redhat.com> On 07/04/16 23:45, Edward Nevill wrote: > OK to push? Sure, thanks. Andrew. From aph at redhat.com Fri Apr 8 08:19:51 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Apr 2016 09:19:51 +0100 Subject: [aarch64-port-dev ] CompareAndExchangeX Message-ID: <570769A7.7090306@redhat.com> I'm doing the CompareAndExchangeX C1 and C2 intrinsics. Andrew. From felix.yang at linaro.org Fri Apr 8 14:36:02 2016 From: felix.yang at linaro.org (Felix Yang) Date: Fri, 8 Apr 2016 22:36:02 +0800 Subject: [aarch64-port-dev ] RFR: 8153837 : aarch64: handle special cases for MaxINode & MinINode Message-ID: Hi, Please review webrev: *http://cr.openjdk.java.net/~fyang/8153837/webrev.00/ * JIRA Issue: *https://bugs.openjdk.java.net/browse/JDK-8153837 * Patch handles code generation for special cases where one arg is -1/0/1 of MaxINode & MinINode eliminating one extra mov instruction. As shown in the JIRA Issue, I saw some occurrences of the specail cases in specJBB2005 and other benchmarks. The patch does something like this: min(x, 1) => cmp x, 0 csinc x, x, zr, le min(x, -1) => cmp x, 0 csinv x, x, zr, lt max(x, 1) => cmp x, 0 csinc x, x, zr, gt max(x, -1) => cmp x, 0 csinv x, x, zr, ge Tested with JTreg hotspot, langtools. Is it OK? Thanks, Felix From aph at redhat.com Fri Apr 8 14:42:34 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 Apr 2016 15:42:34 +0100 Subject: [aarch64-port-dev ] RFR: 8153837 : aarch64: handle special cases for MaxINode & MinINode In-Reply-To: References: Message-ID: <5707C35A.2060000@redhat.com> On 04/08/2016 03:36 PM, Felix Yang wrote: > Is it OK? It looks good, but I'm surely going to need a jtreg test case which exercises all these patterns in C2. Thanks, Andrew. From edward.nevill at gmail.com Fri Apr 8 20:29:50 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 08 Apr 2016 21:29:50 +0100 Subject: [aarch64-port-dev ] Freeze aarch64/jdk8 In-Reply-To: <56CEE75C.9080102@redhat.com> References: <56CED360.1000000@redhat.com> <1456395940.7333.2.camel@mint> <56CEE75C.9080102@redhat.com> Message-ID: <1460147390.8852.3.camel@mint> On Thu, 2016-02-25 at 11:37 +0000, Andrew Dinn wrote: > > On 25/02/16 10:25, Edward Nevill wrote: > > On Thu, 2016-02-25 at 10:11 +0000, Andrew Haley wrote: > >> The jdk8 development tree at aarch64/jdk8 has been in use for some > >> time. I don't think we need it any more. aarch64/jdk8u tracks > >> upstream jdk8u far more closely: it differs from upstream only in the > >> minimum number of places needed to get AArch64 to work. > > > > Perhaps to close out the jdk8 tree it might be good to backport the following patch > > > > http://openjdk.linaro.org/releases/1602/jdk8/patches/8592.patch > > > > This is a really nasty, critical bug and people are still building from this tree, > > I'm in the process of backporting all missing jdk8 hotspot patches into > jdk8u. Unfortunately, one of the patches applied cleanly but made the > changes in the wrong place (all those 0x1f and 0x3f substitutions for > shifts were carefully misaligned by hg patch into the wrong cases). I > have just started testing a newly patched build which corrects for this > failure. > > regards, Hi, This patch still does not seem to have made it into jdk8u and is still causing random SEGVs in specjbb. May I backport it? Thanks, Ed. From felix.yang at linaro.org Mon Apr 11 11:47:32 2016 From: felix.yang at linaro.org (Felix Yang) Date: Mon, 11 Apr 2016 19:47:32 +0800 Subject: [aarch64-port-dev ] RFR: 8153837 : aarch64: handle special cases for MaxINode & MinINode In-Reply-To: <5707C35A.2060000@redhat.com> References: <5707C35A.2060000@redhat.com> Message-ID: Hi, Thanks for reviewing the patch. I find that the cases the patch tries to catch here are the result of loop transformations. And it's hard to produce a test case to for it simply using the Math.min/max API. (Seems C2 will not create a MaxINode/MinINode for a call for these APIs) But I do noticed some JTReg hotspot test cases that already generates the pattern. Example JTReg test cases: hotspot/test/compiler/rangechecks/TestExplicitRangeChecks.java hotspot/test/compiler/rangechecks/TestBadFoldCompare.java hotspot/test/compiler/rangechecks/PowerOf2SizedArraysChecks.java hotspot/test/compiler/rangechecks/TestRangeCheckSmearing.java For the first test, I saw the following instructions in C1 JIT code: $ grep "csel" JTwork/compiler/rangechecks/TestExplicitRangeChecks.jtr | grep zr | grep gt 0x0000007f9e127e8c: csel w14, w10, wzr, gt 0x0000007f9e129568: csel w11, w12, wzr, gt ;*aload_1 {reexecute=0 rethrow=0 return_oop=0} 0x0000007f9e147c78: csel w12, w11, wzr, gt 0x0000007f9e15c75c: csel w12, w13, wzr, gt 0x0000007f9e1689e4: csel w16, w22, wzr, gt 0x0000007f9e18a570: csel w13, w11, wzr, gt 0x0000007f7e13e278: csel w12, w11, wzr, gt 0x0000007f7e14f55c: csel w13, w13, wzr, gt $ grep "csinc" JTwork/compiler/rangechecks/TestExplicitRangeChecks.jtr 0x0000007f9e112860: csinc w12, w12, wzr, gt 0x0000007f9e120e40: csinc w11, w11, wzr, gt 0x0000007f7e114de0: csinc w12, w12, wzr, gt 0x0000007f7e123440: csinc w11, w11, wzr, gt I also searched the C2 JIT code of specJBB2005 & Spark Terasort and I saw the following csel/csinc/csinv generated with the patch: 1. Spark Terasort: 0x0000007f990ec898: csinc w14, w0, wzr, le 0x0000007f990f3a40: csinv w13, w11, wzr, ge 0x0000007f990f3a94: csinv w11, w13, wzr, ge 0x0000007f9912c1a8: csinc w14, w13, wzr, le 0x0000007f9912afe8: csinc w12, w10, wzr, le ;*aload_1 0x0000007f99137f90: csinv w12, w12, wzr, ge 0x0000007f99137fe4: csinv w13, w12, wzr, ge 0x0000007f99132ff8: csinc w11, w10, wzr, le ;*aload_1 0x0000007f9917fdfc: csinc w12, w15, wzr, le 0x0000007f991a5e3c: csinv w11, w11, wzr, ge 0x0000007f991a5e90: csinv w12, w11, wzr, ge 0x0000007f991133bc: csinc w0, w12, wzr, le 0x0000007f9918e548: csinc w12, w18, wzr, le ;*aload_0 0x0000007f991639f8: csinc w16, w12, wzr, le 0x0000007f99115508: csinc w3, w13, wzr, le 0x0000007f991d7e38: csinc w13, w14, wzr, le ;*aload_1 0x0000007f992f7e48: csinc w12, w13, wzr, le ;*aload_0 0x0000007f992dd578: csinv w13, w10, wzr, ge 0x0000007f992e7370: csinv w17, w14, wzr, ge 0x0000007f99222ec8: csinc w12, w13, wzr, le ;*aload_0 0x0000007f993ae208: csinc w10, w15, wzr, le 0x0000007f99405604: csinc w10, w13, wzr, le 0x0000007f9931da84: csinc w11, w13, wzr, le 0x0000007f9941eb04: csinv w15, w11, wzr, ge ;*lload_0 0x0000007f9941ec4c: csinv w15, w14, wzr, ge ;*iload 0x0000007f994a3110: csinc w11, w13, wzr, le 0x0000007f990e78d8: csel w11, w11, wzr, gt 0x0000007f990dc8e0: csel w11, w12, wzr, gt 0x0000007f990dc8f0: csel w11, w11, wzr, gt 0x0000007f990f5f00: csel w12, w12, wzr, gt 0x0000007f990ff83c: csel w11, w10, wzr, gt 0x0000007f9914e0dc: csel w13, w12, wzr, gt 0x0000007f991504f0: csel w10, w11, wzr, gt 0x0000007f9918cbac: csel w20, w20, wzr, gt 0x0000007f991a32dc: csel w10, w10, wzr, gt 0x0000007f990f3a64: csel w13, w13, wzr, gt 0x0000007f990f3ad0: csel w10, w10, wzr, gt 0x0000007f99114d98: csel w16, w14, wzr, gt 0x0000007f991f0434: csel w0, w10, wzr, gt 0x0000007f9920753c: csel w10, w11, wzr, gt 0x0000007f9920754c: csel w10, w10, wzr, gt 0x0000007f99213270: csel w12, w12, wzr, gt 0x0000007f9923a9f8: csel w18, w15, wzr, gt 0x0000007f99210ad4: csel w11, w11, wzr, gt 0x0000007f9926a524: csel w12, w11, wzr, gt 0x0000007f9929e3d0: csel w10, w11, wzr, gt 0x0000007f9929e3ec: csel w11, w11, wzr, gt 0x0000007f992a6c90: csel w11, w12, wzr, gt 0x0000007f99214044: csel w13, w11, wzr, gt 0x0000007f99242d04: csel w11, w12, wzr, gt 0x0000007f99420260: csel w10, w11, wzr, gt ;*checkcast 0x0000007f993b1d14: csel w12, w12, wzr, gt 0x0000007f993fe15c: csel w11, w11, wzr, gt ;*checkcast 0x0000007f99460688: csel w10, w11, wzr, gt 2. specJBB2005: 0x0000007f7e1233e0: csinc w12, w12, wzr, gt 0x0000007f7e1632f8: csinc w10, w10, wzr, gt 0x0000007f7e1c8a1c: csinv w10, w2, wzr, ge 0x0000007f7e14d2cc: csel w0, w12, wzr, gt 0x0000007f7e19982c: csel w10, w10, wzr, gt ;*baload {reexecute=0 rethrow=0 return_oop=0} 0x0000007f7e1bad4c: csel w12, w3, wzr, gt 0x0000007f7e27e25c: csel w10, w10, wzr, gt ;*baload {reexecute=0 rethrow=0 return_oop=0} So the patch got tested for the most part and is not causing us trouble. On 8 April 2016 at 22:42, Andrew Haley wrote: > On 04/08/2016 03:36 PM, Felix Yang wrote: > > Is it OK? > > It looks good, but I'm surely going to need a jtreg test case > which exercises all these patterns in C2. > > Thanks, > > Andrew. > > From aph at redhat.com Mon Apr 11 11:56:02 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Apr 2016 12:56:02 +0100 Subject: [aarch64-port-dev ] RFR: 8153837 : aarch64: handle special cases for MaxINode & MinINode In-Reply-To: References: <5707C35A.2060000@redhat.com> Message-ID: <570B90D2.5020900@redhat.com> Hi, On 04/11/2016 12:47 PM, Felix Yang wrote: > > Thanks for reviewing the patch. > I find that the cases the patch tries to catch here are the > result of loop transformations. > And it's hard to produce a test case to for it simply using the > Math.min/max API. (Seems C2 will not create a MaxINode/MinINode > for a call for these APIs) But I do noticed some JTReg hotspot > test cases that already generates the pattern. > > So the patch got tested for the most part and is not causing us trouble. Sure, but that doesn't necessarily give us test coverage of the changes you've made. Is the problem that you don't know how to write test cases to cover your changes? Andrew. From felix.yang at linaro.org Mon Apr 11 12:48:02 2016 From: felix.yang at linaro.org (Felix Yang) Date: Mon, 11 Apr 2016 20:48:02 +0800 Subject: [aarch64-port-dev ] RFR: 8153837 : aarch64: handle special cases for MaxINode & MinINode In-Reply-To: <570B90D2.5020900@redhat.com> References: <5707C35A.2060000@redhat.com> <570B90D2.5020900@redhat.com> Message-ID: Hi, Yes, I haven't looked into the details of the loop transformation code and find it hard to produce a test case at least for now. And it seems to me necessary to do so in order to produce a good JTReg test case for the patch. But I am not quite sure if I can come up with a test case which covers all the templates added. Any suggestions? Thanks, Felix On 11 April 2016 at 19:56, Andrew Haley wrote: > Hi, > > On 04/11/2016 12:47 PM, Felix Yang wrote: > > > > Thanks for reviewing the patch. > > > I find that the cases the patch tries to catch here are the > > result of loop transformations. > > And it's hard to produce a test case to for it simply using the > > Math.min/max API. (Seems C2 will not create a MaxINode/MinINode > > for a call for these APIs) But I do noticed some JTReg hotspot > > test cases that already generates the pattern. > > > > So the patch got tested for the most part and is not causing us > trouble. > > Sure, but that doesn't necessarily give us test coverage of the > changes you've made. Is the problem that you don't know how to write > test cases to cover your changes? > > Andrew. > > > From felix.yang at linaro.org Tue Apr 12 10:49:33 2016 From: felix.yang at linaro.org (Felix Yang) Date: Tue, 12 Apr 2016 18:49:33 +0800 Subject: [aarch64-port-dev ] RFR: 8153713 : aarch64: improve short array clearing using store pair In-Reply-To: <57067E32.3010403@redhat.com> References: <57067E32.3010403@redhat.com> Message-ID: Done. New webrev: http://cr.openjdk.java.net/~fyang/8153713/webrev.01 Tested with JTreg hotspot, langtools and jdk. Thanks, Felix On 7 April 2016 at 23:35, Andrew Haley wrote: > On 04/07/2016 04:01 PM, Felix Yang wrote: > > Please review webrev: > http://cr.openjdk.java.net/~fyang/8153713/webrev.00/ > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8153713 > > > > Currently, C2 compiler generate independent stores to clear > > short arrays whose size is no bigger than parameter > > InitArrayShortSize (refer to ClearArrayNode::Ideal function). > > For the aarch64 port, we have store pair instruction which can > > zero two memory words at a time and this will be good for code > > size and maybe performance for some micro-archs. > > > > For Spark Terasort, an extra of 550 stp (xzr, xzr) instructions > > are generated with the patch, which mean about 2KB reduction in > > codesize. > > > > Tested with JTreg hotspot, langtools and jdk. Is it OK? > > It looks reasonable. It's rather a big slab of code for aarch64.ad, > and I think that it should be in MacroAssembler. Long Chen created > MacroAssembler::zero_words, and you should create an overload of > zero_words which takes a constant int as an argument. > > Andrew. > > > From aph at redhat.com Tue Apr 12 12:30:22 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Apr 2016 13:30:22 +0100 Subject: [aarch64-port-dev ] RFR: 8153713 : aarch64: improve short array clearing using store pair In-Reply-To: References: <57067E32.3010403@redhat.com> Message-ID: <570CEA5E.2040208@redhat.com> On 04/12/2016 11:49 AM, Felix Yang wrote: > Done. New webrev: http://cr.openjdk.java.net/~fyang/8153713/webrev.01 That looks fine. Thanks. Andrew. From aph at redhat.com Sat Apr 16 07:59:38 2016 From: aph at redhat.com (Andrew Haley) Date: Sat, 16 Apr 2016 08:59:38 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: References: Message-ID: <5711F0EA.8020106@redhat.com> + void dc(cache_maintenance cm, Register Rt) { + sys(0b011, 0b0111, cm, 0b001, Rt); + } + + void ic(cache_maintenance cm, Register Rt) { + sys(0b011, 0b0111, cm, 0b001, Rt); } Are DC and IC really synonyms? +typedef void (*_zero_Fn)(HeapWord* to, size_t count); + static void pd_fill_to_aligned_words(HeapWord* tohw, size_t count, juint value) { - pd_fill_to_words(tohw, count, value); + if (UseBlockZeroing + && value == 0 + && count >= (size_t)(BlockZeroingLowLimit >> LogHeapWordSize)) { + ((_zero_Fn)StubRoutines::zero_aligned_words())(tohw, count); + } + else { + pd_fill_to_words(tohw, count, value); + } } I'm not convinced of the value of this. We already know that a simple while (count-- > 0) { *to++ = v; } turns into a call to memset() which does DC ZVA. diff --git a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp @@ -4670,11 +4670,54 @@ BLOCK_COMMENT(is_string ? "} string_equals" : "} array_equals"); } + +// base: Address of a buffer to be zeroed, 8 bytes aligned. +// cnt: Count in 8-byte unit. +// is_large: True when 'cnt' is known to be >= BlockZeroingLowLimit. +void MacroAssembler::zero_words(Register base, Register cnt, bool is_large) +{ + if (UseBlockZeroing) { + Label non_block_zeroing; + block_zeroing(base, cnt, non_block_zeroing, is_large); Always use the imperative form of a verb for methods: "block_zero", not, "block_zeroing". // base: Address of a buffer to be zeroed, 8 bytes aligned. -// cnt: Count in 8-byte unit. -void MacroAssembler::zero_words(Register base, Register cnt) +// cnt: Immediate count in 8-byte unit. Please make this // cnt: count in HeapWords Thanks, Andrew. From edward.nevill at gmail.com Mon Apr 18 08:10:51 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 18 Apr 2016 09:10:51 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: References: Message-ID: <1460967051.10749.31.camel@mint> On Fri, 2016-04-15 at 20:45 +0800, Long Chen wrote: > Hi > > Please review this patch making use of DC ZVA to do block zeroing. > > http://people.linaro.org/~long.chen/block_zeroing/block_zeroing.patch > > I?m sorry that I can?t produce a test case matching the ?clear_array? pattern showing obvious improvement. However, generating ?DC ZVA? should be the right thing to do as it usually has better cache behaviors. Besides, gcc and linux?s memset have been using ?DC ZVA?. > Hi Long, Thanks for this. I have benchmarked this on 3 different partners HW using the following JMH test case http://people.linaro.org/~edward.nevill/jmh/test/src/main/java/org/sample/JMHTest_00_StringConcatTest.java On two partners HW I see a significant improvement. On one partners HW I see almost identical performance. Here are the results I get with the original normalised to 100 sec to avoid disclosing any absolute performance figures. Partner A, Original = 100 sec, revised = 100.7 sec Partner B, Original = 100 sec, revised = 97.6 sec Partner C, Original = 100 sec, revised = 91.2 sec One small improvement might be to above using a tmp register which has to be allocated here -instruct clearArray_imm_reg(immL cnt, iRegP base, Universe dummy, rFlagsReg cr) +instruct clearArray_imm_reg(immL cnt, iRegP base, iRegLNoSp tmp, Universe dummy, rFlagsReg cr) - __ zero_words($base$$Register, (u_int64_t)$cnt$$constant); + __ zero_words($base$$Register, (u_int64_t)$cnt$$constant, $tmp$$Register); by using 'lr' as the tmp register here + } else if (UseBlockZeroing && cnt >= (u_int64_t)(BlockZeroingLowLimit >> LogBytesPerWord)) { + mov(tmp, cnt); + zero_words(base, tmp, true); AFAIK, 'lr' is always available as a tmp register in C2 generated code. All the best, Ed. From aph at redhat.com Mon Apr 18 11:45:10 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Apr 2016 12:45:10 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: <1460967051.10749.31.camel@mint> References: <1460967051.10749.31.camel@mint> Message-ID: <5714C8C6.3030302@redhat.com> On 04/18/2016 09:10 AM, Edward Nevill wrote: > I have benchmarked this on 3 different partners HW using the following JMH test case > > http://people.linaro.org/~edward.nevill/jmh/test/src/main/java/org/sample/JMHTest_00_StringConcatTest.java This isn't a great test for block zeroing. Nevertheless, I have approved this patch, with a few alterations. A note about using jmh, not just for you but for everyone working on this project. Don't do something like for (int i = 0; i < 10000; i++) theTest(); as an attempt to pad out the execution time. jmh is much better at this sort of thing than you are. Just put the code you're trying to test in the test case. Andrew. From aph at redhat.com Mon Apr 18 12:55:12 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Apr 2016 13:55:12 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: References: Message-ID: <5714D930.4090804@redhat.com> One other thing. This is rather a lot of code to emit every time an array is created: ;; zero_words { 0x0000007fa880f5f0: cmp x11, #0x20 0x0000007fa880f5f4: b.lt 0x0000007fa880f62c 0x0000007fa880f5f8: neg x8, x10 0x0000007fa880f5fc: and x8, x8, #0x7f 0x0000007fa880f600: cbz x8, 0x0000007fa880f614 0x0000007fa880f604: sub x11, x11, x8, asr #3 0x0000007fa880f608: sub x8, x8, #0x8 0x0000007fa880f60c: str xzr, [x10],#8 0x0000007fa880f610: cbnz x8, 0x0000007fa880f608 0x0000007fa880f614: sub x11, x11, #0x10 0x0000007fa880f618: dc zva, x10 0x0000007fa880f61c: subs x11, x11, #0x10 0x0000007fa880f620: add x10, x10, #0x80 0x0000007fa880f624: b.ge 0x0000007fa880f618 0x0000007fa880f628: add x11, x11, #0x10 0x0000007fa880f62c: and x8, x11, #0x7 I don't think this CBZ does anything useful: 0x0000007fa880f630: cbz x8, 0x0000007fa880f670 (I'm assuming that the 0-7 cases are uniformly distributed.) 0x0000007fa880f634: sub x11, x11, x8 0x0000007fa880f638: add x10, x10, x8, lsl #3 0x0000007fa880f63c: adr x9, 0x0000007fa880f670 0x0000007fa880f640: sub x9, x9, x8, lsl #2 0x0000007fa880f644: br x9 0x0000007fa880f648: add x10, x10, #0x40 0x0000007fa880f64c: sub x11, x11, #0x8 0x0000007fa880f650: stur xzr, [x10,#-64] 0x0000007fa880f654: stur xzr, [x10,#-56] 0x0000007fa880f658: stur xzr, [x10,#-48] 0x0000007fa880f65c: stur xzr, [x10,#-40] 0x0000007fa880f660: stur xzr, [x10,#-32] 0x0000007fa880f664: stur xzr, [x10,#-24] 0x0000007fa880f668: stur xzr, [x10,#-16] 0x0000007fa880f66c: stur xzr, [x10,#-8] 0x0000007fa880f670: cbnz x11, 0x0000007fa880f648 ;; } zero_words We could think about moving the large block case into a stub which is emitted after the main body of the method, or even into a shared stub. A shared stub would require the args to be in fixed registers, though. Andrew. From edward.nevill at gmail.com Tue Apr 19 12:43:44 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 19 Apr 2016 13:43:44 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer Felix Yang Message-ID: <1461069824.22444.6.camel@mylittlepony.linaroharston> I hereby nominate Felix Yang (fyang) to aarch64-port Committer. Felix is a JDK 9 Author. He has contributed 15 patches to JDK 9 [4]. He is also a gcc committer [3]. He is a valued member or our Linaro team and will continue to work to improve OpenJDK. Votes are due by 13:43 PM UTC, Tuesday May 3, 2016. Only current aarch64-port committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Edward Nevill. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://gcc.gnu.org/svn/gcc/trunk/MAINTAINERS (Fei Yang) [4] 1. aarch64: test/compiler/runtime/7196199/Test7196199.java fails https://bugs.openjdk.java.net/browse/JDK-8136524 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e1517978bf12?revcount=1920 2. aarch64: add support for vectorizing fabs/fneg https://bugs.openjdk.java.net/browse/JDK-8138583 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/daf8acf3afda?revcount=1920 3. Disable C2 peephole by default for aarch64 https://bugs.openjdk.java.net/browse/JDK-8138641 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2598332ad46c?revcount=1920 4. aarch64: generate vectorized MLA/MLS instructions https://bugs.openjdk.java.net/browse/JDK-8144587 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f76a6a7bf9dd?revcount=1920 5. aarch64: jdk/test/com/sun/net/httpserver/Test6a.java fails with --enable-unlimited-crypto https://bugs.openjdk.java.net/browse/JDK-8144201 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0d72925dbace?revcount=1920 6. aarch64: redundant lsr instructions in stub code. https://bugs.openjdk.java.net/browse/JDK-8148328 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf349fa14f20?revcount=1920 7. aarch64: Make use of CBZ and CBNZ when comparing narrow pointer with zero https://bugs.openjdk.java.net/browse/JDK-8150038 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fe9e0761c550?revcount=1920 8. aarch64: use load/store pair instructions in call_stub https://bugs.openjdk.java.net/browse/JDK-8149907 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/161aa091d841?revcount=1920 9. aarch64: pipeline class for several instructions is not set correctly https://bugs.openjdk.java.net/browse/JDK-8150229 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/77836bd8ec95?revcount=1920 10. aarch64: prefetch the destination word for write prior to ldxr/stxr loops https://bugs.openjdk.java.net/browse/JDK-8151340 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9e9281592247?revcount=1920 11. aarch64: Make use of CBZ and CBNZ when comparing unsigned values with zero https://bugs.openjdk.java.net/browse/JDK-8152537 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9e2388205f66?revcount=1920 12. aarch64: improve _unsafe_arraycopy stub routine https://bugs.openjdk.java.net/browse/JDK-8152840 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0d2b390d451a?revcount=1920 13. aarch64: hotspot crashes after the 8.1 LSE patch is merged https://bugs.openjdk.java.net/browse/JDK-8153172 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8911d94e888b?revcount=1920 14. C1 segmentation fault due to inline Unsafe::getAndSetObject https://bugs.openjdk.java.net/browse/JDK-8147805 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/609a41177fbe?revcount=1920 15. aarch64: improve short array clearing using store pair https://bugs.openjdk.java.net/browse/JDK-8153713 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f9545cf437eb 16. aarch64: handle special cases for MaxINode & MinINode https://bugs.openjdk.java.net/browse/JDK-8153837 http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2016-April/003327.html (pending) From aph at redhat.com Tue Apr 19 12:52:50 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Apr 2016 13:52:50 +0100 Subject: [aarch64-port-dev ] RFR(S): 8154537: AArch64: some integer rotate instructions are never emitted In-Reply-To: <57161A23.3050807@redhat.com> References: <57161A23.3050807@redhat.com> Message-ID: <57162A22.2050706@redhat.com> On 04/19/2016 12:44 PM, Roland Westrelin wrote: > (src >>> shift) | (src << (32 - shift)) and (src >>> shift) | (src << > -shift) with src an int have some support in the aarch64.ad ad file: > rorI_rReg_Var_C_32 and rorI_rReg_Var_C0 but their definitions is broken > and never match any ideal graph subtree. > > http://cr.openjdk.java.net/~roland/8154537/webrev.00/ OK, thanks. We'll need backports for http://hg.openjdk.java.net/aarch64-port/jdk8u/ and http://hg.openjdk.java.net/aarch64-port/jdk7u/ These should just apply cleanly. Andrew. From adinn at redhat.com Tue Apr 19 12:55:19 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 19 Apr 2016 13:55:19 +0100 Subject: [aarch64-port-dev ] RFR(S): 8154537: AArch64: some integer rotate instructions are never emitted In-Reply-To: <57162A22.2050706@redhat.com> References: <57161A23.3050807@redhat.com> <57162A22.2050706@redhat.com> Message-ID: <57162AB7.6010602@redhat.com> On 19/04/16 13:52, Andrew Haley wrote: > On 04/19/2016 12:44 PM, Roland Westrelin wrote: >> (src >>> shift) | (src << (32 - shift)) and (src >>> shift) | (src << >> -shift) with src an int have some support in the aarch64.ad ad file: >> rorI_rReg_Var_C_32 and rorI_rReg_Var_C0 but their definitions is broken >> and never match any ideal graph subtree. >> >> http://cr.openjdk.java.net/~roland/8154537/webrev.00/ > > OK, thanks. We'll need backports for > http://hg.openjdk.java.net/aarch64-port/jdk8u/ and > http://hg.openjdk.java.net/aarch64-port/jdk7u/ Patch also looks good to me. regards, Andrew Dinn ----------- From aph at redhat.com Tue Apr 19 12:58:50 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Apr 2016 13:58:50 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer Felix Yang In-Reply-To: <1461069824.22444.6.camel@mylittlepony.linaroharston> References: <1461069824.22444.6.camel@mylittlepony.linaroharston> Message-ID: <57162B8A.5060601@redhat.com> On 04/19/2016 01:43 PM, Edward Nevill wrote: > I hereby nominate Felix Yang (fyang) to aarch64-port Committer. OK. Andrew. From aph at redhat.com Tue Apr 19 13:19:31 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Apr 2016 14:19:31 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: References: <5714D930.4090804@redhat.com> Message-ID: <57163063.3020506@redhat.com> On 04/19/2016 01:54 PM, Long Chen wrote: > Thanks for all these nice comments. Here is a revised version: > > http://people.linaro.org/~long.chen/block_zeroing/block_zeroing.v02.patch > > > Changes: > > 1. Are DC and IC really synonyms? > > DC and IC assembling was supposed to be distinguished by different > cache_maintenance parameters. I create two enums ?icache_maintanence? and > ?dcache_maintanence? in the revised patch, to make it look better. > > + enum icache_maintenance {IVAU = 0b0101}; > + enum dcache_maintenance {CVAC = 0b1010, CVAU = 0b1011, CIVAC = 0b1110, > ZVA = 0b100}; > + void dc(dcache_maintenance cm, Register Rt) { > + sys(0b011, 0b0111, cm, 0b001, Rt); > + } > + > + void ic(icache_maintenance cm, Register Rt) { > + sys(0b011, 0b0111, cm, 0b001, Rt); > } That looks better, yes. > 5. To avoid scratching a new register, I write a small piece of code > after the dc zva loop in block_zero, so that block_zero doesn?t need to > fall through to fill_words to zero the small part of array. This code might > not perform as good as fill_words (unrolled), but it requires one less > register, and the code size becomes smaller as well. > The final code is like this: > > 0x0000007f7d3dd4fc: cmp x11, #0x20 > 0x0000007f7d3dd500: b.lt 0x0000007f7d3dd538 > 0x0000007f7d3dd504: neg x8, x10 > 0x0000007f7d3dd508: and x8, x8, #0x3f > 0x0000007f7d3dd50c: cbz x8, 0x0000007f7d3dd520 > 0x0000007f7d3dd510: sub x11, x11, x8, asr #3 > 0x0000007f7d3dd514: sub x8, x8, #0x8 > 0x0000007f7d3dd518: str xzr, [x10],#8 > 0x0000007f7d3dd51c: cbnz x8, 0x0000007f7d3dd514 > 0x0000007f7d3dd520: sub x11, x11, #0x8 > 0x0000007f7d3dd524: dc zva, x10 > 0x0000007f7d3dd528: subs x11, x11, #0x8 > 0x0000007f7d3dd52c: add x10, x10, #0x40 > 0x0000007f7d3dd530: b.ge 0x0000007f7d3dd524 > 0x0000007f7d3dd534: add x11, x11, #0x8 > 0x0000007f7d3dd538: tbz w11, #0, 0x0000007f7d3dd544 > 0x0000007f7d3dd53c: str xzr, [x10],#8 > 0x0000007f7d3dd540: sub x11, x11, #0x1 > 0x0000007f7d3dd544: cbz x11, 0x0000007f7d3dd554 > 0x0000007f7d3dd548: sub x11, x11, #0x2 > 0x0000007f7d3dd54c: stp xzr, xzr, [x10],#16 > 0x0000007f7d3dd550: cbnz x11, 0x0000007f7d3dd548 > > Would this be fine? It might well be. I'd like Ed to do a few measurements of large and small block zeroing. My guess is that a reasonably small unrolled loop doing STP ZR, ZR will work better than anything else, but we'll see. Thanks, Andrew. From chris.plummer at oracle.com Tue Apr 19 16:25:42 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 19 Apr 2016 09:25:42 -0700 (PDT) Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 Message-ID: <57165C06.9040000@oracle.com> Hello, Please review the following diff. I would appreciate it if someone could verify that the open aarch64 port still runs properly after this change. Testing with just "bin/java" should be enough. https://bugs.openjdk.java.net/browse/JDK-8154379 diff --git a/src/cpu/aarch64/vm/globals_aarch64.hpp b/src/cpu/aarch64/vm/globals_aarch64.hpp --- a/src/cpu/aarch64/vm/globals_aarch64.hpp +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp @@ -50,7 +50,7 @@ #define MIN_STACK_YELLOW_PAGES 1 #define MIN_STACK_RED_PAGES 1 -#define MIN_STACK_SHADOW_PAGES 1 +#define MIN_STACK_SHADOW_PAGES DEFAULT_STACK_SHADOW_PAGES #define MIN_STACK_RESERVED_PAGES (0) define_pd_global(intx, StackYellowPages, DEFAULT_STACK_YELLOW_PAGES); thanks, Chris From gnu.andrew at redhat.com Tue Apr 19 22:11:57 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 Apr 2016 18:11:57 -0400 (EDT) Subject: [aarch64-port-dev ] RFR: u91 In-Reply-To: <1456259021.3386672.1461103645814.JavaMail.zimbra@redhat.com> Message-ID: <642807995.3387056.1461103917426.JavaMail.zimbra@redhat.com> Hi, OpenJDK 8 was recently updated with a security update, u91. Here is the corresponding update for aarch64/jdk8u, aarch64-jdk8u91-b14 http://cr.openjdk.java.net/~andrew/aarch64-8/u91/ Ok to push? Incidentally, we'll need to also add a aarch64-jdk8u91-b15 tag to incorporate the AArch64 port of 8132051: Better byte behavior, which was added after aarch64-jdk8u91-b14 was tagged. I suggest we do that together with a merge of the upstream u91 which has just been pushed. Thanks, -- 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 From aph at redhat.com Wed Apr 20 08:33:02 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Apr 2016 09:33:02 +0100 Subject: [aarch64-port-dev ] RFR: u91 In-Reply-To: <642807995.3387056.1461103917426.JavaMail.zimbra@redhat.com> References: <642807995.3387056.1461103917426.JavaMail.zimbra@redhat.com> Message-ID: <57173EBE.8010609@redhat.com> Hi, On 19/04/16 23:11, Andrew Hughes wrote: > OpenJDK 8 was recently updated with a security update, u91. > > Here is the corresponding update for aarch64/jdk8u, aarch64-jdk8u91-b14 > > http://cr.openjdk.java.net/~andrew/aarch64-8/u91/ > > Ok to push? OK. > Incidentally, we'll need to also add a aarch64-jdk8u91-b15 tag to > incorporate the AArch64 port of 8132051: Better byte behavior, > which was added after aarch64-jdk8u91-b14 was tagged. I suggest > we do that together with a merge of the upstream u91 which has > just been pushed. Righto. Andrew. From fridrich.strba at suse.com Wed Apr 20 09:46:58 2016 From: fridrich.strba at suse.com (Fridrich Strba) Date: Wed, 20 Apr 2016 11:46:58 +0200 Subject: [aarch64-port-dev ] RFR: u91 In-Reply-To: <642807995.3387056.1461103917426.JavaMail.zimbra@redhat.com> References: <642807995.3387056.1461103917426.JavaMail.zimbra@redhat.com> Message-ID: <57175012.9020001@suse.com> And u92? Cheers F. On 20/04/16 00:11, Andrew Hughes wrote: > Hi, > > OpenJDK 8 was recently updated with a security update, u91. > > Here is the corresponding update for aarch64/jdk8u, aarch64-jdk8u91-b14 > > http://cr.openjdk.java.net/~andrew/aarch64-8/u91/ > > Ok to push? > > Incidentally, we'll need to also add a aarch64-jdk8u91-b15 tag to > incorporate the AArch64 port of 8132051: Better byte behavior, > which was added after aarch64-jdk8u91-b14 was tagged. I suggest > we do that together with a merge of the upstream u91 which has > just been pushed. > > Thanks, > From edward.nevill at gmail.com Wed Apr 20 11:53:05 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 20 Apr 2016 12:53:05 +0100 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <57165C06.9040000@oracle.com> References: <57165C06.9040000@oracle.com> Message-ID: <1461153185.2941.20.camel@mylittlepony.linaroharston> Hi Chris, On Tue, 2016-04-19 at 09:25 -0700, Chris Plummer wrote: > Hello, > > Please review the following diff. I would appreciate it if someone could > verify that the open aarch64 port still runs properly after this change. > Testing with just "bin/java" should be enough. > > https://bugs.openjdk.java.net/browse/JDK-8154379 > > diff --git a/src/cpu/aarch64/vm/globals_aarch64.hpp > b/src/cpu/aarch64/vm/globals_aarch64.hpp > --- a/src/cpu/aarch64/vm/globals_aarch64.hpp > +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp > @@ -50,7 +50,7 @@ > > #define MIN_STACK_YELLOW_PAGES 1 > #define MIN_STACK_RED_PAGES 1 > -#define MIN_STACK_SHADOW_PAGES 1 > +#define MIN_STACK_SHADOW_PAGES DEFAULT_STACK_SHADOW_PAGES > #define MIN_STACK_RESERVED_PAGES (0) > > define_pd_global(intx, StackYellowPages, DEFAULT_STACK_YELLOW_PAGES); I have patched this and tested it extensively (*). However I wonder if the correct fix is not to back out the following changeset completely? I have also tested this extensively (*). --- cut here --- # HG changeset patch # User enevill # Date 1445940528 0 # Tue Oct 27 10:08:48 2015 +0000 # Node ID 0ecd612047de30414112300f6d315e4fce5c55ee # Parent e7b4c40ebb110615f2ad3be549fd3f2adf0c44a4 8140582: aarch64: jvm fails to initialise after 8078556 Summary: jvm fails to initialise on aarch64 systems with pagesize > 4K Reviewed-by: duke diff -r e7b4c40ebb11 -r 0ecd612047de src/cpu/aarch64/vm/globals_aarch64.hpp --- a/src/cpu/aarch64/vm/globals_aarch64.hpp Tue Oct 27 01:45:01 2015 -0400 +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp Tue Oct 27 10:08:48 2015 +0000 @@ -59,9 +59,9 @@ #define DEFAULT_STACK_RED_PAGES (1) #define DEFAULT_STACK_SHADOW_PAGES (4 DEBUG_ONLY(+5)) -#define MIN_STACK_YELLOW_PAGES DEFAULT_STACK_YELLOW_PAGES -#define MIN_STACK_RED_PAGES DEFAULT_STACK_RED_PAGES -#define MIN_STACK_SHADOW_PAGES DEFAULT_STACK_SHADOW_PAGES +#define MIN_STACK_YELLOW_PAGES 1 +#define MIN_STACK_RED_PAGES 1 +#define MIN_STACK_SHADOW_PAGES 1 define_pd_global(intx, StackYellowPages, DEFAULT_STACK_YELLOW_PAGES); define_pd_global(intx, StackRedPages, DEFAULT_STACK_RED_PAGES); --- cut here --- Backing this out reverts the MIN YELLOW/RED/SHADOW to DEFAULT YELLOW/RED/SHADOW which seems the correct thing to do. The above changeset ( https://bugs.openjdk.java.net/browse/JDK-8140582 ) was to workaround problems introduced by ( https://bugs.openjdk.java.net/browse/JDK-8078556 ) However this has been resolved by ( https://bugs.openjdk.java.net/browse/JDK-8139864 ) so the above change should not be necessary and can be back out. All the best, Ed. (*) I ran java DhryStone From rwestrel at redhat.com Wed Apr 20 12:05:14 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 20 Apr 2016 14:05:14 +0200 Subject: [aarch64-port-dev ] 8u backport: 8154537: AArch64: some integer rotate instructions are never emitted Message-ID: <5717707A.4050708@redhat.com> I'm backporting 8154537 (pushed to 9 yesterday) to http://hg.openjdk.java.net/aarch64-port/jdk8u That patch applies cleanly. Here is the jdk 9 patch for the record: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/52cfeb90ea8b Roland. From rwestrel at redhat.com Wed Apr 20 13:27:50 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Wed, 20 Apr 2016 13:27:50 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 8154537: AArch64: some integer rotate instructions are never emitted Message-ID: <201604201327.u3KDRolj029872@aojmv0008.oracle.com> Changeset: e3c2d68a36ae Author: roland Date: 2016-04-19 19:52 -0700 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/e3c2d68a36ae 8154537: AArch64: some integer rotate instructions are never emitted Reviewed-by: aph, adinn, kvn ! src/cpu/aarch64/vm/aarch64.ad ! test/compiler/codegen/IntRotateWithImmediate.java From gnu.andrew at redhat.com Wed Apr 20 15:52:46 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Apr 2016 11:52:46 -0400 (EDT) Subject: [aarch64-port-dev ] 8u backport: 8154537: AArch64: some integer rotate instructions are never emitted In-Reply-To: <5717707A.4050708@redhat.com> References: <5717707A.4050708@redhat.com> Message-ID: <1968170208.3659069.1461167566475.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I'm backporting 8154537 (pushed to 9 yesterday) to > http://hg.openjdk.java.net/aarch64-port/jdk8u > That patch applies cleanly. Here is the jdk 9 patch for the record: > > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/52cfeb90ea8b > > Roland. > Ok, I'd rather this had waited until after the 8u91 updates had gone in. Thanks, -- 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 From rwestrel at redhat.com Wed Apr 20 15:55:27 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 20 Apr 2016 17:55:27 +0200 Subject: [aarch64-port-dev ] 8u backport: 8154537: AArch64: some integer rotate instructions are never emitted In-Reply-To: <1968170208.3659069.1461167566475.JavaMail.zimbra@redhat.com> References: <5717707A.4050708@redhat.com> <1968170208.3659069.1461167566475.JavaMail.zimbra@redhat.com> Message-ID: <5717A66F.3040607@redhat.com> > Ok, I'd rather this had waited until after the 8u91 updates had gone in. The change is in. I guess I should have waited longer before I pushed it. Sorry about that. Roland. From chris.plummer at oracle.com Wed Apr 20 16:01:36 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 20 Apr 2016 09:01:36 -0700 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <1461153185.2941.20.camel@mylittlepony.linaroharston> References: <57165C06.9040000@oracle.com> <1461153185.2941.20.camel@mylittlepony.linaroharston> Message-ID: <5717A7E0.7000905@oracle.com> On 4/20/16 4:53 AM, Edward Nevill wrote: > Hi Chris, > > On Tue, 2016-04-19 at 09:25 -0700, Chris Plummer wrote: >> Hello, >> >> Please review the following diff. I would appreciate it if someone could >> verify that the open aarch64 port still runs properly after this change. >> Testing with just "bin/java" should be enough. >> >> https://bugs.openjdk.java.net/browse/JDK-8154379 >> >> diff --git a/src/cpu/aarch64/vm/globals_aarch64.hpp >> b/src/cpu/aarch64/vm/globals_aarch64.hpp >> --- a/src/cpu/aarch64/vm/globals_aarch64.hpp >> +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp >> @@ -50,7 +50,7 @@ >> >> #define MIN_STACK_YELLOW_PAGES 1 >> #define MIN_STACK_RED_PAGES 1 >> -#define MIN_STACK_SHADOW_PAGES 1 >> +#define MIN_STACK_SHADOW_PAGES DEFAULT_STACK_SHADOW_PAGES >> #define MIN_STACK_RESERVED_PAGES (0) >> >> define_pd_global(intx, StackYellowPages, DEFAULT_STACK_YELLOW_PAGES); > I have patched this and tested it extensively (*). > > However I wonder if the correct fix is not to back out the following changeset completely? I have also tested this extensively (*). > > --- cut here --- > # HG changeset patch > # User enevill > # Date 1445940528 0 > # Tue Oct 27 10:08:48 2015 +0000 > # Node ID 0ecd612047de30414112300f6d315e4fce5c55ee > # Parent e7b4c40ebb110615f2ad3be549fd3f2adf0c44a4 > 8140582: aarch64: jvm fails to initialise after 8078556 > Summary: jvm fails to initialise on aarch64 systems with pagesize > 4K > Reviewed-by: duke > > diff -r e7b4c40ebb11 -r 0ecd612047de src/cpu/aarch64/vm/globals_aarch64.hpp > --- a/src/cpu/aarch64/vm/globals_aarch64.hpp Tue Oct 27 01:45:01 2015 -0400 > +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp Tue Oct 27 10:08:48 2015 +0000 > @@ -59,9 +59,9 @@ > #define DEFAULT_STACK_RED_PAGES (1) > #define DEFAULT_STACK_SHADOW_PAGES (4 DEBUG_ONLY(+5)) > > -#define MIN_STACK_YELLOW_PAGES DEFAULT_STACK_YELLOW_PAGES > -#define MIN_STACK_RED_PAGES DEFAULT_STACK_RED_PAGES > -#define MIN_STACK_SHADOW_PAGES DEFAULT_STACK_SHADOW_PAGES > +#define MIN_STACK_YELLOW_PAGES 1 > +#define MIN_STACK_RED_PAGES 1 > +#define MIN_STACK_SHADOW_PAGES 1 > > define_pd_global(intx, StackYellowPages, DEFAULT_STACK_YELLOW_PAGES); > define_pd_global(intx, StackRedPages, DEFAULT_STACK_RED_PAGES); > --- cut here --- > > Backing this out reverts the MIN YELLOW/RED/SHADOW to DEFAULT YELLOW/RED/SHADOW which seems the correct thing to do. > > The above changeset ( https://bugs.openjdk.java.net/browse/JDK-8140582 ) was to workaround problems introduced by ( https://bugs.openjdk.java.net/browse/JDK-8078556 ) > > However this has been resolved by ( https://bugs.openjdk.java.net/browse/JDK-8139864 ) so the above change should not be necessary and can be back out. > > All the best, > Ed. > > (*) I ran java DhryStone > > Hi Ed, I think the full backout as you suggest makes sense. I can do that. Thanks for testing. Chris From aph at redhat.com Wed Apr 20 16:05:13 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Apr 2016 17:05:13 +0100 Subject: [aarch64-port-dev ] 8u backport: 8154537: AArch64: some integer rotate instructions are never emitted In-Reply-To: <5717A66F.3040607@redhat.com> References: <5717707A.4050708@redhat.com> <1968170208.3659069.1461167566475.JavaMail.zimbra@redhat.com> <5717A66F.3040607@redhat.com> Message-ID: <5717A8B9.4050502@redhat.com> On 04/20/2016 04:55 PM, Roland Westrelin wrote: >> Ok, I'd rather this had waited until after the 8u91 updates had gone in. > > The change is in. I guess I should have waited longer before I pushed > it. Sorry about that. I didn't think about it either. But I don't expect much in the way of conflicts. Andrew. From gnu.andrew at redhat.com Wed Apr 20 16:42:24 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Apr 2016 12:42:24 -0400 (EDT) Subject: [aarch64-port-dev ] 8u backport: 8154537: AArch64: some integer rotate instructions are never emitted In-Reply-To: <5717A8B9.4050502@redhat.com> References: <5717707A.4050708@redhat.com> <1968170208.3659069.1461167566475.JavaMail.zimbra@redhat.com> <5717A66F.3040607@redhat.com> <5717A8B9.4050502@redhat.com> Message-ID: <1841244894.3672814.1461170544662.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 04/20/2016 04:55 PM, Roland Westrelin wrote: > >> Ok, I'd rather this had waited until after the 8u91 updates had gone in. > > > > The change is in. I guess I should have waited longer before I pushed > > it. Sorry about that. > > I didn't think about it either. But I don't expect much in the way > of conflicts. > > Andrew. > > There's not an issue with conflicts. It just can be a bit confusing that the patch is there, but not part of a tag that occurs later in the history. It also means it will be included when I merge with upstream u91. Maybe it's worth considering a freeze of this tree during the CPU period? Thanks, -- 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 From aph at redhat.com Wed Apr 20 16:46:48 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 20 Apr 2016 17:46:48 +0100 Subject: [aarch64-port-dev ] 8u backport: 8154537: AArch64: some integer rotate instructions are never emitted In-Reply-To: <1841244894.3672814.1461170544662.JavaMail.zimbra@redhat.com> References: <5717707A.4050708@redhat.com> <1968170208.3659069.1461167566475.JavaMail.zimbra@redhat.com> <5717A66F.3040607@redhat.com> <5717A8B9.4050502@redhat.com> <1841244894.3672814.1461170544662.JavaMail.zimbra@redhat.com> Message-ID: <5717B278.80602@redhat.com> On 04/20/2016 05:42 PM, Andrew Hughes wrote: >> > > There's not an issue with conflicts. It just can be a bit confusing > that the patch is there, but not part of a tag that occurs later > in the history. It also means it will be included when I merge > with upstream u91. OK. > Maybe it's worth considering a freeze of this tree during the CPU period? Maybe so. Unless someone announces that the tree is frozen, then it's open for commits. Andrew. From gnu.andrew at redhat.com Wed Apr 20 17:03:08 2016 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 20 Apr 2016 17:03:08 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u: Added tag aarch64-jdk8u91-b14 for changeset ed73b014b78b Message-ID: <201604201703.u3KH3833020963@aojmv0008.oracle.com> Changeset: a633c1615f39 Author: andrew Date: 2016-04-10 22:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/rev/a633c1615f39 Added tag aarch64-jdk8u91-b14 for changeset ed73b014b78b ! .hgtags From gnu.andrew at redhat.com Wed Apr 20 17:03:17 2016 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 20 Apr 2016 17:03:17 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/corba: 2 new changesets Message-ID: <201604201703.u3KH3HBJ021070@aojmv0008.oracle.com> Changeset: b71ea8e84608 Author: asaha Date: 2016-02-28 18:55 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/corba/rev/b71ea8e84608 8150790: 8u75 L10n resource file translation update Summary: 8u75 L10n resource file translation update Reviewed-by: naoto Contributed-by: li.jiang at oracle.com ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties Changeset: 98d2911a9ab6 Author: andrew Date: 2016-04-10 22:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/corba/rev/98d2911a9ab6 Added tag aarch64-jdk8u91-b14 for changeset b71ea8e84608 ! .hgtags From gnu.andrew at redhat.com Wed Apr 20 17:03:27 2016 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 20 Apr 2016 17:03:27 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jaxp: 4 new changesets Message-ID: <201604201703.u3KH3RfX021129@aojmv0008.oracle.com> Changeset: 7d39e87edb4f Author: aefimov Date: 2015-10-30 01:33 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxp/rev/7d39e87edb4f 8134650: Xsl transformation gives different results in 8u66 Reviewed-by: lancea, dfuchs, joehw ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java Changeset: a5d038113460 Author: aefimov Date: 2015-12-05 01:57 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxp/rev/a5d038113460 8143167: Better buffering of XML strings Reviewed-by: joehw, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java Changeset: 3281d2f8342e Author: asaha Date: 2016-02-28 18:58 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxp/rev/3281d2f8342e 8150790: 8u75 L10n resource file translation update Summary: 8u75 L10n resource file translation update Reviewed-by: naoto Contributed-by: li.jiang at oracle.com ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java ! src/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java ! src/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java ! src/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties ! src/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties ! src/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java ! src/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java Changeset: aa843d4029f5 Author: andrew Date: 2016-04-10 22:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxp/rev/aa843d4029f5 Added tag aarch64-jdk8u91-b14 for changeset 3281d2f8342e ! .hgtags From gnu.andrew at redhat.com Wed Apr 20 17:03:37 2016 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 20 Apr 2016 17:03:37 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jaxws: Added tag aarch64-jdk8u91-b14 for changeset a9d0d969559f Message-ID: <201604201703.u3KH3bas021184@aojmv0008.oracle.com> Changeset: d89529722e27 Author: andrew Date: 2016-04-10 22:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jaxws/rev/d89529722e27 Added tag aarch64-jdk8u91-b14 for changeset a9d0d969559f ! .hgtags From gnu.andrew at redhat.com Wed Apr 20 17:03:46 2016 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 20 Apr 2016 17:03:46 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/langtools: Added tag aarch64-jdk8u91-b14 for changeset 2e3153b336d2 Message-ID: <201604201703.u3KH3lD9021256@aojmv0008.oracle.com> Changeset: 6f04a486e5c8 Author: andrew Date: 2016-04-10 22:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/langtools/rev/6f04a486e5c8 Added tag aarch64-jdk8u91-b14 for changeset 2e3153b336d2 ! .hgtags From gnu.andrew at redhat.com Wed Apr 20 17:03:57 2016 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 20 Apr 2016 17:03:57 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 13 new changesets Message-ID: <201604201703.u3KH3veB021341@aojmv0008.oracle.com> Changeset: 13a26b9746b7 Author: ctornqvi Date: 2014-03-27 22:36 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/13a26b9746b7 8007890: [TESTBUG] JcmdWithNMTDisabled.java fails when invoked with NMT explicitly turned on Summary: Wrapped the test in another layer process creation to avoid NMT being turned on. Reviewed-by: coleenp, dcubed ! test/runtime/NMT/JcmdWithNMTDisabled.java Changeset: 9e9243eebe8e Author: kshefov Date: 2016-02-12 18:15 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/9e9243eebe8e 8059661: Test SoftReference and OOM behavior Reviewed-by: coffeys Contributed-by: Alexander Vorobyev + test/gc/TestSoftReferencesBehaviorOnOOME.java Changeset: db9acaeacb90 Author: csahu Date: 2016-01-28 09:41 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/db9acaeacb90 8073735: [TEST_BUG] compiler/loopopts/CountedLoopProblem.java got OOME Summary: Ignore OOM in the test Reviewed-by: kvn ! test/compiler/loopopts/CountedLoopProblem.java Changeset: 1553c7eb74d4 Author: kevinw Date: 2016-01-15 22:33 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/1553c7eb74d4 8132051: Better byte behavior Reviewed-by: coleenp, roland ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86.cpp ! src/cpu/x86/vm/interp_masm_x86.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateTable.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/cpCache.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 1cdd80643ecb Author: kevinw Date: 2016-01-19 15:35 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/1cdd80643ecb 8147567: InterpreterRuntime::post_field_access not updated for boolean in JDK-8132051 Reviewed-by: coleenp ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: 4c03920db43a Author: kevinw Date: 2016-02-08 13:08 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/4c03920db43a 8148475: Missing SA Bytecode updates. Reviewed-by: coleenp ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java Changeset: 2c0ab6b6c813 Author: simonis Date: 2016-01-27 15:01 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/2c0ab6b6c813 8148487: PPC64: Better byte behavior Reviewed-by: goetz, mdoerr ! src/cpu/ppc/vm/interp_masm_ppc_64.cpp ! src/cpu/ppc/vm/interp_masm_ppc_64.hpp ! src/cpu/ppc/vm/interpreter_ppc.cpp ! src/cpu/ppc/vm/templateInterpreter_ppc.cpp ! src/cpu/ppc/vm/templateTable_ppc_64.cpp Changeset: 8c47e16b490e Author: kevinw Date: 2016-02-10 13:34 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/8c47e16b490e 8149170: Better byte behavior for native arguments Summary: Arguments coming from native should be converted to 0=false, 1-255=true Reviewed-by: coleenp ! src/share/vm/prims/jni.cpp Changeset: dfe539c2e181 Author: kevinw Date: 2016-02-23 23:47 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/dfe539c2e181 8149367: PolicyQualifierInfo/index_Ctor JCk test fails with IOE: Invalid encoding for PolicyQualifierInfo Summary: fix incorrect code Reviewed-by: kvn, coleenp ! src/share/vm/runtime/deoptimization.cpp Changeset: 8e05c47f805f Author: coleenp Date: 2016-02-21 08:33 -0500 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/8e05c47f805f 8150012: Better byte behavior for reflection Reviewed-by: kvn, jrose, kevinw, ahgross ! src/share/vm/oops/typeArrayOop.hpp Changeset: e2b90ce9a1d1 Author: andrew Date: 2016-04-10 22:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/e2b90ce9a1d1 Added tag aarch64-jdk8u91-b14 for changeset 8e05c47f805f ! .hgtags Changeset: 388e9d0905e6 Author: aph Date: 2016-04-11 11:33 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/388e9d0905e6 8132051: Better byte behavior Reviewed-by: adinn ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/aarch64/vm/interp_masm_aarch64.cpp ! src/cpu/aarch64/vm/interp_masm_aarch64.hpp ! src/cpu/aarch64/vm/templateTable_aarch64.cpp Changeset: 56b06919734b Author: andrew Date: 2016-04-20 18:02 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/56b06919734b Merge From gnu.andrew at redhat.com Wed Apr 20 17:04:09 2016 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 20 Apr 2016 17:04:09 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/jdk: 20 new changesets Message-ID: <201604201704.u3KH49UD021398@aojmv0008.oracle.com> Changeset: 1b87cb7b6d8b Author: dsamersoff Date: 2016-01-22 16:12 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/1b87cb7b6d8b 8002116: This JdbReadTwiceTest.sh gets an exit 1 Summary: Explicitly check readability of file in question Reviewed-by: sla, dholmes, olagneau ! test/com/sun/jdi/JdbReadTwiceTest.sh Changeset: 0638b09b899b Author: sla Date: 2016-01-22 17:58 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/0638b09b899b 8036132: Tab characters in test/com/sun/jdi files Reviewed-by: alanb, mikael ! test/com/sun/jdi/CatchPatternTest.sh ! test/com/sun/jdi/GetLocalVariables4Test.sh ! test/com/sun/jdi/JdbReadTwiceTest.sh ! test/com/sun/jdi/NullLocalVariable.sh ! test/com/sun/jdi/PrivateTransportTest.sh ! test/com/sun/jdi/RedefineFinal.sh ! test/com/sun/jdi/RedefineIntConstantToLong.sh ! test/com/sun/jdi/StringConvertTest.sh ! test/com/sun/jdi/SuspendNoFlagTest.sh Changeset: d0e779dd55b9 Author: kshefov Date: 2016-02-15 14:43 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/d0e779dd55b9 8038963: com/sun/jdi tests fail because cygwin's ps sometimes misses processes Reviewed-by: coffeys ! test/com/sun/jdi/ShellScaffold.sh Changeset: a35481eb16ac Author: ykantser Date: 2016-01-22 18:04 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/a35481eb16ac 8044419: TEST_BUG: com/sun/jdi/JdbReadTwiceTest.sh fails when run under root Reviewed-by: dsamersoff, sla Contributed-by: mattias.tobiasson at oracle.com ! test/com/sun/jdi/JdbReadTwiceTest.sh Changeset: 2840655de5ba Author: dsamersoff Date: 2016-01-22 18:06 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/2840655de5ba 8074146: [TEST_BUG] jdb has succeded to read an unreadable file Summary: Remove this testcase Reviewed-by: sla, egahlin ! test/com/sun/jdi/JdbReadTwiceTest.sh Changeset: d55480081ed6 Author: robm Date: 2016-01-25 14:07 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/d55480081ed6 8129952: Ensure thread consistency Reviewed-by: chegar ! src/share/classes/java/io/ObjectInputStream.java Changeset: 387e211e84e0 Author: igerasim Date: 2015-11-27 10:59 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/387e211e84e0 8134297: NPE in GSSNameElement nameType check Reviewed-by: xuelei ! src/share/classes/sun/security/jgss/wrapper/GSSNameElement.java Changeset: 3625e8f95863 Author: igerasim Date: 2015-12-24 08:42 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/3625e8f95863 8138593: Make DSA more fair Summary: Changed nounce K generation to FIPS 186-4 B2.1 Reviewed-by: mullan ! src/share/classes/sun/security/provider/DSA.java ! test/java/security/Signature/TestInitSignWithMyOwnRandom.java ! test/sun/security/provider/DSA/TestDSA2.java Changeset: b6e94d7710f2 Author: vadim Date: 2015-10-20 12:08 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/b6e94d7710f2 8139008: Better state table management Reviewed-by: prr, srl, mschoene ! src/share/native/sun/font/layout/StateTableProcessor2.cpp Changeset: 20b718f7d39b Author: vadim Date: 2015-11-18 12:18 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/20b718f7d39b 8141229: [Parfait] Null pointer dereference in cmsstrcasecmp of cmserr.c Reviewed-by: prr, serb ! src/share/native/sun/java2d/cmm/lcms/cmscgats.c Changeset: 27e87873dfe3 Author: vadim Date: 2015-12-10 12:13 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/27e87873dfe3 8143002: [Parfait] JNI exception pending in fontpath.c:1300 Reviewed-by: prr, serb ! src/solaris/native/sun/awt/fontpath.c Changeset: 57ea4a1ac8d7 Author: ascarpino Date: 2015-12-21 10:43 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/57ea4a1ac8d7 8143945: Better GCM validation Reviewed-by: xuelei, mullan ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Changeset: 6b03c6b870f4 Author: sjiang Date: 2016-01-22 13:41 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/6b03c6b870f4 8144430: Improve JMX connections Reviewed-by: dfuchs, jbachorik, skoivu ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java ! src/share/classes/sun/management/jmxremote/ConnectorBootstrap.java + src/share/classes/sun/misc/JavaObjectInputStreamAccess.java + src/share/classes/sun/misc/ObjectStreamClassValidator.java ! src/share/classes/sun/misc/SharedSecrets.java + src/share/classes/sun/rmi/server/DeserializationChecker.java ! src/share/classes/sun/rmi/server/MarshalInputStream.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java Changeset: 47b9ded5921d Author: coffeys Date: 2016-01-08 16:21 +0000 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/47b9ded5921d 8146477: [TEST_BUG] ClientJSSEServerJSSE.java failing again Reviewed-by: mullan ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Changeset: c6782e9d11c4 Author: prr Date: 2016-01-13 11:28 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/c6782e9d11c4 8146494: Better ligature substitution Reviewed-by: vadim, mschoene ! src/share/native/sun/font/layout/LigatureSubstProc.cpp ! src/share/native/sun/font/layout/LigatureSubstProc2.cpp Changeset: 42074f34351e Author: prr Date: 2016-01-13 11:28 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/42074f34351e 8146498: Better device table adjustments Reviewed-by: vadim, mschoene ! src/share/native/sun/font/layout/DeviceTables.cpp Changeset: bf3e62dcf0f4 Author: igerasim Date: 2016-01-15 11:49 +0300 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/bf3e62dcf0f4 8146967: [TEST_BUG] javax/security/auth/SubjectDomainCombiner/Optimize.java should use 4-args ProtectionDomain constructor Reviewed-by: mullan, valeriep ! test/javax/security/auth/SubjectDomainCombiner/Optimize.java Changeset: 44a76f73864d Author: rpatil Date: 2016-02-12 00:13 +0530 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/44a76f73864d 8148446: (tz) Support tzdata2016a Reviewed-by: okutsu, aefimov ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/backward ! make/data/tzdata/europe ! make/data/tzdata/northamerica ! make/data/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/de/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/es/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/fr/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/it/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/ja/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/ko/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/pt/TimeZoneNames_pt_BR.java ! src/share/classes/sun/util/resources/sv/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_TW.java ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/zone.tab Changeset: e559bd990501 Author: asaha Date: 2016-02-28 18:59 -0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/e559bd990501 8150790: 8u75 L10n resource file translation update Summary: 8u75 L10n resource file translation update Reviewed-by: naoto Contributed-by: li.jiang at oracle.com ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/share/classes/sun/awt/resources/awt_de.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/security/tools/keytool/Resources_de.java ! src/share/classes/sun/security/tools/policytool/Resources_ko.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/tools/jar/resources/jar_ko.properties Changeset: 0e757f8bf24c Author: andrew Date: 2016-04-10 22:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/rev/0e757f8bf24c Added tag aarch64-jdk8u91-b14 for changeset e559bd990501 ! .hgtags From gnu.andrew at redhat.com Wed Apr 20 17:04:17 2016 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 20 Apr 2016 17:04:17 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/nashorn: Added tag aarch64-jdk8u91-b14 for changeset 6c5e2fc0638d Message-ID: <201604201704.u3KH4HYE021485@aojmv0008.oracle.com> Changeset: 68091b9af73e Author: andrew Date: 2016-04-10 22:47 +0100 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/nashorn/rev/68091b9af73e Added tag aarch64-jdk8u91-b14 for changeset 6c5e2fc0638d ! .hgtags From gnu.andrew at redhat.com Wed Apr 20 17:04:18 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Apr 2016 13:04:18 -0400 (EDT) Subject: [aarch64-port-dev ] RFR: u91 In-Reply-To: <57175012.9020001@suse.com> References: <642807995.3387056.1461103917426.JavaMail.zimbra@redhat.com> <57175012.9020001@suse.com> Message-ID: <662452318.3681476.1461171858857.JavaMail.zimbra@redhat.com> ----- Original Message ----- > And u92? > I'll look at that once OpenJDK 6 & 7 updates are out. -- 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 From edward.nevill at gmail.com Wed Apr 20 17:08:30 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 20 Apr 2016 18:08:30 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: <57163063.3020506@redhat.com> References: <5714D930.4090804@redhat.com> <57163063.3020506@redhat.com> Message-ID: <1461172110.2941.63.camel@mylittlepony.linaroharston> On Tue, 2016-04-19 at 14:19 +0100, Andrew Haley wrote: > On 04/19/2016 01:54 PM, Long Chen wrote: > > Would this be fine? > > It might well be. I'd like Ed to do a few measurements of large and > small block zeroing. My guess is that a reasonably small unrolled loop > doing STP ZR, ZR will work better than anything else, but we'll see. OK. So I started by doing some basic measurements of how long it takes to clear a cache line on 3 different partners HW using 3 different methods. 1) A sequence of str zr, [base, #N] instructions 2) A sequence of stp zr, zr, [base, #N] instructions 3) Using dc zva Each test was repeated for 3 different memory sizes, 100 cache lines, 10000 cache lines and 1E7 cache lines to simulate the cases where we are hitting L1, L2 and main memory respectively. The results are here. I have normalised the time for the 100 cache line str to 100 for each partner to avoid disclosing any absolute performance figures. http://people.linaro.org/~edward.nevill/block_zero/zva.pdf >From this I get the following conclusions Partner X: - Significant improvement using stp vs str across all block zero sizes - Significant improvement using dc zva over stp across all sizes Partner Y: - Virtually no performance improvement using stp vs str all sizes - Significant improvement using dc zva Partner Z: - Small improvement using stp vs str on L2 sized clears - Small improvement using dc zva on L1/L2 sizes clears - Large block zeros show no performance improvement str/stp/dc zva (this is probably a feature of the external memory system on the partner Z board) So, guided by this I modified the block zeroing patch as follows if (!small) { } Here is the webrev for this http://people.linaro.org/~edward.nevill/block_zero/block_zeroing.v03/ I also made a minor modifcation to Long Chen's v02 patch. In the following code + tbz(cnt, 0, store_pair); + str(zr, Address(post(base, 8))); + sub(cnt, cnt, 1); + bind(store_pair); + cbz(cnt, done); + bind(loop_store_pair); + sub(cnt, cnt, 2); + stp(zr, zr, Address(post(base, 16))); + cbnz(cnt, loop_store_pair); + bind(done); it unnecessarily misaligns the base before continuing to do the stps. We know the base is aligned in the large case because it has just finished clearing cache lines. I moved the single word zero to the end. The number of instructions is the same. The webrev for this is here. http://people.linaro.org/~edward.nevill/block_zero/block_zeroing.v04 For completeness I also implemented a version using stp only and not using dc zva at all. Webrev here http://people.linaro.org/~edward.nevill/block_zero/stp I have tested all of these, including Long Chens v01 and v02 patches using jmh as before (http://people.linaro.org/~edward.nevill/jmh/test/src/main/java/org/sample/JMHTest_00_StringConcatTest.java) Results are here, I have normalised the original value in each case to 1E7uS to avoid disclosing any absolute performance figures. http://people.linaro.org/~edward.nevill/block_zero/zero.pdf In this orig - is a clean jdk9/hs-comp build (results normalised to 1E7uS) stp - is the stp patch above using only stps (no dc zva) bzero1 - is Long Chens v01 patch bzero2 - is Long Chens v02 patch bzero3 - is my patch above bzero4 - is Long Chens v02 patch with the minor mod to avoid misaligning the stps >From this it looks like bzero3 or bzero4 would be the preferred options, and I would suggest bzero4 as bzero3 is significantly larger. If people are happy could I prepare final changeset for review based on bzero4 (ie this one) http://people.linaro.org/~edward.nevill/block_zero/block_zeroing.v04 All the best, Ed. From gnu.andrew at redhat.com Wed Apr 20 17:18:44 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Apr 2016 13:18:44 -0400 (EDT) Subject: [aarch64-port-dev ] 8u backport: 8154537: AArch64: some integer rotate instructions are never emitted In-Reply-To: <5717B278.80602@redhat.com> References: <5717707A.4050708@redhat.com> <1968170208.3659069.1461167566475.JavaMail.zimbra@redhat.com> <5717A66F.3040607@redhat.com> <5717A8B9.4050502@redhat.com> <1841244894.3672814.1461170544662.JavaMail.zimbra@redhat.com> <5717B278.80602@redhat.com> Message-ID: <846854971.3683284.1461172724995.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 04/20/2016 05:42 PM, Andrew Hughes wrote: > >> > > > There's not an issue with conflicts. It just can be a bit confusing > > that the patch is there, but not part of a tag that occurs later > > in the history. It also means it will be included when I merge > > with upstream u91. > > OK. > > > Maybe it's worth considering a freeze of this tree during the CPU period? > > Maybe so. Unless someone announces that the tree is frozen, then it's open > for commits. > Ok, I'll announce such a freeze for the next CPU, if that's ok with you. > Andrew. > > -- 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 From adinn at redhat.com Thu Apr 21 07:43:41 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 21 Apr 2016 08:43:41 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: <1461172110.2941.63.camel@mylittlepony.linaroharston> References: <5714D930.4090804@redhat.com> <57163063.3020506@redhat.com> <1461172110.2941.63.camel@mylittlepony.linaroharston> Message-ID: <571884AD.1030906@redhat.com> On 20/04/16 18:08, Edward Nevill wrote: > If people are happy could I prepare final changeset for review based on bzero4 (ie this one) > > http://people.linaro.org/~edward.nevill/block_zero/block_zeroing.v04 Yeah, science rocks! bzero4 is it for me but you need a nod from the boss. regards, Andrew Dinn ----------- From adinn at redhat.com Thu Apr 21 07:46:09 2016 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 21 Apr 2016 08:46:09 +0100 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <5717A7E0.7000905@oracle.com> References: <57165C06.9040000@oracle.com> <1461153185.2941.20.camel@mylittlepony.linaroharston> <5717A7E0.7000905@oracle.com> Message-ID: <57188541.1010109@redhat.com> On 20/04/16 17:01, Chris Plummer wrote: > I think the full backout as you suggest makes sense. I can do that. > Thanks for testing. Sorry, I meant to add yesterday that I agree this is the best fix but was distracted from replying by other things. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul Argiry (US) From chris.plummer at oracle.com Thu Apr 21 20:23:03 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 21 Apr 2016 13:23:03 -0700 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <57188541.1010109@redhat.com> References: <57165C06.9040000@oracle.com> <1461153185.2941.20.camel@mylittlepony.linaroharston> <5717A7E0.7000905@oracle.com> <57188541.1010109@redhat.com> Message-ID: <571936A7.5040702@oracle.com> On 4/21/16 12:46 AM, Andrew Dinn wrote: > On 20/04/16 17:01, Chris Plummer wrote: >> I think the full backout as you suggest makes sense. I can do that. >> Thanks for testing. > Sorry, I meant to add yesterday that I agree this is the best fix but > was distracted from replying by other things. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul > Argiry (US) Thanks Andrew. So I'll count you and Ed as reviewers if that's ok. I'll push the diff that undoes 8140582: rc/cpu/aarch64/vm/globals_aarch64.hpp b/src/cpu/aarch64/vm/globals_aarch64.hpp --- a/src/cpu/aarch64/vm/globals_aarch64.hpp +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp @@ -48,9 +48,9 @@ #define DEFAULT_STACK_SHADOW_PAGES (4 DEBUG_ONLY(+5)) #define DEFAULT_STACK_RESERVED_PAGES (0) -#define MIN_STACK_YELLOW_PAGES 1 -#define MIN_STACK_RED_PAGES 1 -#define MIN_STACK_SHADOW_PAGES 1 +#define MIN_STACK_YELLOW_PAGES DEFAULT_STACK_YELLOW_PAGES +#define MIN_STACK_RED_PAGES DEFAULT_STACK_RED_PAGES +#define MIN_STACK_SHADOW_PAGES DEFAULT_STACK_SHADOW_PAGES #define MIN_STACK_RESERVED_PAGES (0) define_pd_global(intx, StackYellowPages, DEFAULT_STACK_YELLOW_PAGES); thanks, Chris From chris.plummer at oracle.com Thu Apr 21 20:52:13 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 21 Apr 2016 13:52:13 -0700 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <571936A7.5040702@oracle.com> References: <57165C06.9040000@oracle.com> <1461153185.2941.20.camel@mylittlepony.linaroharston> <5717A7E0.7000905@oracle.com> <57188541.1010109@redhat.com> <571936A7.5040702@oracle.com> Message-ID: <57193D7D.3090105@oracle.com> On 4/21/16 1:23 PM, Chris Plummer wrote: > On 4/21/16 12:46 AM, Andrew Dinn wrote: >> On 20/04/16 17:01, Chris Plummer wrote: >>> I think the full backout as you suggest makes sense. I can do that. >>> Thanks for testing. >> Sorry, I meant to add yesterday that I agree this is the best fix but >> was distracted from replying by other things. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in UK and Wales under Company Registration No. 3798903 >> Directors: Michael Cunningham (US), Michael O'Neill (Ireland), Paul >> Argiry (US) > Thanks Andrew. So I'll count you and Ed as reviewers if that's ok. > I'll push the diff that undoes 8140582: > > rc/cpu/aarch64/vm/globals_aarch64.hpp > b/src/cpu/aarch64/vm/globals_aarch64.hpp > --- a/src/cpu/aarch64/vm/globals_aarch64.hpp > +++ b/src/cpu/aarch64/vm/globals_aarch64.hpp > @@ -48,9 +48,9 @@ > #define DEFAULT_STACK_SHADOW_PAGES (4 DEBUG_ONLY(+5)) > #define DEFAULT_STACK_RESERVED_PAGES (0) > > -#define MIN_STACK_YELLOW_PAGES 1 > -#define MIN_STACK_RED_PAGES 1 > -#define MIN_STACK_SHADOW_PAGES 1 > +#define MIN_STACK_YELLOW_PAGES DEFAULT_STACK_YELLOW_PAGES > +#define MIN_STACK_RED_PAGES DEFAULT_STACK_RED_PAGES > +#define MIN_STACK_SHADOW_PAGES DEFAULT_STACK_SHADOW_PAGES > #define MIN_STACK_RESERVED_PAGES (0) > > define_pd_global(intx, StackYellowPages, DEFAULT_STACK_YELLOW_PAGES); > > thanks, > > Chris > BTW, does one of the reviewers need Reviewer status for aarch64 pushes? Chris From aph at redhat.com Fri Apr 22 08:44:22 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Apr 2016 09:44:22 +0100 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <57193D7D.3090105@oracle.com> References: <57165C06.9040000@oracle.com> <1461153185.2941.20.camel@mylittlepony.linaroharston> <5717A7E0.7000905@oracle.com> <57188541.1010109@redhat.com> <571936A7.5040702@oracle.com> <57193D7D.3090105@oracle.com> Message-ID: <5719E466.1040303@redhat.com> On 21/04/16 21:52, Chris Plummer wrote: > BTW, does one of the reviewers need Reviewer status for aarch64 pushes? Yes. OK, thanks. Andrew. From aph at redhat.com Fri Apr 22 08:57:14 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Apr 2016 09:57:14 +0100 Subject: [aarch64-port-dev ] New forest: aarch64-port/jdk8u-shenandoah/ Message-ID: <5719E76A.9020602@redhat.com> http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ This is an integration forest for AArch64 JDK8u and the Shenandoah GC. It's not for development: all changes will come either from the Shenandoah project repositories or from aarch64-port/jdk8u. It should be kept up-to-date with aarch64-port/jdk8u, which in turn should be kept up-to-date with jdk8u upstream. Because Shenandoah only touches HotSpot, the other trees should be no different from aarch64-port/jdk8u. All changes should be posted here. Changes from the two feeder repositories will usually be automatically accepted. At Red Hat we'll be using this forest to make preview packages available to developers who are interested in Shenandoah and want to kick the tyres. Andrew. From rkennke at redhat.com Fri Apr 22 13:55:19 2016 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 22 Apr 2016 15:55:19 +0200 Subject: [aarch64-port-dev ] Initial import from shenandoah/jdk8u/hotspot Message-ID: <1461333319.4482.79.camel@redhat.com> Hi there, I would like to push the initial import of Shenandoah code from ?http://hg.openjdk.java.net/shenandoah/jdk8u/hotspot I uplaoded a summary of all the changesets that would get pushed to: http://cr.openjdk.java.net/~rkennke/jdk8u-aarch64-shenandoah-changsets. txt Unfortunately, webrev doesn't seem to work well with many changesets like this. It can do it, but it ain't pretty :-) http://cr.openjdk.java.net/~rkennke/jdk8u-aarch64-shenandoah/webrev.00/ (still uploading as I write this, it might take a while to complete...) Unfortunately this includes some stuff from? http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot that is not in aarch64-port yet. In particular, that's everything between?jdk8u71-b15 (the point where aarch64-port/jdk8u is) up to?jdk8u82-b00 (the point where shenandoah/jdk8u is). Upstream is currently at?jdk8u102-b03, so we might want to bring both aarch64- port/jdk8u and shenandoah/jdk8u up to that first? Roman From rkennke at redhat.com Fri Apr 22 13:57:07 2016 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 22 Apr 2016 15:57:07 +0200 Subject: [aarch64-port-dev ] New forest: aarch64-port/jdk8u-shenandoah/ In-Reply-To: <5719E76A.9020602@redhat.com> References: <5719E76A.9020602@redhat.com> Message-ID: <1461333427.4482.81.camel@redhat.com> Am Freitag, den 22.04.2016, 09:57 +0100 schrieb Andrew Haley: > http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ > > This is an integration forest for AArch64 JDK8u and the Shenandoah > GC. Great! > It's not for development: all changes will come either from the > Shenandoah project repositories or from aarch64-port/jdk8u. Probably with one exception: Shenandoah support for Aarch64 needs to be backported from Shenandoah's jdk9 repo, or so. Right? Roman From aph at redhat.com Fri Apr 22 14:36:36 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Apr 2016 15:36:36 +0100 Subject: [aarch64-port-dev ] New forest: aarch64-port/jdk8u-shenandoah/ In-Reply-To: <1461333427.4482.81.camel@redhat.com> References: <5719E76A.9020602@redhat.com> <1461333427.4482.81.camel@redhat.com> Message-ID: <571A36F4.4070407@redhat.com> On 04/22/2016 02:57 PM, Roman Kennke wrote: > Probably with one exception: Shenandoah support for Aarch64 needs to be > backported from Shenandoah's jdk9 repo, or so. Right? I guess so. I rather expected you to have a jdk8 Shenandoah repo that you use for Shenandoah development. I think you should. Andrew. From rkennke at redhat.com Fri Apr 22 14:40:20 2016 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 22 Apr 2016 16:40:20 +0200 Subject: [aarch64-port-dev ] New forest: aarch64-port/jdk8u-shenandoah/ In-Reply-To: <571A36F4.4070407@redhat.com> References: <5719E76A.9020602@redhat.com> <1461333427.4482.81.camel@redhat.com> <571A36F4.4070407@redhat.com> Message-ID: <1461336020.4482.82.camel@redhat.com> Am Freitag, den 22.04.2016, 15:36 +0100 schrieb Andrew Haley: > On 04/22/2016 02:57 PM, Roman Kennke wrote: > > > > Probably with one exception: Shenandoah support for Aarch64 needs > > to be > > backported from Shenandoah's jdk9 repo, or so. Right? > I guess so.??I rather expected you to have a jdk8 Shenandoah repo > that > you use for Shenandoah development.??I think you should. Well yeah, we do, but we have no aarch64 stuff in it :-) Unless it's already in upstream jdk8u, which I don't think it is. Or is it? Roman From aph at redhat.com Fri Apr 22 16:12:35 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Apr 2016 17:12:35 +0100 Subject: [aarch64-port-dev ] Repo busted Message-ID: <571A4D73.4000709@redhat.com> A recent HotSpot merge seems to have broken jdk9/hs/hotspot for AArch64. I'm on it. Andrew. From chris.plummer at oracle.com Fri Apr 22 16:26:17 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Apr 2016 09:26:17 -0700 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <5719E466.1040303@redhat.com> References: <57165C06.9040000@oracle.com> <1461153185.2941.20.camel@mylittlepony.linaroharston> <5717A7E0.7000905@oracle.com> <57188541.1010109@redhat.com> <571936A7.5040702@oracle.com> <57193D7D.3090105@oracle.com> <5719E466.1040303@redhat.com> Message-ID: <571A50A9.2070800@oracle.com> On 4/22/16 1:44 AM, Andrew Haley wrote: > On 21/04/16 21:52, Chris Plummer wrote: >> BTW, does one of the reviewers need Reviewer status for aarch64 pushes? > Yes. OK, thanks. > > Andrew. > Hi Andrew, Are you approving the change? thanks Chris From aph at redhat.com Fri Apr 22 16:55:38 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Apr 2016 17:55:38 +0100 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <571A50A9.2070800@oracle.com> References: <57165C06.9040000@oracle.com> <1461153185.2941.20.camel@mylittlepony.linaroharston> <5717A7E0.7000905@oracle.com> <57188541.1010109@redhat.com> <571936A7.5040702@oracle.com> <57193D7D.3090105@oracle.com> <5719E466.1040303@redhat.com> <571A50A9.2070800@oracle.com> Message-ID: <571A578A.8080503@redhat.com> On 04/22/2016 05:26 PM, Chris Plummer wrote: > Are you approving the change? Yes. Andrew. From chris.plummer at oracle.com Fri Apr 22 18:12:51 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 22 Apr 2016 11:12:51 -0700 Subject: [aarch64-port-dev ] RFR(XXS) JDK-8154379: MIN_STACK_SHADOW_PAGES should equal DEFAULT_STACK_SHADOW_PAGES on aarch64 In-Reply-To: <571A578A.8080503@redhat.com> References: <57165C06.9040000@oracle.com> <1461153185.2941.20.camel@mylittlepony.linaroharston> <5717A7E0.7000905@oracle.com> <57188541.1010109@redhat.com> <571936A7.5040702@oracle.com> <57193D7D.3090105@oracle.com> <5719E466.1040303@redhat.com> <571A50A9.2070800@oracle.com> <571A578A.8080503@redhat.com> Message-ID: <571A69A3.8050908@oracle.com> On 4/22/16 9:55 AM, Andrew Haley wrote: > On 04/22/2016 05:26 PM, Chris Plummer wrote: >> Are you approving the change? > Yes. > > Andrew. > Thank you. From edward.nevill at gmail.com Mon Apr 25 09:09:33 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 25 Apr 2016 10:09:33 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: <1461172110.2941.63.camel@mylittlepony.linaroharston> References: <5714D930.4090804@redhat.com> <57163063.3020506@redhat.com> <1461172110.2941.63.camel@mylittlepony.linaroharston> Message-ID: <1461575373.10032.23.camel@mint> Hi, On Wed, 2016-04-20 at 18:08 +0100, Edward Nevill wrote: > On Tue, 2016-04-19 at 14:19 +0100, Andrew Haley wrote: > > On 04/19/2016 01:54 PM, Long Chen wrote: > > > Would this be fine? > > > > It might well be. I'd like Ed to do a few measurements of large and > > small block zeroing. My guess is that a reasonably small unrolled loop > > doing STP ZR, ZR will work better than anything else, but we'll see. > > OK. So I started by doing some basic measurements of how long it takes to clear a cache line on 3 different partners HW using 3 different methods. > I have redone these benchmarks using a JMH test provided by Andrew Haley. Thanks Andrew! The test is here http://people.linaro.org/~edward.nevill/block_zero/ArrayFill.java And the results are here http://people.linaro.org/~edward.nevill/block_zero/zva1.pdf As a reminder, the different patches are http://people.linaro.org/~edward.nevill/block_zero/stp.patch Uses stp instead of str (no use of dc zva) http://people.linaro.org/~edward.nevill/block_zero/block_zeroing.v01.patch Long Chen's V01 patch http://people.linaro.org/~edward.nevill/block_zero/block_zeroing.v02.patch Long Chen's V02 patch http://people.linaro.org/~edward.nevill/block_zero/block_zeroing.v03.patch if (!small) { } http://people.linaro.org/~edward.nevill/block_zero/block_zeroing.v04.patch Long Chen's v02 patch modified to avoid unaligned stp instructions. >From this it seems that patches bzero3 and bzero4 produce better performance on all except very small zeros <= 16 bytes. bzero3 significantly larger than bzero4 and would probably need outlining. Also, this cutoff point from using stp/str instead of dc zva is set at 2 x cache lines (to guarantee there is at least 1 use of dc zva). A larger value may be better. What I propose next, is only to look at bzero3 and bzero4, to modify bzero3 to out of line the dc zva loop and to look at the cutoff point from stp/str to dc zva to determine thr optimum cutoff point. Thoughts? Ed. From edward.nevill at gmail.com Mon Apr 25 09:28:14 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 25 Apr 2016 10:28:14 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: <1461575373.10032.23.camel@mint> References: <5714D930.4090804@redhat.com> <57163063.3020506@redhat.com> <1461172110.2941.63.camel@mylittlepony.linaroharston> <1461575373.10032.23.camel@mint> Message-ID: <1461576494.10032.31.camel@mint> On Mon, 2016-04-25 at 10:09 +0100, Edward Nevill wrote: > Hi, > > > On Wed, 2016-04-20 at 18:08 +0100, Edward Nevill wrote: > > On Tue, 2016-04-19 at 14:19 +0100, Andrew Haley wrote: > > > On 04/19/2016 01:54 PM, Long Chen wrote: > > > > Would this be fine? > > > > > > It might well be. I'd like Ed to do a few measurements of large and > > > small block zeroing. My guess is that a reasonably small unrolled loop > > > doing STP ZR, ZR will work better than anything else, but we'll see. > > > > OK. So I started by doing some basic measurements of how long it takes to clear a cache line on 3 different partners HW using 3 different methods. > > > > I have redone these benchmarks using a JMH test provided by Andrew Haley. Thanks Andrew! > > The test is here > > http://people.linaro.org/~edward.nevill/block_zero/ArrayFill.java > One interesting data point is the interaction between zeroing memory and allocation prefetch. The following shows this. http://people.linaro.org/~edward.nevill/block_zero/noprefetch.pdf Peformance is improved significantly by turning off allocation prefetch. The problem is that allocation prefetch forces the cache line into L1. The zero mem then has to wait until the cache line has loaded before it can zero it. Therefore performance is much better turning off allocation prefetch altogether. When allocation prefetch is turned off, the str/stp/dc zva just zeros L2 cache and L1 remains unaffected. Also ZeroTlab should improve performance since this will reverse the order of the str/stp/dc zva and the prefetch. However, I think the tuning of prefetch / zero tlab is a separate exercise. All the best, Ed. From aph at redhat.com Mon Apr 25 10:05:32 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 25 Apr 2016 11:05:32 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: <1461575373.10032.23.camel@mint> References: <5714D930.4090804@redhat.com> <57163063.3020506@redhat.com> <1461172110.2941.63.camel@mylittlepony.linaroharston> <1461575373.10032.23.camel@mint> Message-ID: <571DEBEC.3050504@redhat.com> On 04/25/2016 10:09 AM, Edward Nevill wrote: > And the results are here > > http://people.linaro.org/~edward.nevill/block_zero/zva1.pdf Bigger numbers are worse, right? Andrew. From rwestrel at redhat.com Mon Apr 25 13:18:06 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 25 Apr 2016 15:18:06 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8155015: Aarch64: bad assert in spill generation code Message-ID: <571E190E.5050600@redhat.com> http://cr.openjdk.java.net/~roland/8155015/webrev.00/ I hit that broken assert when doing some testing. Roland. From tobias.hartmann at oracle.com Mon Apr 25 13:26:00 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 25 Apr 2016 15:26:00 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8155015: Aarch64: bad assert in spill generation code In-Reply-To: <571E190E.5050600@redhat.com> References: <571E190E.5050600@redhat.com> Message-ID: <571E1AE8.4020000@oracle.com> Hi Roland, On 25.04.2016 15:18, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8155015/webrev.00/ > > I hit that broken assert when doing some testing. That looks good to me! Best regards, Tobias > > Roland. > From edward.nevill at gmail.com Mon Apr 25 14:47:03 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 25 Apr 2016 15:47:03 +0100 Subject: [aarch64-port-dev ] aarch64: RFR: Block zeroing by 'DC ZVA' In-Reply-To: <571DEBEC.3050504@redhat.com> References: <5714D930.4090804@redhat.com> <57163063.3020506@redhat.com> <1461172110.2941.63.camel@mylittlepony.linaroharston> <1461575373.10032.23.camel@mint> <571DEBEC.3050504@redhat.com> Message-ID: <1461595623.10032.37.camel@mint> On Mon, 2016-04-25 at 11:05 +0100, Andrew Haley wrote: > On 04/25/2016 10:09 AM, Edward Nevill wrote: > > And the results are here > > > > http://people.linaro.org/~edward.nevill/block_zero/zva1.pdf > > Bigger numbers are worse, right? > Right, original normalised to 100%, Regards, Ed. From edward.nevill at gmail.com Tue Apr 26 09:37:24 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 26 Apr 2016 10:37:24 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer Felix Yang In-Reply-To: <1461069824.22444.6.camel@mylittlepony.linaroharston> References: <1461069824.22444.6.camel@mylittlepony.linaroharston> Message-ID: <1461663444.2941.65.camel@mylittlepony.linaroharston> Vote: yes On Tue, 2016-04-19 at 13:43 +0100, Edward Nevill wrote: > I hereby nominate Felix Yang (fyang) to aarch64-port Committer. From aph at redhat.com Tue Apr 26 10:43:33 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Apr 2016 11:43:33 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer Felix Yang In-Reply-To: <57162B8A.5060601@redhat.com> References: <1461069824.22444.6.camel@mylittlepony.linaroharston> <57162B8A.5060601@redhat.com> Message-ID: <571F4655.5000804@redhat.com> Vote: yes. Andrew. From adinn at redhat.com Tue Apr 26 11:15:31 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 26 Apr 2016 12:15:31 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer Felix Yang In-Reply-To: <1461069824.22444.6.camel@mylittlepony.linaroharston> References: <1461069824.22444.6.camel@mylittlepony.linaroharston> Message-ID: <571F4DD3.3060609@redhat.com> Vote: yes On 19/04/16 13:43, Edward Nevill wrote: > I hereby nominate Felix Yang (fyang) to aarch64-port Committer. > > Felix is a JDK 9 Author. He has contributed 15 patches to JDK 9 [4]. He > is also a gcc committer [3]. He is a valued member or our Linaro team > and will continue to work to improve OpenJDK. > > Votes are due by 13:43 PM UTC, Tuesday May 3, 2016. > > Only current aarch64-port committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Edward Nevill. > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://gcc.gnu.org/svn/gcc/trunk/MAINTAINERS (Fei Yang) > [4] > > 1. aarch64: test/compiler/runtime/7196199/Test7196199.java fails > https://bugs.openjdk.java.net/browse/JDK-8136524 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e1517978bf12?revcount=1920 > > 2. aarch64: add support for vectorizing fabs/fneg > https://bugs.openjdk.java.net/browse/JDK-8138583 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/daf8acf3afda?revcount=1920 > > 3. Disable C2 peephole by default for aarch64 > https://bugs.openjdk.java.net/browse/JDK-8138641 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/2598332ad46c?revcount=1920 > > 4. aarch64: generate vectorized MLA/MLS instructions > https://bugs.openjdk.java.net/browse/JDK-8144587 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f76a6a7bf9dd?revcount=1920 > > 5. aarch64: jdk/test/com/sun/net/httpserver/Test6a.java fails with > --enable-unlimited-crypto > https://bugs.openjdk.java.net/browse/JDK-8144201 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0d72925dbace?revcount=1920 > > 6. aarch64: redundant lsr instructions in stub code. > https://bugs.openjdk.java.net/browse/JDK-8148328 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/bf349fa14f20?revcount=1920 > > 7. aarch64: Make use of CBZ and CBNZ when comparing narrow pointer with > zero > https://bugs.openjdk.java.net/browse/JDK-8150038 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/fe9e0761c550?revcount=1920 > > 8. aarch64: use load/store pair instructions in call_stub > https://bugs.openjdk.java.net/browse/JDK-8149907 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/161aa091d841?revcount=1920 > > 9. aarch64: pipeline class for several instructions is not set correctly > https://bugs.openjdk.java.net/browse/JDK-8150229 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/77836bd8ec95?revcount=1920 > > 10. aarch64: prefetch the destination word for write prior to ldxr/stxr > loops > https://bugs.openjdk.java.net/browse/JDK-8151340 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9e9281592247?revcount=1920 > > 11. aarch64: Make use of CBZ and CBNZ when comparing unsigned values > with zero > https://bugs.openjdk.java.net/browse/JDK-8152537 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9e2388205f66?revcount=1920 > > 12. aarch64: improve _unsafe_arraycopy stub routine > https://bugs.openjdk.java.net/browse/JDK-8152840 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0d2b390d451a?revcount=1920 > > 13. aarch64: hotspot crashes after the 8.1 LSE patch is merged > https://bugs.openjdk.java.net/browse/JDK-8153172 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/8911d94e888b?revcount=1920 > > 14. C1 segmentation fault due to inline Unsafe::getAndSetObject > https://bugs.openjdk.java.net/browse/JDK-8147805 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/609a41177fbe?revcount=1920 > > 15. aarch64: improve short array clearing using store pair > https://bugs.openjdk.java.net/browse/JDK-8153713 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f9545cf437eb > > 16. aarch64: handle special cases for MaxINode & MinINode > https://bugs.openjdk.java.net/browse/JDK-8153837 > http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2016-April/003327.html (pending) > > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From rwestrel at redhat.com Wed Apr 27 15:57:17 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 27 Apr 2016 17:57:17 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8155015: Aarch64: bad assert in spill generation code In-Reply-To: <571E1AE8.4020000@oracle.com> References: <571E190E.5050600@redhat.com> <571E1AE8.4020000@oracle.com> Message-ID: <5720E15D.3050006@redhat.com> Thanks for the review, Tobias! Roland. On 04/25/2016 03:26 PM, Tobias Hartmann wrote: > Hi Roland, > > On 25.04.2016 15:18, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8155015/webrev.00/ >> >> I hit that broken assert when doing some testing. > > That looks good to me! > > Best regards, > Tobias > >> >> Roland. >> From rwestrel at redhat.com Wed Apr 27 16:18:38 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 27 Apr 2016 18:18:38 +0200 Subject: [aarch64-port-dev ] 8u backport: 8155015: Aarch64: bad assert in spill generation code Message-ID: <5720E65E.5060200@redhat.com> I'd like to backport 8155015 that I just pushed to 9: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9fca65b0a9a1 Can I go ahead? Roland. From aph at redhat.com Wed Apr 27 16:32:40 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Apr 2016 17:32:40 +0100 Subject: [aarch64-port-dev ] 8u backport: 8155015: Aarch64: bad assert in spill generation code In-Reply-To: <5720E65E.5060200@redhat.com> References: <5720E65E.5060200@redhat.com> Message-ID: <5720E9A8.7090500@redhat.com> On 04/27/2016 05:18 PM, Roland Westrelin wrote: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9fca65b0a9a1 > > Can I go ahead? OK. Andrew. From edward.nevill at gmail.com Thu Apr 28 13:49:48 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 28 Apr 2016 14:49:48 +0100 Subject: [aarch64-port-dev ] RFR: 8155617: aarch64: ClearArray does not use DC ZVA Message-ID: <1461851388.10531.27.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8155617/bzero6 https://bugs.openjdk.java.net/browse/JDK-8155617 This is the bzero3 version previously discussed on the aarch64 list with the inner DC ZVA outlined. The outlining of the DC ZVA loop made no measurable difference to performance. I have also tuned the BlockZeroingLowLimit to default to 4 x cache line size rather than always defaulting to 256. Updated performance charts here:- http://cr.openjdk.java.net/~enevill/8155617/bzero6.pdf The chart show the performance improvement on 3 different partners HW. The benchmark was the following JHM test provided by Andrew Haley http://people.linaro.org/~edward.nevill/block_zero/ArrayFill.java The charts have been normalised so that the original jdk9 hs-comp tree is shown as 100%. The figures are % of original performance so lower is better. This is done to avoid disclosing absolute performance information on partner's HW. Orig: Original jdk9 hs-comp bzero6: jdk9 hs-comp with bzero6 Orig (no prf): Original jdk9 hs-comp (-XX:AllocatePrefetchStyle=0) bzero6 (no pref): jdk9 hs-comp with bzero6 (-XX:AllocatePrefetchStyle=0) There is significant interaction between prefetch and block zeroing as discussed previously. Some partners benefit from prefetch, others do not. The proposed patch does not change the behaviour of prefetch (ie. it leaves it enabled) as I think there should be a separate tuning exercise to tune prefetch for different partners HW. OK to push? Ed. From rwestrel at redhat.com Thu Apr 28 15:47:31 2016 From: rwestrel at redhat.com (rwestrel at redhat.com) Date: Thu, 28 Apr 2016 15:47:31 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 8155015: Aarch64: bad assert in spill generation code Message-ID: <201604281547.u3SFlVTf006344@aojmv0008.oracle.com> Changeset: 5d6d52ede653 Author: roland Date: 2016-04-25 15:14 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/5d6d52ede653 8155015: Aarch64: bad assert in spill generation code Reviewed-by: thartmann ! src/cpu/aarch64/vm/aarch64.ad From rwestrel at redhat.com Fri Apr 29 08:49:34 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 29 Apr 2016 10:49:34 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8155717: Aarch64: enable loop superword's unrolling analysis Message-ID: <5723201E.5080909@redhat.com> http://cr.openjdk.java.net/~roland/8155717/webrev.00/ Loop unrolling analysis can help on arm for smaller data types (bytes). For other data types, it drives more inlining which can also be beneficial. This also includes the change Michael ok'ed to shared code. Roland. From aph at redhat.com Fri Apr 29 08:53:11 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 Apr 2016 09:53:11 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8155717: Aarch64: enable loop superword's unrolling analysis In-Reply-To: <5723201E.5080909@redhat.com> References: <5723201E.5080909@redhat.com> Message-ID: <572320F7.9030608@redhat.com> On 29/04/16 09:49, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8155717/webrev.00/ > > Loop unrolling analysis can help on arm for smaller data types (bytes). > For other data types, it drives more inlining which can also be > beneficial. This also includes the change Michael ok'ed to shared code. OK, cool. Will Michael sponsor this, then? Thanks, Andrew. From rwestrel at redhat.com Fri Apr 29 08:58:28 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 29 Apr 2016 10:58:28 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8155717: Aarch64: enable loop superword's unrolling analysis In-Reply-To: <572320F7.9030608@redhat.com> References: <5723201E.5080909@redhat.com> <572320F7.9030608@redhat.com> Message-ID: <57232234.7020504@redhat.com> > OK, cool. Will Michael sponsor this, then? Thanks for reviewing it. I don't think Michael has that power. Roland. From rkennke at redhat.com Fri Apr 29 13:51:20 2016 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 29 Apr 2016 15:51:20 +0200 Subject: [aarch64-port-dev ] Shenandoah import (2nd attempt) Message-ID: <1461937880.7003.3.camel@redhat.com> So here's my second attempt at importing Shenandoah into the Aarch64- Shenandoah integration repository. Compared to the previous one, it adds some missing barriers that have been found by testing the old one, and it now comes as a single big patch. Webrev: http://cr.openjdk.java.net/~rkennke/jdk8u-aarch64-shenandoah/webrev.01/ (If it doesn't show up correctly, it means it hasn't completed uploading yet, just wait a little). Please review and commit if you find it ok. Roman From rwestrel at redhat.com Fri Apr 29 14:05:26 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 29 Apr 2016 16:05:26 +0200 Subject: [aarch64-port-dev ] RFR: 8155617: aarch64: ClearArray does not use DC ZVA In-Reply-To: <1461851388.10531.27.camel@mint> References: <1461851388.10531.27.camel@mint> Message-ID: Hi Ed, I can't start a debug VM since that change was pushed: # Internal Error (/scratch/rwestrel/hs-comp/hotspot/src/share/vm/runtime/stubRoutines.cpp:344), pid=16911, tid=16912 # assert(s.body[i] == 32) failed: what? I think the problem is MacroAssembler::fill_words() moves the pointer past the last word that was written (i.e. there'a hole between the last written word and the value of the base). It passes again with this patch: diff --git a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp @@ -4754,12 +4754,12 @@ const int unroll = 8; // Number of stp instructions we'll unroll cbz(cnt, fini); - tbz(base, 3, skip); + tbz(cnt, 0, skip); str(value, Address(post(base, 8))); sub(cnt, cnt, 1); bind(skip); - andr(rscratch1, cnt, (unroll-1) * 2); + andr(rscratch1, cnt, unroll* 2 - 1); sub(cnt, cnt, rscratch1); add(base, base, rscratch1, Assembler::LSL, 3); adr(rscratch2, entry); @@ -4767,15 +4767,14 @@ br(rscratch2); bind(loop); - for (int i = -unroll; i < 0; i++) + add(base, base, unroll * 16); + sub(cnt, cnt, unroll * 2); + for (int i = -unroll; i < 0; i++) { stp(value, value, Address(base, i * 16)); + } bind(entry); - subs(cnt, cnt, unroll * 2); - add(base, base, unroll * 16); - br(Assembler::GE, loop); - - tbz(cnt, 0, fini); - str(value, Address(base, -unroll * 16)); + cbnz(cnt, loop); + bind(fini); } I've done very little testing with it but a few things felt strange in that code: - I don't understand why aligning the base at the beginning is necessary. Once the base is aligned there's no guarantee the cnt is an even number of words. so when we update the base with: add(base, base, rscratch1, Assembler::LSL, 3); base can be misaligned again. I changed it to test whether cnt is even so at least we don't have to worry about that anymore. - (unroll-1) * 2 seems like an incorrect mask. - then there's the problem of base being updated at the end of the loop that I mentioned above and that can lead to an incorrect base. - That part at the end: str(value, Address(base, -unroll * 16)); I don't understand. Anyway, as I said I've done very little testing so it's entirely possible my patch above is broken. Roland. From aph at redhat.com Fri Apr 29 14:07:37 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 Apr 2016 15:07:37 +0100 Subject: [aarch64-port-dev ] Shenandoah import (2nd attempt) In-Reply-To: <1461937880.7003.3.camel@redhat.com> References: <1461937880.7003.3.camel@redhat.com> Message-ID: <57236AA9.5070906@redhat.com> On 04/29/2016 02:51 PM, Roman Kennke wrote: > Please review and commit if you find it ok. Will do. BTW, it always helps if you send this as a real webrev from a commit; that way the author is set and so is the comment. Andrew. From rkennke at redhat.com Fri Apr 29 14:57:59 2016 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 29 Apr 2016 16:57:59 +0200 Subject: [aarch64-port-dev ] Shenandoah import (2nd attempt) In-Reply-To: <57236AA9.5070906@redhat.com> References: <1461937880.7003.3.camel@redhat.com> <57236AA9.5070906@redhat.com> Message-ID: <1461941879.7003.4.camel@redhat.com> Am Freitag, den 29.04.2016, 15:07 +0100 schrieb Andrew Haley: > On 04/29/2016 02:51 PM, Roman Kennke wrote: > > > > Please review and commit if you find it ok. > Will do.??BTW, it always helps if you send this as a real webrev from > a > commit; that way the author is set and so is the comment. Ok, that would be this, right? http://cr.openjdk.java.net/~rkennke/jdk8u-aarch64-shenandoah/webrev.02/ The changeset seems correct, but the webrev looks all messed up to me. Roman >? From edward.nevill at gmail.com Fri Apr 29 15:30:33 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Fri, 29 Apr 2016 16:30:33 +0100 Subject: [aarch64-port-dev ] RFR: 8155617: aarch64: ClearArray does not use DC ZVA In-Reply-To: References: <1461851388.10531.27.camel@mint> Message-ID: <1461943833.12456.16.camel@mint> Hi Roland, On Fri, 2016-04-29 at 16:05 +0200, Roland Westrelin wrote: > Hi Ed, > > I can't start a debug VM since that change was pushed: > > # Internal Error (/scratch/rwestrel/hs-comp/hotspot/src/share/vm/runtime/stubRoutines.cpp:344), pid=16911, tid=16912 > # assert(s.body[i] == 32) failed: what? > > I think the problem is MacroAssembler::fill_words() moves the pointer > past the last word that was written (i.e. there'a hole between the last > written word and the value of the base). It passes again with this > patch: Sorry, I missed the post-condition that base should point to the end. Could you please try the following patch diff -r e118111d4433 src/cpu/aarch64/vm/macroAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Fri Apr 29 14:32:19 2016 +0200 +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp Fri Apr 29 08:08:47 2016 -0700 @@ -4767,15 +4767,15 @@ br(rscratch2); bind(loop); + add(base, base, unroll * 16); for (int i = -unroll; i < 0; i++) stp(value, value, Address(base, i * 16)); bind(entry); subs(cnt, cnt, unroll * 2); - add(base, base, unroll * 16); br(Assembler::GE, loop); tbz(cnt, 0, fini); - str(value, Address(base, -unroll * 16)); + str(value, Address(post(base, 8))); bind(fini); } I believe the only thing wrong with the code is that it exits without the base being updated as expected. > > diff --git a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > --- a/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > +++ b/src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > @@ -4754,12 +4754,12 @@ > const int unroll = 8; // Number of stp instructions we'll unroll > > cbz(cnt, fini); > - tbz(base, 3, skip); > + tbz(cnt, 0, skip); > str(value, Address(post(base, 8))); > sub(cnt, cnt, 1); > bind(skip); The intention here is to align the base, not ensure the count is even. An odd count is handled by the final store. > > - andr(rscratch1, cnt, (unroll-1) * 2); > + andr(rscratch1, cnt, unroll* 2 - 1); The mask (unroll-1) * 2 ensures rscratch1 is even. With an unroll value of 8 the mask will be 0xe giving a count of the even no of values to be stored by the jump into the loop. > sub(cnt, cnt, rscratch1); > add(base, base, rscratch1, Assembler::LSL, 3); > adr(rscratch2, entry); > @@ -4767,15 +4767,14 @@ > br(rscratch2); > > bind(loop); > - for (int i = -unroll; i < 0; i++) > + add(base, base, unroll * 16); > + sub(cnt, cnt, unroll * 2); > + for (int i = -unroll; i < 0; i++) { > stp(value, value, Address(base, i * 16)); > + } > bind(entry); > - subs(cnt, cnt, unroll * 2); > - add(base, base, unroll * 16); > - br(Assembler::GE, loop); I need to do subs / b GE here because cnt may be odd. Therefore I cannot use cbnz cnt, ... because the count may never become zero. Moving the update of the base to the head of the loop is correct as that ensures the base points correctly to the end on exit. > - > - tbz(cnt, 0, fini); > - str(value, Address(base, -unroll * 16)); > + cbnz(cnt, loop); > + > bind(fini); > } > > > I've done very little testing with it but a few things felt strange in > that code: > > - I don't understand why aligning the base at the beginning is > necessary. Once the base is aligned there's no guarantee the cnt is an > even number of words. so when we update the base with: > > add(base, base, rscratch1, Assembler::LSL, 3); Yes, but the mask (unroll-1) * 2 ensures rscratch1 is even. > > base can be misaligned again. I changed it to test whether cnt is even > so at least we don't have to worry about that anymore. > > - (unroll-1) * 2 seems like an incorrect mask. > > - then there's the problem of base being updated at the end of the loop > that I mentioned above and that can lead to an incorrect base. Yes, sorry I completely missed that postcondition. > > - That part at the end: > str(value, Address(base, -unroll * 16)); Because I did the update of the base at the end, base points unroll * 16 beyond the end. So if there is an odd word at the end it is stored at offset -unroll * 16. But updating the base at the head of the loop ensures it is pointing to the end on exit. Then if there is an odd word at the end we can use post(base, 8) to store the odd word and ensure the base is updated. > > I don't understand. > > Anyway, as I said I've done very little testing so it's entirely > possible my patch above is broken. Thanks for finding this and sorry again. I'll give the above patch a good testing and submit it for RFR. If you could also try it that would be appreciated. All the best, Ed. From aph at redhat.com Fri Apr 29 15:32:54 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 Apr 2016 16:32:54 +0100 Subject: [aarch64-port-dev ] Shenandoah import (2nd attempt) In-Reply-To: <1461941879.7003.4.camel@redhat.com> References: <1461937880.7003.3.camel@redhat.com> <57236AA9.5070906@redhat.com> <1461941879.7003.4.camel@redhat.com> Message-ID: <57237EA6.7020807@redhat.com> On 04/29/2016 03:57 PM, Roman Kennke wrote: > Ok, that would be this, right? > > http://cr.openjdk.java.net/~rkennke/jdk8u-aarch64-shenandoah/webrev.02/ > > The changeset seems correct, but the webrev looks all messed up to me. It is totally wrong. rm -rf webrev The run webrev. Andrew. From aph at redhat.com Fri Apr 29 15:47:30 2016 From: aph at redhat.com (aph at redhat.com) Date: Fri, 29 Apr 2016 15:47:30 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: Initial import of Shenandoah Message-ID: <201604291547.u3TFlUKp006926@aojmv0008.oracle.com> Changeset: 04726a0d70bb Author: rkennke Date: 2016-04-29 16:18 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/04726a0d70bb Initial import of Shenandoah ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/jniFastGetField_x86_64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegionBounds.inline.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp + src/share/vm/gc_implementation/shenandoah/brooksPointer.cpp + src/share/vm/gc_implementation/shenandoah/brooksPointer.hpp + src/share/vm/gc_implementation/shenandoah/brooksPointer.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentThread.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahHumongous.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahJNICritical.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahJNICritical.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp + src/share/vm/gc_implementation/shenandoah/shenandoah_globals.cpp + src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp + src/share/vm/gc_implementation/shenandoah/shenandoah_specialized_oop_closures.hpp + src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.cpp + src/share/vm/gc_implementation/shenandoah/vm_operations_shenandoah.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/gc_interface/gcName.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/specialized_oop_closures.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/instanceRefKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayOop.hpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/classes.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/multnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/parseHelper.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp + src/share/vm/opto/shenandoahSupport.cpp + src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/precompiled/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/jniHandles.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryManager.hpp ! src/share/vm/services/memoryPool.hpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/memoryService.hpp ! src/share/vm/services/serviceUtil.hpp + src/share/vm/services/shenandoahMemoryPool.cpp + src/share/vm/services/shenandoahMemoryPool.hpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/top.hpp From rwestrel at redhat.com Fri Apr 29 15:56:11 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 29 Apr 2016 17:56:11 +0200 Subject: [aarch64-port-dev ] RFR: 8155617: aarch64: ClearArray does not use DC ZVA In-Reply-To: <1461943833.12456.16.camel@mint> References: <1461851388.10531.27.camel@mint> <1461943833.12456.16.camel@mint> Message-ID: <5723841B.3030607@redhat.com> Hi Ed, > Could you please try the following patch I tried your patch and the debug VM starts ok now. Roland. From rwestrel at redhat.com Fri Apr 29 16:06:09 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 29 Apr 2016 18:06:09 +0200 Subject: [aarch64-port-dev ] 8u backport: 8155612: Aarch64: vector nodes need to support misaligned offset Message-ID: <57238671.6060709@redhat.com> I'd like to backport 8155612 (and its companion 8155653) to 8u. Here are the changesets: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/9e21d8c18a7d http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/e118111d4433 Roland. From vladimir.kozlov at oracle.com Fri Apr 29 16:09:00 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 29 Apr 2016 09:09:00 -0700 Subject: [aarch64-port-dev ] RFR(XS): 8155717: Aarch64: enable loop superword's unrolling analysis In-Reply-To: <57232234.7020504@redhat.com> References: <5723201E.5080909@redhat.com> <572320F7.9030608@redhat.com> <57232234.7020504@redhat.com> Message-ID: <5caad142-53f6-ed36-ac4e-e006c441bdc4@oracle.com> Changes looks good. I will run tests with it and will sponsor. Thanks, Vladimir On 4/29/16 1:58 AM, Roland Westrelin wrote: > >> OK, cool. Will Michael sponsor this, then? > > Thanks for reviewing it. I don't think Michael has that power. > > Roland. > From edward.nevill at gmail.com Sat Apr 30 08:17:29 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Sat, 30 Apr 2016 09:17:29 +0100 Subject: [aarch64-port-dev ] 8155790: aarch64: debug VM fails to start after 8155617 Message-ID: <1462004249.32168.11.camel@mint> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8155790/ JIRA: https://bugs.openjdk.java.net/browse/JDK-8155790 This fixes an issue where the debug build fails to start after 8155617 with the error # Internal Error (/scratch/rwestrel/hs-comp/hotspot/src/share/vm/runtime/stubRoutines.cpp:344), pid=16911, tid=16912 # assert(s.body[i] == 32) failed: what? The problem is that I failed to observe that the base register must point immediately after the end of the block being zeroed on exit from the zero loop. In addition the base register can sometimes be byte aligned due to vectorisation and this was not handled. The above webrev fixes this. I have tested a debug build with jtreg hotspot and langtools. OK to push? Ed. From aph at redhat.com Sat Apr 30 08:39:57 2016 From: aph at redhat.com (Andrew Haley) Date: Sat, 30 Apr 2016 09:39:57 +0100 Subject: [aarch64-port-dev ] 8155790: aarch64: debug VM fails to start after 8155617 In-Reply-To: <1462004249.32168.11.camel@mint> References: <1462004249.32168.11.camel@mint> Message-ID: <57246F5D.7090609@redhat.com> On 30/04/16 09:17, Edward Nevill wrote: > http://cr.openjdk.java.net/~enevill/8155790/ > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8155790 OK, thanks. Andrew.