From Pengfei.Li at arm.com Tue Mar 3 10:12:08 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Tue, 3 Mar 2020 10:12:08 +0000 Subject: [aarch64-port-dev ] RFR(S): 8239914: AArch64: Combine add/sub with comparison against zero In-Reply-To: <0dc8ae78-3e50-c90a-d50e-8c009ee137e8@redhat.com> References: <0dc8ae78-3e50-c90a-d50e-8c009ee137e8@redhat.com> Message-ID: Hi Andrew Haley, > I am not sure you're thought about this clearly enough. Try this > program: > > public class DifferenceTest { > > static int theTest(int x, int y) { > int sum = 0; > while (x - y > 0) { > sum++; > y--; > } > return sum; > } > > static int n = -0x7000_0000; > static int m = +0x7000_0000; > > void trial() { > int prev = theTest(n, m); > for (int i = 0; i < 10_000_000; i++) { > int result = theTest(n, m); > if (prev != result) { > throw new RuntimeException("last sum was " + prev + ", is now " + > result); > } > prev = result; > } > } > > public static void main(String[] args) { > new DifferenceTest().trial(); > } > } Thanks for reporting this. I just tested the program and found the exception also exists with AArch64 JDK master build (without my patch). Apologize that I will be on leave and unable to create patches in the following days. But I've reported this to my colleagues. I think someone else will reply you soon. -- Thanks, Pengfei From aph at redhat.com Tue Mar 3 15:11:32 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 3 Mar 2020 15:11:32 +0000 Subject: [aarch64-port-dev ] RFR(S): 8239914: AArch64: Combine add/sub with comparison against zero In-Reply-To: References: <0dc8ae78-3e50-c90a-d50e-8c009ee137e8@redhat.com> Message-ID: Hi, On 3/3/20 10:12 AM, Pengfei Li wrote: > Thanks for reporting this. I just tested the program and found the > exception also exists with AArch64 JDK master build (without my > patch). Not for me. I see no such problem. > Apologize that I will be on leave and unable to create patches in > the following days. But I've reported this to my colleagues. I think > someone else will reply you soon. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Wed Mar 4 03:52:51 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 04 Mar 2020 11:52:51 +0800 Subject: [aarch64-port-dev ] RFR(S): 8239914: AArch64: Combine add/sub with comparison against zero In-Reply-To: References: <0dc8ae78-3e50-c90a-d50e-8c009ee137e8@redhat.com> Message-ID: <85blpcydws.fsf@nicgas01-03-arm-vm.shanghai.arm.com> Hi Pengfei, On 03/03/20 18:12 pm, Pengfei Li wrote: > Thanks for reporting this. I just tested the program and found the > exception also exists with AArch64 JDK master build (without my > patch). I couldn't reproduce this on the latest jdk/jdk, only with your patch. I think the problem is with the cmp*_sub_zero match rules. (a - b) > 0 !== a > b if a - b overflows because Java requires the result to wrap around which changes the sign. > > Apologize that I will be on leave and unable to create patches in the following days. But I've reported this to my colleagues. I think someone else will reply you soon. I think it's ok to update the patch when you come back. Thanks, Nick From aph at redhat.com Wed Mar 4 09:29:10 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 4 Mar 2020 09:29:10 +0000 Subject: [aarch64-port-dev ] RFR(S): 8239914: AArch64: Combine add/sub with comparison against zero In-Reply-To: <85blpcydws.fsf@nicgas01-03-arm-vm.shanghai.arm.com> References: <0dc8ae78-3e50-c90a-d50e-8c009ee137e8@redhat.com> <85blpcydws.fsf@nicgas01-03-arm-vm.shanghai.arm.com> Message-ID: On 3/4/20 3:52 AM, Nick Gasson wrote: > > On 03/03/20 18:12 pm, Pengfei Li wrote: >> Thanks for reporting this. I just tested the program and found the >> exception also exists with AArch64 JDK master build (without my >> patch). > > I couldn't reproduce this on the latest jdk/jdk, only with your patch. I > think the problem is with the cmp*_sub_zero match rules. (a - b) > 0 !== > a > b if a - b overflows because Java requires the result to wrap around > which changes the sign. Indeed. We need to think carefully about the way we review (and, indeed, write) AArch64 patches. This small one might well have got through to production without its fatal flaw being noticed. In this case, though, the review process worked. Unit tests are good, but we need to make sure that they test the corner cases. Every arithmetic instruction can overflow. Note that this is absolutely not a criticism of Pengfei; we all make mistakes. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Wed Mar 4 19:17:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 4 Mar 2020 19:17:39 +0000 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b05 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b05: - S8022263: use same Clang warnings on BSD as on Linux - S8055283: Expand ResourceHashtable with C_HEAP allocation, removal and some unit tests - S8068184: Fix for JDK-8032832 caused a deadlock - S8079693: Add support for ECDSA P-384 and P-521 curves to XML Signature - S8132130: some docs cleanup - S8144526: Remove Marlin logging use of deleted internal API - S8144654: Improve Marlin logging - S8144718: Pisces / Marlin Strokers may generate invalid curves with huge coordinates and round joins - S8166976: TestCipherPBECons has wrong @run line - S8167409: Invalid value passed to critical JNI function - S8181872: C1: possible overflow when strength reducing integer multiply by constant - S8187078: -XX:+VerifyOops finds numerous problems when running JPRT - S8191227: issues with unsafe handle resolution - S8216472: (se) Stack overflow during selection operation leads to crash (win) - S8229022: BufferedReader performance can be improved by using StringBuilder - S8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type - S8235904: Infinite loop when rendering huge lines Main issues of note: - Two merge conflicts - src/share/vm/code/debugInfo.cpp: changes are applied to ConstantOopWriteValue::write_on_impl rather than CanstantOopWriteValue::write_on due to "[backport] Workaround C1 ConstantOopWriteValue bug" - src/share/vm/opto/type.cpp: slight context difference due to presence of TypeAryPtr::cast_to_nonconst in aarch64/shenandoah-jdk8u diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/src/share/classes/com/sun/crypto/provider/BlowfishCipher.java | 2 b/src/share/classes/com/sun/crypto/provider/DESCipher.java | 2 b/src/share/classes/com/sun/crypto/provider/DESedeCipher.java | 2 b/src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java | 29 b/src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java | 2 b/src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java | 2 b/src/share/classes/com/sun/crypto/provider/PBEWithMD5AndDESCipher.java | 2 b/src/share/classes/com/sun/crypto/provider/PBEWithMD5AndTripleDESCipher.java | 2 b/src/share/classes/com/sun/crypto/provider/PBKDF2HmacSHA1Factory.java | 2 b/src/share/classes/com/sun/security/sasl/digest/FactoryImpl.java | 6 b/src/share/classes/com/sun/security/sasl/ntlm/FactoryImpl.java | 6 b/src/share/classes/java/io/BufferedReader.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java | 103 ++- b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java | 6 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java | 1 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java | 1 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java | 1 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java | 34 - b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java | 1 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java | 1 b/src/share/classes/sun/java2d/marlin/ByteArrayCache.java | 4 b/src/share/classes/sun/java2d/marlin/FloatArrayCache.java | 4 b/src/share/classes/sun/java2d/marlin/IntArrayCache.java | 4 b/src/share/classes/sun/java2d/marlin/MarlinConst.java | 9 b/src/share/classes/sun/java2d/marlin/MarlinProperties.java | 4 b/src/share/classes/sun/java2d/marlin/MarlinUtils.java | 49 - b/src/share/classes/sun/java2d/marlin/RendererContext.java | 22 b/src/share/classes/sun/java2d/marlin/Stroker.java | 20 b/src/share/classes/sun/java2d/pisces/Stroker.java | 20 b/src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java | 29 b/src/share/classes/sun/security/jgss/GSSCredentialImpl.java | 4 b/src/share/classes/sun/security/jgss/GSSToken.java | 14 b/src/share/classes/sun/security/jgss/LoginConfigImpl.java | 2 b/src/share/classes/sun/security/jgss/ProviderList.java | 6 b/src/share/classes/sun/security/jgss/krb5/Krb5NameElement.java | 4 b/src/share/classes/sun/security/jgss/spi/GSSContextSpi.java | 12 b/src/share/classes/sun/security/jgss/spi/GSSNameSpi.java | 4 b/src/share/classes/sun/security/jgss/spi/MechanismFactory.java | 2 b/src/share/classes/sun/security/krb5/Checksum.java | 8 b/src/share/classes/sun/security/krb5/Config.java | 4 b/src/share/classes/sun/security/krb5/Credentials.java | 2 b/src/share/classes/sun/security/krb5/EncryptedData.java | 6 b/src/share/classes/sun/security/krb5/EncryptionKey.java | 12 b/src/share/classes/sun/security/krb5/KrbAsReqBuilder.java | 2 b/src/share/classes/sun/security/krb5/PrincipalName.java | 11 b/src/share/classes/sun/security/krb5/Realm.java | 5 b/src/share/classes/sun/security/krb5/internal/APOptions.java | 4 b/src/share/classes/sun/security/krb5/internal/APRep.java | 4 b/src/share/classes/sun/security/krb5/internal/APReq.java | 4 b/src/share/classes/sun/security/krb5/internal/Authenticator.java | 4 b/src/share/classes/sun/security/krb5/internal/EncAPRepPart.java | 4 b/src/share/classes/sun/security/krb5/internal/EncKDCRepPart.java | 4 b/src/share/classes/sun/security/krb5/internal/EncKrbCredPart.java | 4 b/src/share/classes/sun/security/krb5/internal/EncKrbPrivPart.java | 4 b/src/share/classes/sun/security/krb5/internal/EncTicketPart.java | 4 b/src/share/classes/sun/security/krb5/internal/HostAddress.java | 6 b/src/share/classes/sun/security/krb5/internal/HostAddresses.java | 4 b/src/share/classes/sun/security/krb5/internal/KDCOptions.java | 6 b/src/share/classes/sun/security/krb5/internal/KDCRep.java | 4 b/src/share/classes/sun/security/krb5/internal/KDCReq.java | 6 b/src/share/classes/sun/security/krb5/internal/KDCReqBody.java | 4 b/src/share/classes/sun/security/krb5/internal/KRBCred.java | 4 b/src/share/classes/sun/security/krb5/internal/KRBError.java | 4 b/src/share/classes/sun/security/krb5/internal/KRBPriv.java | 4 b/src/share/classes/sun/security/krb5/internal/KRBSafe.java | 4 b/src/share/classes/sun/security/krb5/internal/KRBSafeBody.java | 4 b/src/share/classes/sun/security/krb5/internal/KerberosTime.java | 4 b/src/share/classes/sun/security/krb5/internal/KrbCredInfo.java | 4 b/src/share/classes/sun/security/krb5/internal/LastReq.java | 4 b/src/share/classes/sun/security/krb5/internal/LoginOptions.java | 4 b/src/share/classes/sun/security/krb5/internal/MethodData.java | 4 b/src/share/classes/sun/security/krb5/internal/PAData.java | 15 b/src/share/classes/sun/security/krb5/internal/PAEncTSEnc.java | 4 b/src/share/classes/sun/security/krb5/internal/PAForUserEnc.java | 4 b/src/share/classes/sun/security/krb5/internal/Ticket.java | 4 b/src/share/classes/sun/security/krb5/internal/TransitedEncoding.java | 4 b/src/share/classes/sun/security/krb5/internal/crypto/Des.java | 2 b/src/share/classes/sun/security/krb5/internal/crypto/DesMacCksumType.java | 2 b/src/share/classes/sun/security/krb5/internal/crypto/HmacMd5ArcFourCksumType.java | 2 b/src/share/classes/sun/security/krb5/internal/crypto/HmacSha1Aes128CksumType.java | 2 b/src/share/classes/sun/security/krb5/internal/crypto/HmacSha1Aes256CksumType.java | 2 b/src/share/classes/sun/security/krb5/internal/crypto/HmacSha1Des3KdCksumType.java | 2 b/src/share/classes/sun/security/krb5/internal/crypto/RsaMd5DesCksumType.java | 2 b/src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java | 2 b/src/share/classes/sun/security/krb5/internal/rcache/AuthList.java | 2 b/src/share/classes/sun/security/pkcs11/wrapper/CK_CREATEMUTEX.java | 7 b/src/solaris/classes/sun/java2d/xr/XRDrawLine.java | 2 b/src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java | 33 - b/src/windows/classes/sun/security/krb5/internal/tools/Kinit.java | 27 b/src/windows/classes/sun/security/krb5/internal/tools/Klist.java | 2 b/src/windows/native/sun/nio/ch/WindowsSelectorImpl.c | 101 +-- b/test/com/sun/crypto/provider/Cipher/PBE/TestCipherPBECons.java | 1 b/test/java/awt/Graphics/DrawLineTest.java | 73 ++ b/test/java/nio/channels/Selector/StackOverflowTest.java | 49 + b/test/javax/xml/crypto/dsig/GenerationTests.java | 154 +++- b/test/javax/xml/crypto/dsig/ValidationTests.java | 4 b/test/javax/xml/crypto/dsig/data/signature-enveloping-p384-sha1.xml | 3 b/test/javax/xml/crypto/dsig/data/signature-enveloping-p521-sha1.xml | 5 b/test/sun/java2d/marlin/TextClipErrorTest.java | 322 ++++++++++ 101 files changed, 984 insertions(+), 431 deletions(-) diffstat for hotspot b/.hgtags | 1 b/make/bsd/makefiles/gcc.make | 9 b/src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp | 7 b/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp | 8 b/src/cpu/x86/vm/sharedRuntime_x86_64.cpp | 2 b/src/share/vm/adlc/archDesc.cpp | 26 - b/src/share/vm/adlc/main.cpp | 1 b/src/share/vm/adlc/output_c.cpp | 17 b/src/share/vm/c1/c1_LIRGenerator.cpp | 10 b/src/share/vm/c1/c1_LIRGenerator.hpp | 2 b/src/share/vm/code/debugInfo.cpp | 18 b/src/share/vm/opto/type.cpp | 33 - b/src/share/vm/opto/type.hpp | 3 b/src/share/vm/prims/forte.cpp | 2 b/src/share/vm/prims/jni.cpp | 2 b/src/share/vm/runtime/java.cpp | 2 b/src/share/vm/utilities/globalDefinitions.hpp | 4 b/src/share/vm/utilities/resourceHash.cpp | 182 ++++++++++ b/src/share/vm/utilities/resourceHash.hpp | 54 ++ b/test/compiler/c1/MultiplyByMaxInt.java | 53 ++ b/test/compiler/criticalnatives/argumentcorruption/CheckLongArgs.java | 54 ++ b/test/compiler/criticalnatives/argumentcorruption/Test8167409.sh | 83 ++++ b/test/compiler/criticalnatives/argumentcorruption/libCNCheckLongArgs.c | 30 + 23 files changed, 510 insertions(+), 93 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Mar 4 19:32:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 4 Mar 2020 20:32:10 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b05 Upstream Sync In-Reply-To: References: Message-ID: <529b6ed0-3b5f-6d30-db2a-c033d71e5856@redhat.com> On 3/4/20 8:17 PM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/jaxws/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b05/root/merge.changeset Looks trivially good. > Main issues of note: > - Two merge conflicts > - src/share/vm/code/debugInfo.cpp: changes are applied to > ConstantOopWriteValue::write_on_impl rather than > CanstantOopWriteValue::write_on due to "[backport] Workaround C1 > ConstantOopWriteValue bug" Yes, it is done appropriately for now. We would clean that mess up in sh/jdk8u and integrate back. > - src/share/vm/opto/type.cpp: slight context difference due to > presence of TypeAryPtr::cast_to_nonconst in aarch64/shenandoah-jdk8u That source of merge conflicts would be removed when we integrate sh/jdk8u: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ed1dc6cce765 > Ok to push? Yes. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Mar 4 19:46:30 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 04 Mar 2020 19:46:30 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <202003041946.024JkUvh016647@aojmv0008.oracle.com> Changeset: bb464170d344 Author: andrew Date: 2020-02-27 19:01 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/bb464170d344 Added tag jdk8u252-b05 for changeset 62c9a2725c6c ! .hgtags Changeset: 8f0a4b79e082 Author: andrew Date: 2020-02-28 05:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/8f0a4b79e082 Merge jdk8u252-b05 ! .hgtags Changeset: 0ff25f1e7256 Author: andrew Date: 2020-02-28 05:29 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/0ff25f1e7256 Added tag aarch64-shenandoah-jdk8u252-b05 for changeset 8f0a4b79e082 ! .hgtags From gnu.andrew at redhat.com Wed Mar 4 19:46:44 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 04 Mar 2020 19:46:44 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 3 new changesets Message-ID: <202003041946.024JkiQ1016785@aojmv0008.oracle.com> Changeset: 4f24bfe038c3 Author: andrew Date: 2020-02-27 19:01 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/4f24bfe038c3 Added tag jdk8u252-b05 for changeset 49013f07f606 ! .hgtags Changeset: d50dc2991dea Author: andrew Date: 2020-02-28 05:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/d50dc2991dea Merge jdk8u252-b05 ! .hgtags Changeset: a5e1811e54eb Author: andrew Date: 2020-02-28 05:29 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/a5e1811e54eb Added tag aarch64-shenandoah-jdk8u252-b05 for changeset d50dc2991dea ! .hgtags From Pengfei.Li at arm.com Fri Mar 6 07:39:08 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Fri, 6 Mar 2020 07:39:08 +0000 Subject: [aarch64-port-dev ] RFR(S): 8239914: AArch64: Combine add/sub with comparison against zero In-Reply-To: <85blpcydws.fsf@nicgas01-03-arm-vm.shanghai.arm.com> References: <0dc8ae78-3e50-c90a-d50e-8c009ee137e8@redhat.com> <85blpcydws.fsf@nicgas01-03-arm-vm.shanghai.arm.com> Message-ID: Hi Nick, > I couldn't reproduce this on the latest jdk/jdk, only with your patch. I think > the problem is with the cmp*_sub_zero match rules. (a - b) > 0 !== a > b if a - > b overflows because Java requires the result to wrap around which changes > the sign. You are right. That's something wrong with my remote environment before. Sorry about that. > I think it's ok to update the patch when you come back. Indeed, my (a + b > 0) has the same overflow issue. And I can produce an incorrect arithmetic result in another case. Hence, my patch has no value and I should abandon it. -- Thanks, Pengfei From Pengfei.Li at arm.com Fri Mar 6 07:41:15 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Fri, 6 Mar 2020 07:41:15 +0000 Subject: [aarch64-port-dev ] RFR(S): 8239914: AArch64: Combine add/sub with comparison against zero In-Reply-To: References: <0dc8ae78-3e50-c90a-d50e-8c009ee137e8@redhat.com> <85blpcydws.fsf@nicgas01-03-arm-vm.shanghai.arm.com> Message-ID: Hi, > Indeed. We need to think carefully about the way we review (and, indeed, > write) AArch64 patches. This small one might well have got through to > production without its fatal flaw being noticed. In this case, though, the > review process worked. > > Unit tests are good, but we need to make sure that they test the corner cases. > Every arithmetic instruction can overflow. I agree. Appreciate for your review. -- Thanks, Pengfei From sgehwolf at redhat.com Fri Mar 6 13:36:45 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 06 Mar 2020 14:36:45 +0100 Subject: [aarch64-port-dev ] [RFR 8u]: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 Message-ID: <88b720d16f853b744a8f97d7de8a99a8c2514d85.camel@redhat.com> Hi, Could I please get a review for this 8u backport of JDK-8224851? We need this patch for building JDK 8 with GCC 10. GCC 10 particularly complains about duplicate declaration of 'using MacroAssembler::call_VM_leaf_base;' in src/cpu/aarch64/vm/interp_masm_aarch64.hpp While we could backport only the relevant hunk to fix the GCC 10 issue I've tried a more complete backport as it seems to be fixing a couple of code issues. If it's preferred, I can do a select backport of [1] too. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224851/01/webrev/ JDK 11u change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/15cc1c8a6371 Unfortunately the JDK 11u patch doesn't apply cleanly. I needed to do the following modifications: src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp -> not present in 8u. Hunks omitted. src/cpu/aarch64/vm/assembler_aarch64.hpp.rej --- assembler_aarch64.hpp +++ assembler_aarch64.hpp @@ -2580,7 +2580,7 @@ // RBIT only allows T8B and T16B but encodes them oddly. Argh... void rbit(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn) { assert((ASSERTION), MSG); - _rbit(Vd, SIMD_Arrangement(T & 1 | 0b010), Vn); + _rbit(Vd, SIMD_Arrangement((T & 1) | 0b010), Vn); } #undef ASSERTION --> JDK-8134869 not present in 8u. Omitted hunk. src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp --> Some whitespace differences. Needed to transplant some hunks manually. src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp --> Copyright fixed manually. src/cpu/aarch64/vm/frame_aarch64.cpp.rej --- frame_aarch64.cpp +++ frame_aarch64.cpp @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2019, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2014, Red Hat Inc. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * @@ -767,11 +767,13 @@ extern "C" void pf(unsigned long sp, unsigned long fp, unsigned long pc, unsigned long bcx, unsigned long thread) { - RegisterMap map((JavaThread*)thread, false); if (!reg_map) { - reg_map = (RegisterMap*)os::malloc(sizeof map, mtNone); + reg_map = NEW_C_HEAP_OBJ(RegisterMap, mtNone); + ::new (reg_map) RegisterMap((JavaThread*)thread, false); + } else { + *reg_map = RegisterMap((JavaThread*)thread, false); } - memcpy(reg_map, &map, sizeof map); + { CodeBlob *cb = CodeCache::find_blob((address)pc); if (cb && cb->frame_size()) --> fixed manually. Context differed. src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp.rej --- os_linux_aarch64.cpp +++ os_linux_aarch64.cpp @@ -199,23 +195,8 @@ return frame(fr->link(), fr->link(), fr->sender_pc()); } -intptr_t* _get_previous_fp() { - register intptr_t **fp __asm__ (SPELL_REG_FP); - - // fp is for this frame (_get_previous_fp). We want the fp for the - // caller of os::current_frame*(), so go up two frames. However, for - // optimized builds, _get_previous_fp() will be inlined, so only go - // up 1 frame in that case. - #ifdef _NMT_NOINLINE_ - return **(intptr_t***)fp; - #else - return *fp; - #endif -} - - -frame os::current_frame() { - intptr_t* fp = _get_previous_fp(); +NOINLINE frame os::current_frame() { + intptr_t *fp = *(intptr_t **)__builtin_frame_address(0); frame myframe((intptr_t*)os::current_stack_pointer(), (intptr_t*)fp, CAST_FROM_FN_PTR(address, os::current_frame)); @@ -228,12 +209,6 @@ } // Utility functions - -// From IA32 System Programming Guide -enum { - trap_page_fault = 0xE -}; - extern "C" JNIEXPORT int JVM_handle_linux_signal(int sig, siginfo_t* info, -> Fixed manually - removed 'const' changes as JDK 8u doesn't have: 8165929: Constify arguments of Copy methods - NOINLINE not defined in os_linux_aarch64.cpp defined explicitly in that file. Tested a build with this on aarch64 Fedora here: https://koji.fedoraproject.org/koji/taskinfo?taskID=42247457 Thoughts? Thanks, Severin [1] https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/15cc1c8a6371#l6.7 From aph at redhat.com Fri Mar 6 14:02:37 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 6 Mar 2020 14:02:37 +0000 Subject: [aarch64-port-dev ] [RFR 8u]: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <88b720d16f853b744a8f97d7de8a99a8c2514d85.camel@redhat.com> References: <88b720d16f853b744a8f97d7de8a99a8c2514d85.camel@redhat.com> Message-ID: <696230af-071b-e11f-b122-718f0def7d0a@redhat.com> On 3/6/20 1:36 PM, Severin Gehwolf wrote: > While we could backport only the relevant hunk to fix the GCC 10 issue > I've tried a more complete backport as it seems to be fixing a couple > of code issues. If it's preferred, I can do a select backport of [1] > too. Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224851/01/webrev/ > JDK 11u change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/15cc1c8a6371 This webrev looks very close to what I'd do. The fixes you've made look correct, and in some cases are real bugs which impact code generation. OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Fri Mar 6 15:36:29 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 6 Mar 2020 16:36:29 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration from Shenandoah Message-ID: <008bc3ef-2d73-76cb-a3b6-cd1386f2791a@redhat.com> This imports recent changes from shenandoah/jdk8 to the integration repo aarch64-port/jdk8-shenandoah. It's all smallish improvements, bug-fixes, cleanups, etc. Changesets: http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/changesets.txt Full webrev: http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/webrev.00/ Merge was almost trivial. Most changes in shared code actually revert Shenandoah-specific changes. Testing: shenandoah/jdk8 has baked in our nightly CI runs for quite a while. I have run build and hotspot_gc_shenandoah locally after the merge for sanity-test Can I get a review? Thanks, Roman From rkennke at redhat.com Fri Mar 6 17:22:15 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 6 Mar 2020 18:22:15 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration from Shenandoah In-Reply-To: <008bc3ef-2d73-76cb-a3b6-cd1386f2791a@redhat.com> References: <008bc3ef-2d73-76cb-a3b6-cd1386f2791a@redhat.com> Message-ID: <16a0f235-e66b-9c28-6928-9b8c649c4c5c@redhat.com> Disregard the webrev, and review those updated changesets/webrev instead: Changeset: http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/changesets.01 Full webrev: http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/webrev.01/ I forgot to include a number of recent backports. Thank you, Roman > This imports recent changes from shenandoah/jdk8 to the integration repo > aarch64-port/jdk8-shenandoah. It's all smallish improvements, bug-fixes, > cleanups, etc. > > Changesets: > http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/changesets.txt > > Full webrev: > http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/webrev.00/ > > Merge was almost trivial. Most changes in shared code actually revert > Shenandoah-specific changes. > > Testing: shenandoah/jdk8 has baked in our nightly CI runs for quite a > while. I have run build and hotspot_gc_shenandoah locally after the > merge for sanity-test > > Can I get a review? > > Thanks, > Roman > From shade at redhat.com Fri Mar 6 17:49:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Mar 2020 18:49:06 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration from Shenandoah In-Reply-To: <16a0f235-e66b-9c28-6928-9b8c649c4c5c@redhat.com> References: <008bc3ef-2d73-76cb-a3b6-cd1386f2791a@redhat.com> <16a0f235-e66b-9c28-6928-9b8c649c4c5c@redhat.com> Message-ID: On 3/6/20 6:22 PM, Roman Kennke wrote: > Changeset: > http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/changesets.01 > > Full webrev: > http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/webrev.01/ This looks good to me. Andrews need to concur before we can push :) -- Thanks, -Aleksey From nick.gasson at arm.com Mon Mar 9 07:00:59 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 09 Mar 2020 15:00:59 +0800 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 Message-ID: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8240353 Webrev: http://cr.openjdk.java.net/~ngasson/8240353/webrev.0/ Runtime1::generate_code_for is missing an implementation for dtrace_object_alloc and LIR_Assembler::emit_unwind_handler is missing a call to SharedRuntime::dtrace_method_exit. Currently the interpreter always checks the value of DTraceMethodProbes on every method entry/exit, but as far as I can tell, this value can only be changed after startup by share/services/dtraceAttacher.cpp and that is only built on Solaris. With this patch the interpreter code to enable these probes is only generated if the appropriate command line options are passed. Might be worth making the same change in the other non-Solaris ports. MacroAssembler::SkipIfEqual is unused now so could be removed. Tested jtreg hotspot_all_no_apps and jdk tier1 with -XX:+ExtendedDTraceProbes. Also used bpftrace to check the method_entry, method_return, and object_alloc probes are triggered correctly. E.g. bpftrace -e 'usdt::hotspot:method__entry { printf("tid:%d, class:%s, name:%s, sig:%s\n", arg0, str(arg1, arg2), str(arg3, arg4), str(arg5, arg6)); }' -p `pidof java` But this needs the very latest bpftrace/libbcc due to some other issues on AArch64. Thanks, Nick From aph at redhat.com Mon Mar 9 10:48:55 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Mar 2020 10:48:55 +0000 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> References: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> Message-ID: <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> On 3/9/20 7:00 AM, Nick Gasson wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8240353 > Webrev: http://cr.openjdk.java.net/~ngasson/8240353/webrev.0/ > > Runtime1::generate_code_for is missing an implementation for > dtrace_object_alloc and LIR_Assembler::emit_unwind_handler is > missing a call to SharedRuntime::dtrace_method_exit. > > Currently the interpreter always checks the value of > DTraceMethodProbes on every method entry/exit, but as far as I can > tell, this value can only be changed after startup by > share/services/dtraceAttacher.cpp and that is only built on > Solaris. With this patch the interpreter code to enable these probes > is only generated if the appropriate command line options are > passed. Might be worth making the same change in the other > non-Solaris ports. I wonder what the actual intent was here, and whether anyone has a use for being able to enable dtrace method probes late. > MacroAssembler::SkipIfEqual is unused now so could be removed. > Tested jtreg hotspot_all_no_apps and jdk tier1 with > -XX:+ExtendedDTraceProbes. > > Also used bpftrace to check the method_entry, method_return, and > object_alloc probes are triggered correctly. E.g. > > bpftrace -e 'usdt::hotspot:method__entry { printf("tid:%d, class:%s, name:%s, sig:%s\n", arg0, str(arg1, arg2), str(arg3, arg4), str(arg5, arg6)); }' -p `pidof java` > > But this needs the very latest bpftrace/libbcc due to some other > issues on AArch64. Hmm, what a pain. Can you tell us what you did to make this work? What packages you built and installed? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Tue Mar 10 03:56:09 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 10 Mar 2020 11:56:09 +0800 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> References: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> Message-ID: <855zfc3lt2.fsf@arm.com> Hi Andrew, On 03/09/20 18:48 pm, Andrew Haley wrote: >> >> Also used bpftrace to check the method_entry, method_return, and >> object_alloc probes are triggered correctly. E.g. >> >> bpftrace -e 'usdt::hotspot:method__entry { printf("tid:%d, class:%s, name:%s, sig:%s\n", arg0, str(arg1, arg2), str(arg3, arg4), str(arg5, arg6)); }' -p `pidof java` >> >> But this needs the very latest bpftrace/libbcc due to some other >> issues on AArch64. > > Hmm, what a pain. Can you tell us what you did to make this work? What > packages you built and installed? Specifically you need these two patches: https://github.com/iovisor/bcc/commit/5011f992b3167c162b5a0ad57fd3fa23c9ea76b3.patch https://github.com/iovisor/bpftrace/commit/ee5314ba23cc60e903b626b14bcfaafa3aa8b11b.patch They apply cleanly on the "bcc" and "bpftrace" packages in Fedora 31. Alternatively you can build the master branch of iovisor/bcc and iovisor/bpftrace on GitHub from source. Thanks, Nick From sgehwolf at redhat.com Wed Mar 11 12:21:47 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 11 Mar 2020 13:21:47 +0100 Subject: [aarch64-port-dev ] [RFR 8u]: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <696230af-071b-e11f-b122-718f0def7d0a@redhat.com> References: <88b720d16f853b744a8f97d7de8a99a8c2514d85.camel@redhat.com> <696230af-071b-e11f-b122-718f0def7d0a@redhat.com> Message-ID: <40dba26fe65ee8e7bbf7c3fe780402b6c89c4c9c.camel@redhat.com> On Fri, 2020-03-06 at 14:02 +0000, Andrew Haley wrote: > On 3/6/20 1:36 PM, Severin Gehwolf wrote: > > While we could backport only the relevant hunk to fix the GCC 10 issue > > I've tried a more complete backport as it seems to be fixing a couple > > of code issues. If it's preferred, I can do a select backport of [1] > > too. Thoughts? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224851/01/webrev/ > > JDK 11u change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/15cc1c8a6371 > > This webrev looks very close to what I'd do. The fixes you've made > look correct, and in some cases are real bugs which impact code > generation. > > OK. Thanks for the review! If somebody could sponsor this patch for me I'd appreciate it. I'm not a committer for the aarch64-port project. HG exported patch is here: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224851/JDK-8224851.aarch64.export.patch Thanks, Severin From aph at redhat.com Wed Mar 11 14:03:23 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 11 Mar 2020 14:03:23 +0000 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> References: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> Message-ID: <327b3f6c-20ee-69ba-ada8-90e79ea34ce3@redhat.com> On 3/9/20 10:48 AM, Andrew Haley wrote: > On 3/9/20 7:00 AM, Nick Gasson wrote: > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8240353 >> Webrev: http://cr.openjdk.java.net/~ngasson/8240353/webrev.0/ >> >> Runtime1::generate_code_for is missing an implementation for >> dtrace_object_alloc and LIR_Assembler::emit_unwind_handler is >> missing a call to SharedRuntime::dtrace_method_exit. >> >> Currently the interpreter always checks the value of >> DTraceMethodProbes on every method entry/exit, but as far as I can >> tell, this value can only be changed after startup by >> share/services/dtraceAttacher.cpp and that is only built on >> Solaris. With this patch the interpreter code to enable these probes >> is only generated if the appropriate command line options are >> passed. Might be worth making the same change in the other >> non-Solaris ports. > > I wonder what the actual intent was here, and whether anyone has a use > for being able to enable dtrace method probes late. Thinking some more, ISTM that changing all this code so that it's tested at startup rather than runtime doesn't gain us very much and potentially closes the door future improvements in this area. I think your patch would be smaller and simpler otherwise. Is the overhead of that test-and-branch significant? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Mar 11 14:06:46 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 11 Mar 2020 14:06:46 +0000 Subject: [aarch64-port-dev ] RFR: Bulk integration from Shenandoah In-Reply-To: References: <008bc3ef-2d73-76cb-a3b6-cd1386f2791a@redhat.com> <16a0f235-e66b-9c28-6928-9b8c649c4c5c@redhat.com> Message-ID: On 3/6/20 5:49 PM, Aleksey Shipilev wrote: > On 3/6/20 6:22 PM, Roman Kennke wrote: >> Changeset: >> http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/changesets.01 >> >> Full webrev: >> http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/webrev.01/ > > This looks good to me. > > Andrews need to concur before we can push :) LGTM too. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Wed Mar 11 16:56:22 2020 From: rkennke at redhat.com (rkennke at redhat.com) Date: Wed, 11 Mar 2020 16:56:22 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 53 new changesets Message-ID: <202003111656.02BGuMQs003963@aojmv0008.oracle.com> Changeset: 68559d22b634 Author: roland Date: 2020-01-09 17:26 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/68559d22b634 [backport] 8237007: Shenandoah: assert(_base == Tuple) failure during C2 compilation Reviewed-by: thartmann, rkennke ! src/share/vm/opto/loopnode.cpp + test/gc/shenandoah/compiler/LRBRightAfterMemBar.java Changeset: b1fa7dcb0327 Author: shade Date: 2019-07-05 23:31 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b1fa7dcb0327 [backport] 8227327: Shenandoah: Faster and more parallel tests Reviewed-by: rkennke ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestHeapUncommit.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestRefprocSanity.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/TestStringDedup.java ! test/gc/shenandoah/TestStringDedupStress.java ! test/gc/shenandoah/TestStringInternCleanup.java ! test/gc/shenandoah/TestVerifyJCStress.java ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java Changeset: 0fd338502602 Author: shade Date: 2020-01-21 13:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0fd338502602 [backport] 8237570: Shenandoah: cleanup uses of allocation/free threshold in static heuristics Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/options/TestArgumentRanges.java Changeset: 6f8ac0de653a Author: shade Date: 2020-01-21 20:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6f8ac0de653a [backport] 8237586: Shenandoah: provide option to disable periodic GC Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! test/gc/shenandoah/TestPeriodicGC.java Changeset: 17e8f02e8f57 Author: zgu Date: 2020-01-13 13:53 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/17e8f02e8f57 [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test Reviewed-by: shade ! test/gc/shenandoah/TestEvilSyncBug.java Changeset: 8f1ba54ee8e9 Author: zgu Date: 2019-11-08 11:41 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8f1ba54ee8e9 [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp Changeset: 1a1835e9c5ff Author: rkennke Date: 2020-01-10 12:42 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1a1835e9c5ff [backport] 8236851: Shenandoah: More details in Traversal GC event messages Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 0c5ebf7e9b67 Author: rkennke Date: 2019-12-17 18:23 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0c5ebf7e9b67 [backport] 8236106: [TESTBUG] Shenandoah: Make TestThreadFailure more resilient Reviewed-by: zgu ! test/gc/shenandoah/oom/TestThreadFailure.java Changeset: 79fed43bbfa6 Author: rkennke Date: 2019-12-11 16:43 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/79fed43bbfa6 [backport] 8235729: Shenandoah: Remove useless casting to non-constant Reviewed-by: roland ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 05e54680154b Author: shade Date: 2019-11-04 19:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/05e54680154b [backport] 8233520: Shenandoah: do not sleep when thread is attaching Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: c9c9c3a12557 Author: shade Date: 2019-11-01 16:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c9c9c3a12557 [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp Changeset: 8c190b1b7295 Author: shade Date: 2020-02-10 14:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8c190b1b7295 Revert leftover changes in type.{cpp|hpp} ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 378a9e9578df Author: shade Date: 2020-02-10 17:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/378a9e9578df Rectify JDK-8191227 workaround for Shenandoah ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/debugInfo.hpp Changeset: 362e3c9e7c61 Author: zgu Date: 2019-10-15 22:22 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/362e3c9e7c61 [backport] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms Reviewed-by: rkennke, adinn ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh Changeset: 6c6f387309ef Author: rkennke Date: 2019-04-04 21:29 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6c6f387309ef [backport] 8221848: Shenandoah: ArrayCopy post-barrier improvements Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 59f20d8c67a7 Author: rkennke Date: 2019-09-18 20:56 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/59f20d8c67a7 [backport] 8231086: Shenandoah: Stronger invariant for object-arraycopy Reviewed-by: shade ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! 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/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: d8f891aedf83 Author: shade Date: 2019-09-25 12:21 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d8f891aedf83 [backport] 8231410: Shenandoah: clone barrier should use base pointer Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp + test/gc/shenandoah/compiler/TestClone.java Changeset: 2f3e38ad18f8 Author: rkennke Date: 2019-09-25 12:33 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2f3e38ad18f8 [backport] 8231447: Shenandoah: Compilation-time regression after JDK-8231086 Reviewed-by: shade ! 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/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/prims/jvm.cpp Changeset: b3c034cecfe2 Author: rkennke Date: 2019-09-30 17:00 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b3c034cecfe2 [backport] 8231499: Shenandoah: compiler/arraycopy/TestDefaultMethodArrayCloneDeoptC2 fails Reviewed-by: shade, roland ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp Changeset: 47f730c94ab9 Author: shade Date: 2019-10-22 14:05 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/47f730c94ab9 [backport] 8232778: Shenandoah: SBSA::arraycopy_prologue checks wrong register Reviewed-by: rkennke ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp Changeset: 10f9960b52d6 Author: shade Date: 2019-09-30 22:39 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/10f9960b52d6 [backport] 8222766: Shenandoah: streamline post-LRB CAS barrier (x86) Reviewed-by: rkennke ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp Changeset: af2530043788 Author: roland Date: 2019-12-06 16:21 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/af2530043788 [backport] 8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: 428fea63a7ae Author: shade Date: 2020-02-25 21:10 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/428fea63a7ae Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject Reviewed-by: rkennke ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 530550e5df24 Author: rkennke Date: 2020-02-24 13:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/530550e5df24 [backport] 8221751: Shenandoah: Improve SATB enqueueing Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp Changeset: 006f1305bbf3 Author: rkennke Date: 2020-02-24 15:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/006f1305bbf3 [backport] 8224179: Shenandoah: CTW test failures with traversal GC Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: b0e783f94bab Author: rkennke Date: 2020-02-24 18:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b0e783f94bab [backport] 8223951: Shenandoah: Only need to update thread roots during final update refs Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 094c655cc519 Author: rkennke Date: 2020-02-24 17:36 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/094c655cc519 [backport] 8224495: Shenandoah: Do not rescan code roots in final mark pause if it is not degenerated GC Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 5553af6553c2 Author: rkennke Date: 2020-02-24 18:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5553af6553c2 [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 51d249139313 Author: rkennke Date: 2020-02-27 12:23 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/51d249139313 [backport] 8225341: Shenandoah: CM::update_thread_roots() needs to handle derived pointers Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 974c2a5397a0 Author: rkennke Date: 2019-08-13 16:05 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/974c2a5397a0 AArch64: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp Changeset: c96d8694dd1e Author: zgu Date: 2019-05-22 09:10 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c96d8694dd1e [backport] 8224525: Shenandoah: Eliminate shenandoah verifier's side-effects Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 31b527293b5f Author: rkennke Date: 2019-06-03 21:28 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/31b527293b5f [backport] 8225171: Remove leftovers in shenandoahBarrierSetC1.cpp Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp Changeset: 4b30807ec868 Author: rkennke Date: 2020-02-27 15:52 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4b30807ec868 [backport] 8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: d9e2882d3f0a Author: rkennke Date: 2019-07-15 15:27 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d9e2882d3f0a [backport] 8227676: Shenandoah: More consistent naming of LRB entry points Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: 0056140b1daa Author: rkennke Date: 2019-07-18 13:16 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0056140b1daa [backport] 8228364: Shenandoah: Remove unused code from ShenandoahBarrierSetC1 Reviewed-by: shade ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp Changeset: d845c1213174 Author: shade Date: 2019-08-19 19:58 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d845c1213174 [backport] 8229865: Use explicit #include debug.hpp for STATIC_ASSERT in gc/shenandoah/shenandoahUtils.cpp Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: e09ffdffec03 Author: zgu Date: 2019-09-23 07:45 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e09ffdffec03 [backport] 8231293: Shenandoah: Traversal should not revive dead weak roots Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: 71630756c297 Author: shade Date: 2019-10-15 19:38 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/71630756c297 [backport] 8232205: Shenandoah: missing "Update References" -> "Update Roots" tracing Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 905014d2b2a2 Author: shade Date: 2019-10-24 11:49 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/905014d2b2a2 [backport] 8232908: Shenandoah: compact heuristics has incorrect trigger "Free is lower than allocated recently" Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp Changeset: e5fa0011685a Author: jiefu Date: 2019-11-15 20:39 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e5fa0011685a [backport] 8234232: [TESTBUG] gc/shenandoah/jvmti/TestHeapDump.java fails with -Xcomp Reviewed-by: zgu ! test/gc/shenandoah/jvmti/TestHeapDump.java Changeset: 0d3beb625e5a Author: rkennke Date: 2020-02-28 20:50 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0d3beb625e5a 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 Reviewed-by: rkennke ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: fc5b978c83e4 Author: rkennke Date: 2020-01-07 21:53 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fc5b978c83e4 [backport] 8236732: Shenandoah: Stricter placement for oom-evac scopes Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.inline.hpp Changeset: 94480154d35c Author: rkennke Date: 2020-01-07 13:45 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/94480154d35c [backport] 8236181: C2: Remove useless step_over_gc_barrier() in int->bool conversion Reviewed-by: thartmann, roland ! src/share/vm/opto/cfgnode.cpp Changeset: 0f4ab5ec73a7 Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0f4ab5ec73a7 [backport] 8240070: Shenandoah: remove obsolete ShenandoahCommonGCStateLoads Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp - test/gc/shenandoah/compiler/TestCommonGCLoads.java Changeset: 364c0c74df65 Author: shade Date: 2020-02-24 18:30 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/364c0c74df65 [backport] 8239868: Shenandoah: ditch C2 node limit adjustments Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp Changeset: 9652b154d2cd Author: shade Date: 2020-02-25 12:35 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9652b154d2cd [backport] 8239904: Shenandoah: accumulated penalties should not be over 100% of capacity Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: 987a83a9970c Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/987a83a9970c [backport] 8240069: Shenandoah: turn more flags diagnostic Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/options/TestCodeCacheRootStyles.java Changeset: 8a663272a9a7 Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8a663272a9a7 [backport] 8240076: Shenandoah: pacer should cover reset and preclean phases Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp Changeset: 082658680ab7 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/082658680ab7 [backport] 8240215: Shenandoah: remove ShenandoahAllocationTrace Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 7bed7e10d3ba Author: shade Date: 2020-03-03 08:05 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7bed7e10d3ba Fix tier2_gc_shenandoah group definition ! test/TEST.groups Changeset: a594fe530dd9 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a594fe530dd9 [backport] 8240216: Shenandoah: remove ShenandoahTerminationTrace Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 8af4d432bf4c Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8af4d432bf4c [backport] 8240217: Shenandoah: remove ShenandoahEvacAssist Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 5a667d30f1c2 Author: shade Date: 2020-03-04 19:23 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5a667d30f1c2 [backport] 8240534: Shenandoah: ditch debug safepoint timeout adjustment Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp From nick.gasson at arm.com Thu Mar 12 07:41:29 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 12 Mar 2020 15:41:29 +0800 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: <327b3f6c-20ee-69ba-ada8-90e79ea34ce3@redhat.com> References: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> <327b3f6c-20ee-69ba-ada8-90e79ea34ce3@redhat.com> Message-ID: <854kuu2f6e.fsf@arm.com> Hi Andrew, On 03/11/20 22:03 pm, Andrew Haley wrote: >> >> I wonder what the actual intent was here, and whether anyone has a use >> for being able to enable dtrace method probes late. > > Thinking some more, ISTM that changing all this code so that it's > tested at startup rather than runtime doesn't gain us very much and > potentially closes the door future improvements in this area. I think > your patch would be smaller and simpler otherwise. > > Is the overhead of that test-and-branch significant? Not really: with a contrived benchmark like the following the overhead is around 1% when using -Xint. public static long ackermann(long m, long n) { if (m == 0) return n + 1; if (n == 0) return ackermann(m - 1, 1); return ackermann(m - 1, ackermann(m, n - 1)); } @Benchmark public long manyCalls() { return ackermann(3, 6); } Revert that part of the patch? Nick From aph at redhat.com Thu Mar 12 10:27:49 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Mar 2020 10:27:49 +0000 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: <854kuu2f6e.fsf@arm.com> References: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> <327b3f6c-20ee-69ba-ada8-90e79ea34ce3@redhat.com> <854kuu2f6e.fsf@arm.com> Message-ID: <32f5e15f-d0a0-89af-9139-2db8e1e0c1e0@redhat.com> On 3/12/20 7:41 AM, Nick Gasson wrote: > Revert that part of the patch? Please do. It may well be that one day this runtime checking is disabled in all ports, but let's wait 'til then. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Fri Mar 13 08:06:45 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 13 Mar 2020 16:06:45 +0800 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: <32f5e15f-d0a0-89af-9139-2db8e1e0c1e0@redhat.com> References: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> <327b3f6c-20ee-69ba-ada8-90e79ea34ce3@redhat.com> <854kuu2f6e.fsf@arm.com> <32f5e15f-d0a0-89af-9139-2db8e1e0c1e0@redhat.com> Message-ID: <8536ac3ch6.fsf@arm.com> On 03/12/20 18:27 pm, Andrew Haley wrote: > On 3/12/20 7:41 AM, Nick Gasson wrote: >> Revert that part of the patch? > > Please do. It may well be that one day this runtime checking is disabled > in all ports, but let's wait 'til then. OK, how about this one? http://cr.openjdk.java.net/~ngasson/8240353/webrev.1/ Thanks, Nick From aph at redhat.com Fri Mar 13 09:11:48 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Mar 2020 09:11:48 +0000 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: <8536ac3ch6.fsf@arm.com> References: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> <327b3f6c-20ee-69ba-ada8-90e79ea34ce3@redhat.com> <854kuu2f6e.fsf@arm.com> <32f5e15f-d0a0-89af-9139-2db8e1e0c1e0@redhat.com> <8536ac3ch6.fsf@arm.com> Message-ID: <2c2d1061-6e80-86f4-786c-0ddc15531e8e@redhat.com> On 3/13/20 8:06 AM, Nick Gasson wrote: > On 03/12/20 18:27 pm, Andrew Haley wrote: >> On 3/12/20 7:41 AM, Nick Gasson wrote: >>> Revert that part of the patch? >> >> Please do. It may well be that one day this runtime checking is disabled >> in all ports, but let's wait 'til then. > > OK, how about this one? > > http://cr.openjdk.java.net/~ngasson/8240353/webrev.1/ OK. One more thing: it's a little bit more readable if you use the names c_rarg0 etc. for native calls. I know we're not consistent about that, but we rather should be. No, you don't need to submit a new webrev for that. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Mar 16 01:25:25 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 16 Mar 2020 01:25:25 +0000 Subject: [aarch64-port-dev ] [RFR 8u]: 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 In-Reply-To: <40dba26fe65ee8e7bbf7c3fe780402b6c89c4c9c.camel@redhat.com> References: <88b720d16f853b744a8f97d7de8a99a8c2514d85.camel@redhat.com> <696230af-071b-e11f-b122-718f0def7d0a@redhat.com> <40dba26fe65ee8e7bbf7c3fe780402b6c89c4c9c.camel@redhat.com> Message-ID: On 11/03/2020 12:21, Severin Gehwolf wrote: > On Fri, 2020-03-06 at 14:02 +0000, Andrew Haley wrote: >> On 3/6/20 1:36 PM, Severin Gehwolf wrote: >>> While we could backport only the relevant hunk to fix the GCC 10 issue >>> I've tried a more complete backport as it seems to be fixing a couple >>> of code issues. If it's preferred, I can do a select backport of [1] >>> too. Thoughts? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224851 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224851/01/webrev/ >>> JDK 11u change: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/15cc1c8a6371 >> >> This webrev looks very close to what I'd do. The fixes you've made >> look correct, and in some cases are real bugs which impact code >> generation. >> >> OK. > > Thanks for the review! > > If somebody could sponsor this patch for me I'd appreciate it. I'm not > a committer for the aarch64-port project. > > HG exported patch is here: > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8224851/JDK-8224851.aarch64.export.patch > > Thanks, > Severin > Pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Mar 16 01:42:48 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 16 Mar 2020 01:42:48 +0000 Subject: [aarch64-port-dev ] RFR: Bulk integration from Shenandoah In-Reply-To: References: <008bc3ef-2d73-76cb-a3b6-cd1386f2791a@redhat.com> <16a0f235-e66b-9c28-6928-9b8c649c4c5c@redhat.com> Message-ID: On 06/03/2020 17:49, Aleksey Shipilev wrote: > On 3/6/20 6:22 PM, Roman Kennke wrote: >> Changeset: >> http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/changesets.01 >> >> Full webrev: >> http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/webrev.01/ > > This looks good to me. > > Andrews need to concur before we can push :) > These would be easier to review if the cumulative effect of the changes could be more easily seen. I was going to suggest including the merge changeset, but this doesn't appear to be a merge. Why are we not just pushing these to aarch64/shenandoah-jdk8u as they are developed, rather than waiting to do them all in bulk? Particularly as it's relatively late in the development process for the April CPU. Most of these seem to be Shenandoah-specific. The one that catches my eye is: 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms This seems like it will introduce a behavioural deviation for those who are not using Shenandoah, in comparison to vanilla 8u. Can you assure me this is safe? I do wonder if patches like this should be backported to upstream 8u & 11u, ahead of any proposed Shenandoah merge into those upstreams. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From nick.gasson at arm.com Mon Mar 16 02:55:00 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 16 Mar 2020 10:55:00 +0800 Subject: [aarch64-port-dev ] RFR: 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 In-Reply-To: <2c2d1061-6e80-86f4-786c-0ddc15531e8e@redhat.com> References: <85v9ne2es4.fsf@nicgas01-03-arm-vm.shanghai.arm.com> <4d0c6d5b-8aed-e09e-1872-60a9fdd2e7b6@redhat.com> <327b3f6c-20ee-69ba-ada8-90e79ea34ce3@redhat.com> <854kuu2f6e.fsf@arm.com> <32f5e15f-d0a0-89af-9139-2db8e1e0c1e0@redhat.com> <8536ac3ch6.fsf@arm.com> <2c2d1061-6e80-86f4-786c-0ddc15531e8e@redhat.com> Message-ID: <85zhch101n.fsf@arm.com> On 03/13/20 17:11 pm, Andrew Haley wrote: > > OK. One more thing: it's a little bit more readable if you use the names > c_rarg0 etc. for native calls. I know we're not consistent about that, but > we rather should be. No, you don't need to submit a new webrev for that. Thanks, pushed here: http://hg.openjdk.java.net/jdk/jdk/rev/981b5a0c43da Nick From rkennke at redhat.com Mon Mar 16 20:16:14 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 16 Mar 2020 21:16:14 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration from Shenandoah In-Reply-To: References: <008bc3ef-2d73-76cb-a3b6-cd1386f2791a@redhat.com> <16a0f235-e66b-9c28-6928-9b8c649c4c5c@redhat.com> Message-ID: <912165ed-f7c0-9104-914a-c6a5b26e4aeb@redhat.com> Hi Andrew, > On 06/03/2020 17:49, Aleksey Shipilev wrote: >> On 3/6/20 6:22 PM, Roman Kennke wrote: >>> Changeset: >>> http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/changesets.01 >>> >>> Full webrev: >>> http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/webrev.01/ >> >> This looks good to me. >> >> Andrews need to concur before we can push :) >> > > These would be easier to review if the cumulative effect of the changes > could be more easily seen. I was going to suggest including the merge > changeset, but this doesn't appear to be a merge. Well yeah. The cumulative effect of the patches is exactly what you see here :-) > Why are we not just > pushing these to aarch64/shenandoah-jdk8u as they are developed, rather > than waiting to do them all in bulk? Particularly as it's relatively > late in the development process for the April CPU. I was thinking why are we integrating this to aarch64/jdk8u-shenandoah at all? We could also use shenandoah/jdk8 as integration forest. shenandoah/jdk8 has aarch64/jdk8 as upstream, which in turn has jdk8u as upstream. Dragging everything into aarch64/jdk8u-shenandoah is just a somewhat unnecessary extra step. > Most of these seem to be Shenandoah-specific. The one that catches my > eye is: > > 8229919: Support JNI Critical functions in object pinning API on x86_32 > platforms > > This seems like it will introduce a behavioural deviation for those who > are not using Shenandoah, in comparison to vanilla 8u. Can you assure me > this is safe? Yes. This code is only entered when Universe::heap()->supports_object_pinning() returns true, and Shenandoah is currently the only implementation that does this. In the x86_32 counterparts I actually put assert(UseShenandoahGC) in a couple of relevant places, I forgot this in x86_32. Sorry. > I do wonder if patches like this should be backported to upstream 8u & > 11u, ahead of any proposed Shenandoah merge into those upstreams. I was considering this. But it would be dead code upstream. So no. The integration has already been pushed. I hope that's ok. Roman From gnu.andrew at redhat.com Mon Mar 16 21:14:21 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 16 Mar 2020 21:14:21 +0000 Subject: [aarch64-port-dev ] RFR: Bulk integration from Shenandoah In-Reply-To: <912165ed-f7c0-9104-914a-c6a5b26e4aeb@redhat.com> References: <008bc3ef-2d73-76cb-a3b6-cd1386f2791a@redhat.com> <16a0f235-e66b-9c28-6928-9b8c649c4c5c@redhat.com> <912165ed-f7c0-9104-914a-c6a5b26e4aeb@redhat.com> Message-ID: <9319b9bf-6ac9-9fc5-ca26-ee00228457ce@redhat.com> On 16/03/2020 20:16, Roman Kennke wrote: > Hi Andrew, > >> On 06/03/2020 17:49, Aleksey Shipilev wrote: >>> On 3/6/20 6:22 PM, Roman Kennke wrote: >>>> Changeset: >>>> http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/changesets.01 >>>> >>>> Full webrev: >>>> http://cr.openjdk.java.net/~rkennke/bulk-integration-2020-03-06/webrev.01/ >>> >>> This looks good to me. >>> >>> Andrews need to concur before we can push :) >>> >> >> These would be easier to review if the cumulative effect of the changes >> could be more easily seen. I was going to suggest including the merge >> changeset, but this doesn't appear to be a merge. > > Well yeah. The cumulative effect of the patches is exactly what you see > here :-) See where? The webrev has individual patches. > >> Why are we not just >> pushing these to aarch64/shenandoah-jdk8u as they are developed, rather >> than waiting to do them all in bulk? Particularly as it's relatively >> late in the development process for the April CPU. > > I was thinking why are we integrating this to aarch64/jdk8u-shenandoah > at all? We could also use shenandoah/jdk8 as integration forest. > shenandoah/jdk8 has aarch64/jdk8 as upstream, which in turn has jdk8u as > upstream. Dragging everything into aarch64/jdk8u-shenandoah is just a > somewhat unnecessary extra step. Funny, I was thinking you could just use aarch64/jdk8u-shenandoah. I don't see why shenandoah/jdk8 is needed at all. > >> Most of these seem to be Shenandoah-specific. The one that catches my >> eye is: >> >> 8229919: Support JNI Critical functions in object pinning API on x86_32 >> platforms >> >> This seems like it will introduce a behavioural deviation for those who >> are not using Shenandoah, in comparison to vanilla 8u. Can you assure me >> this is safe? > > Yes. This code is only entered when > Universe::heap()->supports_object_pinning() returns true, and Shenandoah > is currently the only implementation that does this. In the x86_32 > counterparts I actually put assert(UseShenandoahGC) in a couple of > relevant places, I forgot this in x86_32. Sorry. That sounds ok. It's certainly not obvious from the patchset though. > >> I do wonder if patches like this should be backported to upstream 8u & >> 11u, ahead of any proposed Shenandoah merge into those upstreams. > > I was considering this. But it would be dead code upstream. So no. Well, the point is it wouldn't be dead code if the long term plan was to add Shenandoah. Getting shared code changes like this in first means the final Shenandoah merge can largely be new code. It's the shared code changes that affect other users. > > The integration has already been pushed. I hope that's ok. > x Yes, I noticed when tagging the next build promotion. > Roman > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Mar 17 09:28:57 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 17 Mar 2020 09:28:57 +0000 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b06 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b06: - S8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 - S8225130: Add exception for expiring Comodo roots to VerifyCACerts test - S8230235: Rendering HTML with empty img attribute and documentBaseKey cause Exception - S8235744: PIT: test/jdk/javax/swing/text/html/TestJLabelWithHTMLText.java times out in linux-x64 - S8240521: Revert backport of 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call I also added a tag for the Shenandoah integration, which seems to have been missed this time around. This allowed these changes to be filtered out of the webrev. Changes in aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06: - AArch64: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject - [backport] 8221751: Shenandoah: Improve SATB enqueueing - [backport] 8221848: Shenandoah: ArrayCopy post-barrier improvements - [backport] 8222766: Shenandoah: streamline post-LRB CAS barrier (x86) - [backport] 8223951: Shenandoah: Only need to update thread roots during final update refs - [backport] 8224179: Shenandoah: CTW test failures with traversal GC - [backport] 8224495: Shenandoah: Do not rescan code roots in final mark pause if it is not degenerated GC - [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle - [backport] 8224525: Shenandoah: Eliminate shenandoah verifier's side-effects - [backport] 8225171: Remove leftovers in shenandoahBarrierSetC1.cpp - [backport] 8225341: Shenandoah: CM::update_thread_roots() needs to handle derived pointers - [backport] 8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC - [backport] 8227327: Shenandoah: Faster and more parallel tests - [backport] 8227676: Shenandoah: More consistent naming of LRB entry points - [backport] 8228364: Shenandoah: Remove unused code from ShenandoahBarrierSetC1 - [backport] 8229865: Use explicit #include debug.hpp for STATIC_ASSERT in gc/shenandoah/shenandoahUtils.cpp - [backport] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms - [backport] 8231086: Shenandoah: Stronger invariant for object-arraycopy - [backport] 8231293: Shenandoah: Traversal should not revive dead weak roots - [backport] 8231410: Shenandoah: clone barrier should use base pointer - [backport] 8231447: Shenandoah: Compilation-time regression after JDK-8231086 - [backport] 8231499: Shenandoah: compiler/arraycopy/TestDefaultMethodArrayCloneDeoptC2 fails - [backport] 8232205: Shenandoah: missing "Update References" -> "Update Roots" tracing - [backport] 8232778: Shenandoah: SBSA::arraycopy_prologue checks wrong register - [backport] 8232908: Shenandoah: compact heuristics has incorrect trigger "Free is lower than allocated recently" - [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically - [backport] 8233520: Shenandoah: do not sleep when thread is attaching - [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware - [backport] 8234232: [TESTBUG] gc/shenandoah/jvmti/TestHeapDump.java fails with -Xcomp - [backport] 8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411 - [backport] 8235729: Shenandoah: Remove useless casting to non-constant - [backport] 8236106: [TESTBUG] Shenandoah: Make TestThreadFailure more resilient - [backport] 8236181: C2: Remove useless step_over_gc_barrier() in int->bool conversion - [backport] 8236732: Shenandoah: Stricter placement for oom-evac scopes - [backport] 8236851: Shenandoah: More details in Traversal GC event messages - [backport] 8237007: Shenandoah: assert(_base == Tuple) failure during C2 compilation - [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test - [backport] 8237570: Shenandoah: cleanup uses of allocation/free threshold in static heuristics - [backport] 8237586: Shenandoah: provide option to disable periodic GC - [backport] 8239868: Shenandoah: ditch C2 node limit adjustments - [backport] 8239904: Shenandoah: accumulated penalties should not be over 100% of capacity - [backport] 8240069: Shenandoah: turn more flags diagnostic - [backport] 8240070: Shenandoah: remove obsolete ShenandoahCommonGCStateLoads - [backport] 8240076: Shenandoah: pacer should cover reset and preclean phases - [backport] 8240215: Shenandoah: remove ShenandoahAllocationTrace - [backport] 8240216: Shenandoah: remove ShenandoahTerminationTrace - [backport] 8240217: Shenandoah: remove ShenandoahEvacAssist - [backport] 8240534: Shenandoah: ditch debug safepoint timeout adjustment - Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject - Fix tier2_gc_shenandoah group definition - Rectify JDK-8191227 workaround for Shenandoah - Revert leftover changes in type.{cpp|hpp} - S8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 Main issues of note: No HotSpot changes, so no merge work. 8224851 is local to this repository and already pushed. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk a/test/java/lang/Runtime/loadLibrary/LoadLibraryTest.java | 156 -------------- a/test/java/lang/Runtime/loadLibrary/src/Target.java | 34 --- a/test/java/lang/Runtime/loadLibrary/src/Target2.java | 29 -- b/.hgtags | 1 b/src/share/classes/java/lang/ClassLoader.java | 32 -- b/src/share/classes/java/lang/Runtime.java | 7 b/src/share/classes/java/lang/System.java | 2 b/src/share/classes/javax/swing/text/html/ImageView.java | 17 + b/test/javax/swing/text/html/TestJLabelWithHTMLText.java | 51 ++++ b/test/sun/security/lib/cacerts/VerifyCACerts.java | 6 10 files changed, 83 insertions(+), 252 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Tue Mar 17 11:54:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 17 Mar 2020 12:54:58 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b06 Upstream Sync In-Reply-To: References: Message-ID: On 3/17/20 10:28 AM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/jdk/merge.changeset Looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b06/root/merge.changeset Look trivially good. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From ci_notify at linaro.org Tue Mar 17 21:06:30 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 17 Mar 2020 21:06:30 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1408868538.10401.1584479191378.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2020/066/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/08 pass: 5,766; fail: 45 Build 1: aarch64/2020/jan/10 pass: 5,769; fail: 45 Build 2: aarch64/2020/jan/13 pass: 5,770; fail: 44 Build 3: aarch64/2020/jan/15 pass: 5,770; fail: 46 Build 4: aarch64/2020/jan/20 pass: 5,776; fail: 44 Build 5: aarch64/2020/jan/22 pass: 5,776; fail: 44 Build 6: aarch64/2020/jan/24 pass: 5,775; fail: 45 Build 7: aarch64/2020/jan/27 pass: 5,776; fail: 44 Build 8: aarch64/2020/jan/29 pass: 5,776; fail: 44 Build 9: aarch64/2020/feb/01 pass: 5,777; fail: 46 Build 10: aarch64/2020/feb/03 pass: 5,777; fail: 46 Build 11: aarch64/2020/feb/05 pass: 5,778; fail: 46 Build 12: aarch64/2020/feb/10 pass: 5,781; fail: 46 Build 13: aarch64/2020/feb/12 pass: 5,786; fail: 46 Build 14: aarch64/2020/mar/06 pass: 5,797; fail: 46 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/08 pass: 8,821; fail: 532; error: 14 Build 1: aarch64/2020/jan/10 pass: 8,830; fail: 521; error: 18 Build 2: aarch64/2020/jan/13 pass: 8,825; fail: 524; error: 20 Build 3: aarch64/2020/jan/15 pass: 8,827; fail: 524; error: 19 Build 4: aarch64/2020/jan/20 pass: 8,830; fail: 529; error: 16 Build 5: aarch64/2020/jan/22 pass: 8,829; fail: 528; error: 19 Build 6: aarch64/2020/jan/24 pass: 8,832; fail: 537; error: 16 Build 7: aarch64/2020/jan/27 pass: 8,846; fail: 523; error: 17 Build 8: aarch64/2020/jan/29 pass: 8,844; fail: 522; error: 19 Build 9: aarch64/2020/feb/01 pass: 8,848; fail: 523; error: 18 Build 10: aarch64/2020/feb/03 pass: 8,851; fail: 525; error: 15 Build 11: aarch64/2020/feb/05 pass: 8,851; fail: 526; error: 15 Build 12: aarch64/2020/feb/10 pass: 8,858; fail: 518; error: 20 Build 13: aarch64/2020/feb/12 pass: 8,849; fail: 525; error: 17 Build 14: aarch64/2020/mar/06 pass: 8,870; fail: 526; error: 17 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/06 pass: 4,030 Build 1: aarch64/2020/jan/08 pass: 4,030 Build 2: aarch64/2020/jan/10 pass: 4,030 Build 3: aarch64/2020/jan/13 pass: 4,030 Build 4: aarch64/2020/jan/15 pass: 4,031 Build 5: aarch64/2020/jan/20 pass: 4,033 Build 6: aarch64/2020/jan/22 pass: 4,033 Build 7: aarch64/2020/jan/24 pass: 4,033 Build 8: aarch64/2020/jan/27 pass: 4,033 Build 9: aarch64/2020/feb/01 pass: 4,036 Build 10: aarch64/2020/feb/03 pass: 4,036 Build 11: aarch64/2020/feb/05 pass: 4,036 Build 12: aarch64/2020/feb/10 pass: 4,037 Build 13: aarch64/2020/feb/12 pass: 4,037 Build 14: aarch64/2020/mar/06 pass: 4,039 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 8.24x Relative performance: Server critical-jOPS (nc): 12.78x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 217.15 Server 217.15 / Server 2014-04-01 (71.00): 3.06x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/006/results/ 2020-01-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/008/results/ 2020-01-11 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/010/results/ 2020-01-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/013/results/ 2020-01-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/015/results/ 2020-01-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/020/results/ 2020-01-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/022/results/ 2020-01-25 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/024/results/ 2020-01-28 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/027/results/ 2020-02-02 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/032/results/ 2020-02-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/034/results/ 2020-02-06 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/036/results/ 2020-02-11 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/041/results/ 2020-02-13 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/043/results/ 2020-03-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/066/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From Pengfei.Li at arm.com Thu Mar 19 08:08:00 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Thu, 19 Mar 2020 08:08:00 +0000 Subject: [aarch64-port-dev ] RFR(S): 8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction" Message-ID: Hi, AArch64 C2 shows an internal error of "bad AD file" when VM option "UsePopCountInstruction" is disabled. This can be reproduced by below simple case with fastdebug build. public class Foo { private static int bar(int x) { return Integer.bitCount(x); } public static void main(String[] args) { int sum = 0; for (int i = 0; i < 30000; i++) { sum += bar(i); } System.out.println(sum); } } Cause is that the PopCountINode or PopCountLNode is created but no match rule for it without "UsePopCountInstruction" enabled. One fix [1] for this is to avoid creating the nodes. As the CNT instruction is available on all AArch64 CPUs and the bitCount() would be ~7x slower (according to my local test) if it's disabled, there is another fix [2] that force the flag to be true on AArch64. But I'm not sure if it's good to ignore a general vm option in an architecture backend. [1] http://cr.openjdk.java.net/~pli/rfr/8241091/webrev.00/ [2] http://cr.openjdk.java.net/~pli/rfr/8241091/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8241091 Please let me know which kind of fix do you prefer, or any other comments. -- Thanks, Pengfei From aph at redhat.com Thu Mar 19 10:38:01 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Mar 2020 10:38:01 +0000 Subject: [aarch64-port-dev ] RFR(S): 8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction" In-Reply-To: References: Message-ID: <31e5ace2-2dbf-e08d-90a8-2a51f0fe8925@redhat.com> On 3/19/20 8:08 AM, Pengfei Li wrote: > Cause is that the PopCountINode or PopCountLNode is created but no > match rule for it without "UsePopCountInstruction" enabled. One fix > [1] for this is to avoid creating the nodes. As the CNT instruction > is available on all AArch64 CPUs and the bitCount() would be ~7x > slower (according to my local test) if it's disabled, there is > another fix [2] that force the flag to be true on AArch64. But I'm > not sure if it's good to ignore a general vm option in an > architecture backend. We could go either way, but there's no point in disabling popcount on AArch64. So [2], but please produce an error message if "-UsePopCountInstruction" is used. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Fri Mar 20 08:40:33 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Fri, 20 Mar 2020 08:40:33 +0000 Subject: [aarch64-port-dev ] RFR(S): 8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction" In-Reply-To: <31e5ace2-2dbf-e08d-90a8-2a51f0fe8925@redhat.com> References: <31e5ace2-2dbf-e08d-90a8-2a51f0fe8925@redhat.com> Message-ID: Hi Andrew, > We could go either way, but there's no point in disabling popcount on > AArch64. So [2], but please produce an error message if "- > UsePopCountInstruction" is used. My understanding of your "error message" is a warning message instead of a hard error, as current "bad AD file" is already a hard error. The general option UsePopCountInstruction is false by default. In my updated webrev [1], the default value is changed to true for AArch64 and a warning is printed if it's turned off manually. $ java Foo 219504 $ java -XX:-UsePopCountInstruction Foo OpenJDK 64-Bit Server VM warning: UsePopCountInstruction is always enabled on this CPU 219504 Jtreg tier1 passed. Is this ok? [1] http://cr.openjdk.java.net/~pli/rfr/8241091/webrev.02/ -- Thanks, Pengfei From aph at redhat.com Fri Mar 20 09:55:25 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Mar 2020 09:55:25 +0000 Subject: [aarch64-port-dev ] RFR(S): 8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction" In-Reply-To: References: <31e5ace2-2dbf-e08d-90a8-2a51f0fe8925@redhat.com> Message-ID: On 3/20/20 8:40 AM, Pengfei Li wrote: > Hi Andrew, > >> We could go either way, but there's no point in disabling popcount on >> AArch64. So [2], but please produce an error message if "- >> UsePopCountInstruction" is used. > > My understanding of your "error message" is a warning message instead of a hard error, as current "bad AD file" is already a hard error. > > The general option UsePopCountInstruction is false by default. In my updated webrev [1], the default value is changed to true for AArch64 and a warning is printed if it's turned off manually. > > $ java Foo > 219504 > $ java -XX:-UsePopCountInstruction Foo > OpenJDK 64-Bit Server VM warning: UsePopCountInstruction is always enabled on this CPU > 219504 > > Jtreg tier1 passed. Is this ok? > > [1] http://cr.openjdk.java.net/~pli/rfr/8241091/webrev.02/ Yes, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Fri Mar 20 14:38:51 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Mar 2020 14:38:51 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 4 new changesets Message-ID: <202003201438.02KEcpFe028606@aojmv0008.oracle.com> Changeset: 746815de8b5b Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/746815de8b5b Added tag jdk8u252-b06 for changeset bb464170d344 ! .hgtags Changeset: 8cdf46c368ee Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/8cdf46c368ee Merge jdk8u252-b06 ! .hgtags Changeset: 9c4e65dab4c0 Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/9c4e65dab4c0 Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 8cdf46c368ee ! .hgtags Changeset: cd896b195b15 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/cd896b195b15 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 8f0a4b79e082 ! .hgtags From gnu.andrew at redhat.com Fri Mar 20 14:38:58 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Mar 2020 14:38:58 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 4 new changesets Message-ID: <202003201438.02KEcw5L028739@aojmv0008.oracle.com> Changeset: ee99eeee44ad Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/ee99eeee44ad Added tag jdk8u252-b06 for changeset ff8c2e73d641 ! .hgtags Changeset: 5dc906baed1d Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/5dc906baed1d Merge jdk8u252-b06 ! .hgtags Changeset: 71af329f3cfb Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/71af329f3cfb Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 5dc906baed1d ! .hgtags Changeset: 72d73e9bee2d Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/72d73e9bee2d Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 82edc7271f6b ! .hgtags From gnu.andrew at redhat.com Fri Mar 20 14:39:06 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Mar 2020 14:39:06 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 4 new changesets Message-ID: <202003201439.02KEd6cI028914@aojmv0008.oracle.com> Changeset: ca05e6121665 Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/ca05e6121665 Added tag jdk8u252-b06 for changeset 4f24bfe038c3 ! .hgtags Changeset: 0cd088a4115f Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/0cd088a4115f Merge jdk8u252-b06 ! .hgtags Changeset: 2230170ff5d9 Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/2230170ff5d9 Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 0cd088a4115f ! .hgtags Changeset: d4e68766e1b3 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/d4e68766e1b3 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset d50dc2991dea ! .hgtags From gnu.andrew at redhat.com Fri Mar 20 14:39:13 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Mar 2020 14:39:13 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 4 new changesets Message-ID: <202003201439.02KEdDTA029005@aojmv0008.oracle.com> Changeset: e86a511a486e Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/e86a511a486e Added tag jdk8u252-b06 for changeset 121cf3b001d9 ! .hgtags Changeset: 8c406f172110 Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/8c406f172110 Merge jdk8u252-b06 ! .hgtags Changeset: 497c08ff356e Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/497c08ff356e Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 8c406f172110 ! .hgtags Changeset: 9b136b5f9145 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/9b136b5f9145 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 1ff35264a334 ! .hgtags From gnu.andrew at redhat.com Fri Mar 20 14:39:21 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Mar 2020 14:39:21 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 4 new changesets Message-ID: <202003201439.02KEdLmR029094@aojmv0008.oracle.com> Changeset: 8ce7c29ca85c Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/8ce7c29ca85c Added tag jdk8u252-b06 for changeset 4010269cf496 ! .hgtags Changeset: 5091dabc613a Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/5091dabc613a Merge jdk8u252-b06 ! .hgtags Changeset: 722684ae14ba Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/722684ae14ba Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 5091dabc613a ! .hgtags Changeset: 43dc4647f6d2 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/43dc4647f6d2 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 5127eea57961 ! .hgtags From gnu.andrew at redhat.com Fri Mar 20 14:39:38 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Mar 2020 14:39:38 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 8 new changesets Message-ID: <202003201439.02KEdcOa029300@aojmv0008.oracle.com> Changeset: 3272c495f495 Author: akozlov Date: 2020-03-10 21:43 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3272c495f495 8240521: Revert backport of 8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call Reviewed-by: andrew ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Runtime.java ! src/share/classes/java/lang/System.java - test/java/lang/Runtime/loadLibrary/LoadLibraryTest.java - test/java/lang/Runtime/loadLibrary/src/Target.java - test/java/lang/Runtime/loadLibrary/src/Target2.java Changeset: ae91f2b94f84 Author: pbansal Date: 2019-11-27 11:05 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ae91f2b94f84 8230235: Rendering HTML with empty img attribute and documentBaseKey cause Exception Reviewed-by: serb, aivanov ! src/share/classes/javax/swing/text/html/ImageView.java + test/javax/swing/text/html/TestJLabelWithHTMLText.java Changeset: d37e685cb0ee Author: pbansal Date: 2019-12-13 12:08 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d37e685cb0ee 8235744: PIT: test/jdk/javax/swing/text/html/TestJLabelWithHTMLText.java times out in linux-x64 Reviewed-by: psadhukhan, prr ! test/javax/swing/text/html/TestJLabelWithHTMLText.java Changeset: 6f7370a85071 Author: rhalade Date: 2020-03-01 23:04 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/6f7370a85071 8225130: Add exception for expiring Comodo roots to VerifyCACerts test Reviewed-by: weijun ! test/sun/security/lib/cacerts/VerifyCACerts.java Changeset: 83bbe56ecea1 Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/83bbe56ecea1 Added tag jdk8u252-b06 for changeset 6f7370a85071 ! .hgtags Changeset: f51349214262 Author: andrew Date: 2020-03-16 02:20 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f51349214262 Merge jdk8u252-b06 ! .hgtags ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/System.java - test/java/lang/Runtime/loadLibrary/LoadLibraryTest.java - test/java/lang/Runtime/loadLibrary/src/Target.java - test/java/lang/Runtime/loadLibrary/src/Target2.java Changeset: f49622d69cdf Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f49622d69cdf Added tag aarch64-shenandoah-jdk8u252-b06 for changeset f51349214262 ! .hgtags Changeset: 852849b1ac52 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/852849b1ac52 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 54226283cd89 ! .hgtags From gnu.andrew at redhat.com Fri Mar 20 14:39:46 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 20 Mar 2020 14:39:46 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 4 new changesets Message-ID: <202003201439.02KEdkTf029370@aojmv0008.oracle.com> Changeset: 0666ec7fe2b4 Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/0666ec7fe2b4 Added tag jdk8u252-b06 for changeset b988f627520c ! .hgtags Changeset: ac6ae7fe2e41 Author: andrew Date: 2020-03-16 02:20 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/ac6ae7fe2e41 Merge jdk8u252-b06 ! .hgtags Changeset: f071e9766167 Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/f071e9766167 Added tag aarch64-shenandoah-jdk8u252-b06 for changeset ac6ae7fe2e41 ! .hgtags Changeset: 0607dc89dbb5 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/0607dc89dbb5 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 3d4116b4ed37 ! .hgtags From Pengfei.Li at arm.com Mon Mar 23 00:29:02 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Mon, 23 Mar 2020 00:29:02 +0000 Subject: [aarch64-port-dev ] RFR(S): 8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction" In-Reply-To: References: <31e5ace2-2dbf-e08d-90a8-2a51f0fe8925@redhat.com> Message-ID: Hi Ningsheng, Could you help push this trivial patch if no other review comments? It's reviewed by aph now. > > Jtreg tier1 passed. Is this ok? > > > > [1] http://cr.openjdk.java.net/~pli/rfr/8241091/webrev.02/ > > Yes, thanks. -- Thanks, Pengfei From ningsheng.jian at arm.com Mon Mar 23 00:41:50 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 23 Mar 2020 08:41:50 +0800 Subject: [aarch64-port-dev ] RFR(S): 8241091: AArch64: "bad AD file" with VM option "-XX:-UsePopCountInstruction" In-Reply-To: References: <31e5ace2-2dbf-e08d-90a8-2a51f0fe8925@redhat.com> Message-ID: Pushed. Thanks, Ningsheng On 3/23/20 8:29 AM, Pengfei Li wrote: > Hi Ningsheng, > > Could you help push this trivial patch if no other review comments? It's reviewed by aph now. > >>> Jtreg tier1 passed. Is this ok? >>> >>> [1] http://cr.openjdk.java.net/~pli/rfr/8241091/webrev.02/ >> >> Yes, thanks. > > -- > Thanks, > Pengfei > From ci_notify at linaro.org Mon Mar 23 10:34:14 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 23 Mar 2020 10:34:14 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 3171 Failure Message-ID: <114774497.11016.1584959659704.JavaMail.javamailuser@localhost> OpenJDK AArch64 jdk/jdk build status is Failure Build details - https://ci.linaro.org/job/jdkX-ci-build/3171/ Changes - shade: d2d076a7dfc4ace596c8e67cf784c3ee87c7bdda - src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp - src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp - src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.hpp --"8241068: Shenandoah: improve ShenandoahTraversalGC constructor arguments Reviewed-by: shade Contributed-by: Kelvin Nilsen " ihse: f81815820cd59418dea8bff79effcdacf69ddf21 - make/autoconf/compare.sh.in - make/autoconf/hotspot.m4 - make/autoconf/spec.gmk.in - make/conf/jib-profiles.js - make/hotspot/lib/CompileJvm.gmk - make/scripts/compare_exceptions.sh.incl - src/hotspot/share/runtime/abstract_vm_version.cpp --"8241271: Make hotspot build reproducible Reviewed-by: erikj, stefank, jwilhelm " ihse: 3ecfa2b80db270c1abc1ee68309fde58f725ea12 - make/CompileToolsJdk.gmk - make/jdk/src/classes/build/tools/cldrconverter/Bundle.java - make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java - make/jdk/src/classes/build/tools/cldrconverter/PluralsParseHandler.java - make/jdk/src/classes/build/tools/dtdbuilder/DTDBuilder.java - make/jdk/src/classes/build/tools/dtdbuilder/DTDInputStream.java - make/jdk/src/classes/build/tools/generatebreakiteratordata/GenerateBreakIteratorData.java - make/jdk/src/classes/build/tools/generatebreakiteratordata/RuleBasedBreakIteratorBuilder.java - make/jdk/src/classes/build/tools/generatecharacter/CharacterName.java - make/jdk/src/classes/build/tools/generatecharacter/CharacterScript.java - make/jdk/src/classes/build/tools/generatecharacter/PrintCharacterRanges.java - make/jdk/src/classes/build/tools/generatecurrencydata/GenerateCurrencyData.java - make/jdk/src/classes/build/tools/jdwpgen/Parse.java - make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java - make/jdk/src/classes/build/tools/x11wrappergen/WrapperGenerator.java --"8241310: Fix warnings in jdk buildtools Reviewed-by: erikj, forax " Build output - Creating java.management.jmod Creating java.desktop.jmod Creating interim java.base.jmod Creating java.management.rmi.jmod Creating java.naming.jmod Creating java.net.http.jmod Creating java.prefs.jmod Creating java.rmi.jmod Creating java.scripting.jmod Creating java.se.jmod Creating java.security.jgss.jmod Creating java.security.sasl.jmod Creating java.smartcardio.jmod Creating java.sql.jmod Creating java.sql.rowset.jmod Creating java.transaction.xa.jmod Creating java.xml.crypto.jmod Creating java.xml.jmod Creating jdk.accessibility.jmod Creating jdk.aot.jmod Creating jdk.attach.jmod Creating jdk.charsets.jmod Creating jdk.compiler.jmod Creating jdk.crypto.cryptoki.jmod Creating jdk.crypto.ec.jmod Creating jdk.dynalink.jmod Creating jdk.editpad.jmod Creating jdk.hotspot.agent.jmod Creating jdk.httpserver.jmod Creating jdk.incubator.foreign.jmod Creating jdk.incubator.jpackage.jmod Creating jdk.internal.ed.jmod Creating jdk.internal.jvmstat.jmod Creating jdk.internal.le.jmod Creating jdk.internal.opt.jmod Creating jdk.internal.vm.ci.jmod Creating jdk.internal.vm.compiler.jmod Creating jdk.internal.vm.compiler.management.jmod Creating jdk.jartool.jmod Creating jdk.javadoc.jmod Creating jdk.jcmd.jmod Creating jdk.jconsole.jmod Creating jdk.jdeps.jmod Creating jdk.jdi.jmod Creating jdk.jdwp.agent.jmod Creating jdk.jfr.jmod Creating jdk.jshell.jmod Creating jdk.jsobject.jmod Creating jdk.jstatd.jmod Creating jdk.localedata.jmod Creating jdk.management.jmod Creating jdk.management.agent.jmod Creating jdk.management.jfr.jmod Creating jdk.naming.dns.jmod Creating jdk.naming.rmi.jmod Creating jdk.net.jmod Creating jdk.nio.mapmode.jmod Creating jdk.rmic.jmod Creating jdk.scripting.nashorn.jmod Creating jdk.scripting.nashorn.shell.jmod Creating jdk.sctp.jmod Creating jdk.security.auth.jmod Creating jdk.security.jgss.jmod Creating jdk.unsupported.jmod Creating jdk.unsupported.desktop.jmod Creating jdk.xml.dom.jmod Creating jdk.zipfs.jmod Compiling 3 files for BUILD_DEMO_CodePointIM Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Creating interim jimage make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/support/demos/classes/jfc/CodePointIM/_the.BUILD_DEMO_CodePointIM_batch] Error 1 make[3]: *** Waiting for unfinished jobs.... CompileDemos.gmk:164: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/support/demos/classes/jfc/CodePointIM/_the.BUILD_DEMO_CodePointIM_batch' failed make/Main.gmk:310: recipe for target 'demos-jdk' failed make[2]: *** [demos-jdk] Error 1 make[2]: *** Waiting for unfinished jobs.... ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) Stopping sjavac server === Output from failing command(s) repeated here === * For target support_demos_classes_jfc_CodePointIM__the.BUILD_DEMO_CodePointIM_batch: * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs. === End of repeated output === === Make failed targets repeated here === CompileDemos.gmk:164: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/support/demos/classes/jfc/CodePointIM/_the.BUILD_DEMO_CodePointIM_batch' failed make/Main.gmk:310: recipe for target 'demos-jdk' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. Hint: See doc/building.html#troubleshooting for assistance. /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:307: recipe for target 'main' failed make[1]: *** [main] Error 1 /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed make: *** [images] Error 2 From ci_notify at linaro.org Mon Mar 23 15:33:14 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 23 Mar 2020 15:33:14 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 3172 Fixed In-Reply-To: <114774497.11016.1584959659704.JavaMail.javamailuser@localhost> References: <114774497.11016.1584959659704.JavaMail.javamailuser@localhost> Message-ID: <566514092.11072.1584977594879.JavaMail.javamailuser@localhost> OpenJDK AArch64 jdk/jdk build status is Fixed Build details - https://ci.linaro.org/job/jdkX-ci-build/3172/ Changes - dfuchs: 973301ba95bb02bd42438cd11e9c48bcb9eac28b - test/jdk/ProblemList.txt --"8241443: Problem list some java.net tests failing with NoRouteToHostException on macOS with special network configuration Reviewed-by: alanb " Build output - Creating java.security.jgss.jmod Creating java.security.sasl.jmod Creating java.smartcardio.jmod Creating java.sql.jmod Creating java.sql.rowset.jmod Creating java.transaction.xa.jmod Creating java.xml.jmod Creating java.xml.crypto.jmod Creating jdk.accessibility.jmod Creating jdk.aot.jmod Creating jdk.attach.jmod Creating jdk.charsets.jmod Creating jdk.compiler.jmod Creating jdk.crypto.cryptoki.jmod Creating jdk.crypto.ec.jmod Creating jdk.dynalink.jmod Creating jdk.editpad.jmod Creating jdk.hotspot.agent.jmod Creating jdk.httpserver.jmod Creating jdk.incubator.foreign.jmod Creating jdk.incubator.jpackage.jmod Creating jdk.internal.ed.jmod Creating jdk.internal.jvmstat.jmod Creating jdk.internal.le.jmod Creating jdk.internal.opt.jmod Creating jdk.internal.vm.ci.jmod Creating jdk.internal.vm.compiler.jmod Creating jdk.internal.vm.compiler.management.jmod Creating jdk.jartool.jmod Creating jdk.javadoc.jmod Creating jdk.jcmd.jmod Creating jdk.jconsole.jmod Creating jdk.jdeps.jmod Creating jdk.jdi.jmod Creating jdk.jdwp.agent.jmod Creating jdk.jfr.jmod Creating jdk.jshell.jmod Creating jdk.jsobject.jmod Creating jdk.jstatd.jmod Creating jdk.localedata.jmod Creating jdk.management.jmod Creating jdk.management.agent.jmod Creating jdk.management.jfr.jmod Creating jdk.naming.dns.jmod Creating jdk.naming.rmi.jmod Creating jdk.net.jmod Creating jdk.nio.mapmode.jmod Creating jdk.rmic.jmod Creating jdk.scripting.nashorn.jmod Creating jdk.scripting.nashorn.shell.jmod Creating jdk.sctp.jmod Creating jdk.security.auth.jmod Creating jdk.security.jgss.jmod Creating jdk.unsupported.jmod Creating jdk.unsupported.desktop.jmod Creating jdk.xml.dom.jmod Creating jdk.zipfs.jmod Creating interim jimage Compiling 3 files for BUILD_DEMO_CodePointIM Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Compiling 29 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 3 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Compiling 8 files for BUILD_DEMO_TableExample Updating support/demos/image/jfc/TableExample/src.zip Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Compiling 1 files for CLASSLIST_JAR Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar Creating support/classlist.jar Creating support/demos/image/jfc/Metalworks/Metalworks.jar Creating support/demos/image/jfc/Stylepad/Stylepad.jar Creating support/demos/image/jfc/Notepad/Notepad.jar Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar Creating jdk.jlink.jmod Creating java.base.jmod Creating jdk image WARNING: Using incubator modules: jdk.incubator.foreign, jdk.incubator.jpackage Creating CDS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From vladimir.x.ivanov at oracle.com Tue Mar 24 18:09:40 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 24 Mar 2020 21:09:40 +0300 Subject: [aarch64-port-dev ] [15] RFR (L): 8241436: C2: Factor out C2-specific code from MacroAssembler In-Reply-To: <2ba0e05e-69d1-75d3-b36b-5bb93dffcda9@oracle.com> References: <2ba0e05e-69d1-75d3-b36b-5bb93dffcda9@oracle.com> Message-ID: Hi, I'd like somebody from aarch64 port maintainers to take a look at the patch as well. Thanks in advance! Best regards, Vladimir Ivanov On 23.03.2020 16:49, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8241436/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8241436 > > (The patch is built on top of 8240248 [1].) > > MacroAssembler has C2-only declarations and the number is growing over > time. > > C1 and template interpreter already subclass MacroAssembler for their > own needs (C1_MacroAssembler and InterpreterMacroAssembler respectively). > > I propose to introduce C2_MacroAssembler, move C2-specific code there, > and use it exclusively across C2 code base. > > I took the liberty and refactored aarch64, arm32, ppc64, s390x code > along the way. I did a cross-build, but I ask maintaners to verify that > it doesn't break anything. > > Testing: tier1-4, build (product+debug): > linux-aarch64,linux-arm32,linux-ppc64le,linux-s390x,linux-x64,solaris-sparcv9 > > > Thanks! > > Best regards, > Vladimir Ivanov > > [1] 8240248: Extend superword reduction optimizations for x86 > ??? http://cr.openjdk.java.net/~sviswanathan/8240248/webrev.02/ From Pengfei.Li at arm.com Wed Mar 25 01:12:04 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Wed, 25 Mar 2020 01:12:04 +0000 Subject: [aarch64-port-dev ] RFR[tiny]: 8241482: AArch64: Fix a potential issue after JDK-8239549 Message-ID: Hi, Could you help review this small fix of a potential issue in my previous patch [1] for JDK-8239549? JBS: https://bugs.openjdk.java.net/browse/JDK-8241482 Webrev: http://cr.openjdk.java.net/~pli/rfr/8241482/webrev.00/ This adds one more effect of "TEMP_DEF dst" in the AArch64 matching rule for MulAddVS2VI node to avoid the conflict between register dst and tmp. The existing effect "TEMP tmp" just guarantees register tmp is different from any of the input registers, but cannot guarantee tmp is different from the dst register. As dst is also used as another temp register in the code, the result would be wrong if tmp and dst happen to be the same one. We should take extra care of register conflict when using NEON temps in the future. [TESTS] Tier1 passed. [1] https://hg.openjdk.java.net/jdk/jdk/rev/ff1f4b5e0c9a -- Thanks, Pengfei From ningsheng.jian at arm.com Wed Mar 25 06:37:17 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 25 Mar 2020 14:37:17 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support Message-ID: Hi, Could you please help to review this patch adding AArch64 SVE support? It also touches c2 compiler shared code. Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 Webrev: http://cr.openjdk.java.net/~njian/8231441/webrev.00 Arm has released new vector ISA extension for AArch64, SVE [1] and SVE2 [2]. This patch adds the initial SVE support in OpenJDK. In this patch we have: 1) SVE feature enablement and detection 2) SVE vector register allocation support with initial predicate register definition 3) SVE c2 backend for current SLP based vectorizer. (We also have a POC patch of a new vectorizer using SVE predicate-driven loop control, but that's still under development.) SVE register definition ======================= Unlike other SIMD architectures, SVE allows hardware implementations to choose a vector register length from 128 and 2048 bits, multiple of 128 bits. So we introduce a new vector type VectorA, i.e. length agnostic (scalable) vector type, and Op_VecA for machine vectora register. In the meantime, to minimize register allocation code changes, we also take advantage of one JIT compiler aspect, that is during the compile time we actually know the real hardware SVE vector register size of current running machine. So, the register allocator actually knows how many register slots an Op_VecA ideal reg requires, and could work fine without much modification. Since the bottom 128 bits are shared with the NEON, we extend current register mask definition of V0-V31 registers. Currently, c2 uses one bit mask for a 32-bit register slot, so to define at most 2048 bits we will need to add 64 slots in AD file. That's a really large number, and will also break current regmask assumption. Considering the SVE vector register is architecturally scalable for different sizes, we just define double of original NEON vector register slots, i.e. 8 slots: Vx, Vx_H, Vx_J ... Vx_O. After adlc, the generated register masks now looks like: const RegMask _VECTORA_REG_mask( 0x0, 0x0, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, ... const RegMask _VECTORD_REG_mask( 0x0, 0x0, 0x3030303, 0x3030303, 0x3030303, 0x3030303, 0x3030303, 0x3030303, ... const RegMask _VECTORX_REG_mask( 0x0, 0x0, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, ... And we use SlotsPerVecA to indicate regmask bit size for a VecA register. Although for physical register allocation, register allocator does not need to know the real VecA register size, while doing spill/unspill, current register allocation needs to know actual stack slot size to store/load VecA registers. SVE is able to do vector size agnostic spilling, but to minimize the code changes, as I mentioned before, we just let RA know the actual vector register size in current running machine, by calling scalable_vector_reg_size(). In the meantime, since some vector operations do not have unpredicated SVE1 instructions, but only predicate version, e.g. vector multiply, vector load/store. We have also defined predicate registers in this patch, and c2 register allocator will allocate a temp predicate register to fulfill the expecting unpredicated operations. And this can also be used for future predicate-driven vectorizer. This is not efficient for now, as we can see many ptrue instructions in the generated code. One possible solution I can see, is to block one predicate register, and preset it to all true. But to preserve/reinitialize a caller save register value cross calls seems risky to work in this patch. I decide to defer it to further optimization work. If anyone has any suggestions on this, I would appreciate. SVE feature detection ===================== Since we may have some compiled code based on the initial detected SVE vector register length and the compiled code is compiled only for that vector register length, we assume that the SVE vector register length will not be changed during the JVM lifetime. However, SVE vector length is per-thread and can be changed by system call [3], so we need to make sure that each jni call will not change the sve vector length. Currently, we verify the SVE vector register length on each JNI return, and if an SVE vector length change is detected, jvm simply reports error and stops running. The VM running vector length can also be set by existing VM option MaxVectorSize with c2 enabled. If MaxVectorSize is specified not the same as system default sve vector length (in /proc/sys/abi/sve_default_vector_length), JVM will set current process sve vector length to the specified vector length. Compiled code ============= We have added all current c2 backend codegen on par with NEON, but only for vector length larger than 128-bit. On a 1024 bit SVE environment, for the following simple loop with int array element type: for (int i = 0; i < LENGTH; i++) { c[i] = a[i] + b[i]; } c2 generated loop: 0x0000ffff811c0820: sbfiz x11, x10, #2, #32 0x0000ffff811c0824: add x13, x18, x11 0x0000ffff811c0828: add x14, x1, x11 0x0000ffff811c082c: add x13, x13, #0x10 0x0000ffff811c0830: add x14, x14, #0x10 0x0000ffff811c0834: add x11, x0, x11 0x0000ffff811c0838: add x11, x11, #0x10 0x0000ffff811c083c: ptrue p1.s // To be optimized 0x0000ffff811c0840: ld1w {z16.s}, p1/z, [x14] 0x0000ffff811c0844: ptrue p0.s 0x0000ffff811c0848: ld1w {z17.s}, p0/z, [x13] 0x0000ffff811c084c: add z16.s, z17.s, z16.s 0x0000ffff811c0850: ptrue p1.s 0x0000ffff811c0854: st1w {z16.s}, p1, [x11] 0x0000ffff811c0858: add w10, w10, #0x20 0x0000ffff811c085c: cmp w10, w12 0x0000ffff811c0860: b.lt 0x0000ffff811c0820 Test ==== Currently, we don't have real hardware to verify SVE features (and performance). But we have run jtreg tests with SVE in some emulators. On QEMU system emulator, which has SVE emulation support, jtreg tier1-3 passed with different vector sizes. We've also verified it with full jtreg tests without SVE on both x86 and AArch64, to make sure that there's no regression. The patch has also been applied to Vector API code base, and verified on emulator. In Vector API, there are more vector related tests and is more possible to generate vector instructions by intrinsification. A simple test can also run in QEMU user emulation, e.g. $ qemu-aarch64 -cpu max,sve-max-vq=2 java -XX:UseSVE=1 SIMD ( To run it in user emulation mode, we will need to bypass SVE feature detection code in this patch. E.g. apply: http://cr.openjdk.java.net/~njian/8231441/user-emulation.patch )l Others ====== Since this patch is a bit large, I've also split it into 3 parts, for easy review: 1) SVE feature detection http://cr.openjdk.java.net/~njian/8231441/webrev.00-feature 2) c2 registion allocation http://cr.openjdk.java.net/~njian/8231441/webrev.00-ra 3) SVE c2 backend http://cr.openjdk.java.net/~njian/8231441/webrev.00-c2 Part of this patch has been contributed by Joshua Zhu and Yang Zhang. Refs ==== [1] https://developer.arm.com/docs/ddi0584/latest [2] https://developer.arm.com/docs/ddi0602/latest [3] https://www.kernel.org/doc/Documentation/arm64/sve.txt Thanks, Ningsheng From aph at redhat.com Wed Mar 25 10:09:47 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Mar 2020 10:09:47 +0000 Subject: [aarch64-port-dev ] [15] RFR (L): 8241436: C2: Factor out C2-specific code from MacroAssembler In-Reply-To: References: <2ba0e05e-69d1-75d3-b36b-5bb93dffcda9@oracle.com> Message-ID: <551dd2c2-d91a-0ed3-f9e8-82d089d7fdd0@redhat.com> > On 23.03.2020 16:49, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8241436/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8241436 >> >> (The patch is built on top of 8240248 [1].) >> >> MacroAssembler has C2-only declarations and the number is growing over >> time. >> >> C1 and template interpreter already subclass MacroAssembler for their >> own needs (C1_MacroAssembler and InterpreterMacroAssembler respectively). >> >> I propose to introduce C2_MacroAssembler, move C2-specific code there, >> and use it exclusively across C2 code base. This is interesting. What are all of the changes in aarch64.ad for? Only three functions have been moved to C2_MacroAssembler. Do you distinguish between MacroAssembler functions that are C2-specific and those that are really general purpose but have hitherto only been used in C2? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Mar 25 10:15:23 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Mar 2020 10:15:23 +0000 Subject: [aarch64-port-dev ] RFR[tiny]: 8241482: AArch64: Fix a potential issue after JDK-8239549 In-Reply-To: References: Message-ID: <818a74fd-2125-3bf4-a56b-10515fa299a1@redhat.com> On 3/25/20 1:12 AM, Pengfei Li wrote: > Could you help review this small fix of a potential issue in my previous > patch [1] for JDK-8239549? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241482 > Webrev: http://cr.openjdk.java.net/~pli/rfr/8241482/webrev.00/ OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.x.ivanov at oracle.com Wed Mar 25 10:18:03 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 25 Mar 2020 13:18:03 +0300 Subject: [aarch64-port-dev ] [15] RFR (L): 8241436: C2: Factor out C2-specific code from MacroAssembler In-Reply-To: <551dd2c2-d91a-0ed3-f9e8-82d089d7fdd0@redhat.com> References: <2ba0e05e-69d1-75d3-b36b-5bb93dffcda9@oracle.com> <551dd2c2-d91a-0ed3-f9e8-82d089d7fdd0@redhat.com> Message-ID: <6b397972-a213-a3b7-4257-47ffb28b31eb@oracle.com> Thanks for taking a look, Andrew! >>> I propose to introduce C2_MacroAssembler, move C2-specific code there, >>> and use it exclusively across C2 code base. > > This is interesting. > > What are all of the changes in aarch64.ad for? Only three functions > have been moved to C2_MacroAssembler. > > Do you distinguish between MacroAssembler functions that are > C2-specific and those that are really general purpose but have > hitherto only been used in C2? I don't. The patch uniformly migrates C2 code to C2_MacroAssembler irrespective of whether C2-specific code is used or not. It's keeps status quo with MacroAssembler vs Assembler separation: MacroAssembler has been used irrespective of whether any MA-specific declarations are needed or not. Best regards, Vladimir Ivanov From aph at redhat.com Wed Mar 25 10:17:31 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 Mar 2020 10:17:31 +0000 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: Message-ID: <0aa4bd7d-56a2-7c5c-5222-75323c5a3f60@redhat.com> On 3/25/20 6:37 AM, Ningsheng Jian wrote: > Could you please help to review this patch adding AArch64 SVE support? > It also touches c2 compiler shared code. Congratulations! This is a pretty big deal. It'll take a while to review, but it's a good start. Hint: some of the explanations in your email might make useful comments. Just sayin'. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ningsheng.jian at arm.com Thu Mar 26 01:36:33 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Thu, 26 Mar 2020 09:36:33 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <0aa4bd7d-56a2-7c5c-5222-75323c5a3f60@redhat.com> References: <0aa4bd7d-56a2-7c5c-5222-75323c5a3f60@redhat.com> Message-ID: <5a14facf-3386-c13b-6e4e-28d495deaa49@arm.com> On 3/25/20 6:17 PM, Andrew Haley wrote: > On 3/25/20 6:37 AM, Ningsheng Jian wrote: >> Could you please help to review this patch adding AArch64 SVE support? >> It also touches c2 compiler shared code. > > Congratulations! This is a pretty big deal. > > It'll take a while to review, but it's a good start. Hint: some of the > explanations in your email might make useful comments. Just sayin'. > Thank you Andrew! Yes, it may take some time to review. We will have some more SVE work in future based on this initial patch. I will see how I can add more comments. Thanks, Ningsheng From stumon01 at arm.com Thu Mar 26 22:42:08 2020 From: stumon01 at arm.com (Stuart Monteith) Date: Thu, 26 Mar 2020 22:42:08 +0000 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading Message-ID: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> Hello, Please review this change to implement nmethod entry barriers on aarch64, and hence concurrent class unloading with ZGC. Shenandoah will need to be separately tested and enabled - there are problems with this on Shenandoah. It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as well as Netbeans. In terms of interesting features: With nmethod entry barriers, immediate oops are removed by: LIR_Assembler::jobject2reg and MacroAssembler::movoop This is to ensure consistency with the entry barrier, as otherwise with an immediate we'd otherwise need an ISB. I've added "-XX:DeoptNMethodBarrierALot". I found this functionality useful in testing as deoptimisation is very infrequent. I've written it as an atomic to avoid it happening too frequently. As it is a new option, I'm not sure whether any more is needed than this review. A new test has been added "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to test GC with that option enabled. BarrierSetAssembler::nmethod_entry_barrier This method emits the barrier code. In internal review it was suggested the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not done this as the BarrierSetNMethod code checks the exact instruction sequence, and I prefer to be explicit. Benchmarking method entry shows an increase of around 6ns with the nmethod entry barrier. The deoptimisation code was contributed by Andrew Haley. The bug: https://bugs.openjdk.java.net/browse/JDK-8216557 The webrev: http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ BR, Stuart IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From gnu.andrew at redhat.com Fri Mar 27 07:10:52 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 27 Mar 2020 07:10:52 +0000 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b07 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b07: - S8197441: Signature#initSign/initVerify for an invalid private/public key fails with ClassCastException for SunPKCS11 provider Main issues of note: No HotSpot changes, so no merge work. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/src/share/classes/sun/security/pkcs11/P11Signature.java | 21 ++++++++------ 2 files changed, 14 insertions(+), 8 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Fri Mar 27 09:36:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 27 Mar 2020 10:36:43 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b07 Upstream Sync In-Reply-To: References: Message-ID: <88a0d526-1e21-73a6-8916-80ecbc12ea5f@redhat.com> On 3/27/20 8:10 AM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/jaxws/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b07/root/merge.changeset Looks trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From erik.osterlund at oracle.com Fri Mar 27 09:47:41 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 27 Mar 2020 10:47:41 +0100 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> Message-ID: <8f317840-a2b2-3ccb-fbb2-a38b2ebcbf4b@oracle.com> Hi Stuart, Thanks for sorting this out on AArch64. It is nice to see thatyou can implement these barriers on platforms that do not have instruction cache coherency. One small change request: It looks like in C1 you inject the entry barrier right after build_frame is done: ?629?????? build_frame(); ?630?????? { ?631???????? // Insert nmethod entry barrier into frame. ?632???????? BarrierSetAssembler* bs = BarrierSet::barrier_set()->barrier_set_assembler(); ?633???????? bs->nmethod_entry_barrier(_masm); ?634?????? } Unfortunately, this is in the platform independent part of the LIR assembler. In the x86 version we inject it at the very end of build_frame() instead, which is a platform-specific function. The platform-specific function is in the C1 macro assembler file for that platform. We intentionally put it in the platform-specific path as it is a platform-specific feature. Now on x86, the barrier code will be emitted once in build_frame() and once after returning from build_frame, resulting in two nmethod entry barriers, and only the first one will get patched, causing the second one to mostly take slow paths, which isn't necessarily wrong, but will cause regressions. I would propose you just move those lines into the very end of the AArch64-specific part of build_frame(). I don't need to see another webrev for that trivial code motion. This looks good to me. Agan, thanks a lot for fixing this! It will allow me to go forward with concurrent stack scanning on AArch64 as well. Thanks, /Erik On 2020-03-26 23:42, Stuart Monteith wrote: > Hello, > Please review this change to implement nmethod entry barriers on > aarch64, and hence concurrent class unloading with ZGC. Shenandoah will > need to be separately tested and enabled - there are problems with this > on Shenandoah. > > It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as > well as Netbeans. > > In terms of interesting features: > With nmethod entry barriers, immediate oops are removed by: > LIR_Assembler::jobject2reg and MacroAssembler::movoop > This is to ensure consistency with the entry barrier, as otherwise with > an immediate we'd otherwise need an ISB. > > I've added "-XX:DeoptNMethodBarrierALot". I found this functionality > useful in testing as deoptimisation is very infrequent. I've written it > as an atomic to avoid it happening too frequently. As it is a new > option, I'm not sure whether any more is needed than this review. A new > test has been added > "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to > test GC with that option enabled. > > BarrierSetAssembler::nmethod_entry_barrier > This method emits the barrier code. In internal review it was suggested > the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not > done this as the BarrierSetNMethod code checks the exact instruction > sequence, and I prefer to be explicit. > > Benchmarking method entry shows an increase of around 6ns with the > nmethod entry barrier. > > > The deoptimisation code was contributed by Andrew Haley. > > The bug: > https://bugs.openjdk.java.net/browse/JDK-8216557 > > The webrev: > http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ > > > BR, > Stuart > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From matthias.baesken at sap.com Fri Mar 27 10:01:43 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 27 Mar 2020 10:01:43 +0000 Subject: [aarch64-port-dev ] RFR [XS]: 8241586: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64 In-Reply-To: References: Message-ID: Thanks for the review ! Best regards, Matthias From: Langer, Christoph Sent: Freitag, 27. M?rz 2020 10:47 To: Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' Cc: aarch64-port-dev at openjdk.java.net Subject: RE: RFR [XS]: 8241586: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64 Hi Matthias, this looks fine to me. The test error that we observe seems to have gone with your fix. Cross-posting to aarch64-port-dev - maybe one of the folks involved in the aarch64 port can acknowledge (or object)? Thanks Christoph From: Baesken, Matthias > Sent: Mittwoch, 25. M?rz 2020 13:33 To: 'hotspot-dev at openjdk.java.net' > Cc: Langer, Christoph > Subject: RFR [XS]: 8241586: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64 Hello, please review this small aarch64 related fix. Currently the hotspot jtreg test compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64. Reason is that in this test, we check the following message (that is printed on other CPU platforms): 51 private static final String AES_NOT_AVAILABLE_MSG = "warning: AES " 52 + "instructions are not available on this CPU"; However the aarch64 message differs and prints instead : warning: UseAES specified, but not supported on this CPU Same with the 'warning: AES intrinsics are not available on this CPU' that is checked by the test as well. (gives currently on aarch64 the warning: UseAESIntrinsics specified, but not supported on this CPU) So I think the aarch64 messages might be adjusted. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8241586 http://cr.openjdk.java.net/~mbaesken/webrevs/8241586.0/ Thanks, Matthias From per.liden at oracle.com Fri Mar 27 11:36:37 2020 From: per.liden at oracle.com (Per Liden) Date: Fri, 27 Mar 2020 12:36:37 +0100 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> Message-ID: <1dc6cf14-267a-2741-2011-3c3a1bb74a38@oracle.com> Hi Stuart, Awesome, thanks a lot for doing this! On 3/26/20 11:42 PM, Stuart Monteith wrote: > Hello, > Please review this change to implement nmethod entry barriers on > aarch64, and hence concurrent class unloading with ZGC. Shenandoah will > need to be separately tested and enabled - there are problems with this > on Shenandoah. > > It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as > well as Netbeans. > > In terms of interesting features: > With nmethod entry barriers, immediate oops are removed by: > LIR_Assembler::jobject2reg and MacroAssembler::movoop > This is to ensure consistency with the entry barrier, as otherwise with > an immediate we'd otherwise need an ISB. > > I've added "-XX:DeoptNMethodBarrierALot". I found this functionality > useful in testing as deoptimisation is very infrequent. I've written it > as an atomic to avoid it happening too frequently. As it is a new > option, I'm not sure whether any more is needed than this review. A new > test has been added > "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to > test GC with that option enabled. > > BarrierSetAssembler::nmethod_entry_barrier > This method emits the barrier code. In internal review it was suggested > the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not > done this as the BarrierSetNMethod code checks the exact instruction > sequence, and I prefer to be explicit. > > Benchmarking method entry shows an increase of around 6ns with the > nmethod entry barrier. > > > The deoptimisation code was contributed by Andrew Haley. > > The bug: > https://bugs.openjdk.java.net/browse/JDK-8216557 > > The webrev: > http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ I'll leave the aarch64-specific part for others to review. I just have two minor comments on the rest. * May I suggest that we rename DeoptNMethodBarrierALot to DeoptimizeNMethodBarriersALot, to better match -XX:DeoptimizeALot and friends? * The "counter" used should probably be an unsigned type, to avoid any overflow UB. That variable could also move into the scope where it's used. Like: ---------------------------------------------------------- diff --git a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp --- a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp +++ b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp @@ -50,7 +50,6 @@ int BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) { address return_address = *return_address_ptr; CodeBlob* cb = CodeCache::find_blob(return_address); - static volatile int counter=0; assert(cb != NULL, "invariant"); @@ -67,8 +66,9 @@ // Diagnostic option to force deoptimization 1 in 3 times. It is otherwise // a very rare event. - if (DeoptNMethodBarrierALot) { - if (Atomic::add(&counter, 1) % 3 == 0) { + if (DeoptimizeNMethodBarriersALot) { + static volatile uint32_t counter = 0; + if (Atomic::add(&counter, 1u) % 3 == 0) { may_enter = false; } } diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp --- a/src/hotspot/share/runtime/globals.hpp +++ b/src/hotspot/share/runtime/globals.hpp @@ -2489,7 +2489,7 @@ product(bool, UseEmptySlotsInSupers, true, \ "Allow allocating fields in empty slots of super-classes") \ \ - diagnostic(bool, DeoptNMethodBarrierALot, false, \ + diagnostic(bool, DeoptimizeNMethodBarriersALot, false, \ "Make nmethod barriers deoptimise a lot.") \ // Interface macros ---------------------------------------------------------- * Instead of adding a new file for the test, we could just add a new section in the existing test. * The test also needs to supply -XX:+UnlockDiagnosticVMOptions. Like: ---------------------------------------------------------- diff --git a/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java b/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java --- a/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java +++ b/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -35,6 +35,18 @@ * @summary Stress ZGC * @run main/othervm/timeout=200 -Xlog:gc*=info -Xmx384m -server -XX:+UnlockExperimentalVMOptions -XX:+UseZGC gc.stress.gcbasher.TestGCBasherWithZ 120000 */ + +/* + * @test TestGCBasherDeoptWithZ + * @key gc stress + * @library / + * @requires vm.gc.Z + * @requires vm.flavor == "server" & !vm.emulatedClient & !vm.graal.enabled & vm.opt.ClassUnloading != false + * @summary Stress ZGC with nmethod barrier forced deoptimization enabled + * @run main/othervm/timeout=200 -Xlog:gc*,nmethod+barrier=trace -Xmx384m -XX:+UnlockExperimentalVMOptions -XX:+UseZGC + * -XX:+DeoptimizeNMethodBarriersALot -XX:-Inline gc.stress.gcbasher.TestGCBasherWithZ 120000 + */ + public class TestGCBasherWithZ { public static void main(String[] args) throws IOException { TestGCBasher.main(args); ---------------------------------------------------------- cheers, Per > > > BR, > Stuart > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > From per.liden at oracle.com Fri Mar 27 11:59:42 2020 From: per.liden at oracle.com (Per Liden) Date: Fri, 27 Mar 2020 12:59:42 +0100 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <1dc6cf14-267a-2741-2011-3c3a1bb74a38@oracle.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> <1dc6cf14-267a-2741-2011-3c3a1bb74a38@oracle.com> Message-ID: Hi again, On 3/27/20 12:36 PM, Per Liden wrote: > Hi Stuart, > > Awesome, thanks a lot for doing this! > > On 3/26/20 11:42 PM, Stuart Monteith wrote: >> Hello, >> ???????? Please review this change to implement nmethod entry barriers on >> aarch64, and hence concurrent class unloading with ZGC. Shenandoah will >> need to be separately tested and enabled - there are problems with this >> on Shenandoah. >> >> It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as >> well as Netbeans. >> >> In terms of interesting features: >> ????????? With nmethod entry barriers,? immediate oops are removed by: >> ???????????????? LIR_Assembler::jobject2reg? and? MacroAssembler::movoop >> ???????? This is to ensure consistency with the entry barrier, as >> otherwise with >> an immediate we'd otherwise need an ISB. >> >> ???????? I've added "-XX:DeoptNMethodBarrierALot". I found this >> functionality >> useful in testing as deoptimisation is very infrequent. I've written it >> as an atomic to avoid it happening too frequently. As it is a new >> option, I'm not sure whether any more is needed than this review. A new >> test has been added >> "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to >> test GC with that option enabled. >> >> ???????? BarrierSetAssembler::nmethod_entry_barrier >> ???????? This method emits the barrier code. In internal review it was >> suggested >> the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not >> done this as the BarrierSetNMethod code checks the exact instruction >> sequence, and I prefer to be explicit. >> >> ???????? Benchmarking method entry shows an increase of around 6ns >> with the >> nmethod entry barrier. >> >> >> The deoptimisation code was contributed by Andrew Haley. >> >> The bug: >> ???????? https://bugs.openjdk.java.net/browse/JDK-8216557 >> >> The webrev: >> ???????? http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ > > I'll leave the aarch64-specific part for others to review. I just have > two minor comments on the rest. > > * May I suggest that we rename DeoptNMethodBarrierALot to > DeoptimizeNMethodBarriersALot, to better match -XX:DeoptimizeALot and > friends? > > * The "counter" used should probably be an unsigned type, to avoid any > overflow UB. That variable could also move into the scope where it's used. > > Like: > > ---------------------------------------------------------- > diff --git a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > --- a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > +++ b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > @@ -50,7 +50,6 @@ > ?int BarrierSetNMethod::nmethod_stub_entry_barrier(address* > return_address_ptr) { > ?? address return_address = *return_address_ptr; > ?? CodeBlob* cb = CodeCache::find_blob(return_address); > -? static volatile int counter=0; > > ?? assert(cb != NULL, "invariant"); > > @@ -67,8 +66,9 @@ > > ?? // Diagnostic option to force deoptimization 1 in 3 times. It is > otherwise > ?? // a very rare event. > -? if (DeoptNMethodBarrierALot) { > -??? if (Atomic::add(&counter, 1) % 3 == 0) { > +? if (DeoptimizeNMethodBarriersALot) { > +??? static volatile uint32_t counter = 0; > +??? if (Atomic::add(&counter, 1u) % 3 == 0) { > ?????? may_enter = false; > ???? } > ?? } > diff --git a/src/hotspot/share/runtime/globals.hpp > b/src/hotspot/share/runtime/globals.hpp > --- a/src/hotspot/share/runtime/globals.hpp > +++ b/src/hotspot/share/runtime/globals.hpp > @@ -2489,7 +2489,7 @@ > ?? product(bool, UseEmptySlotsInSupers, true, ???? \ > ???????????????? "Allow allocating fields in empty slots of > super-classes")? \ > > ???? \ > -? diagnostic(bool, DeoptNMethodBarrierALot, false, ??? \ > +? diagnostic(bool, DeoptimizeNMethodBarriersALot, false, ??? \ > ???????????????? "Make nmethod barriers deoptimise a lot.") ???? \ > > ?// Interface macros > ---------------------------------------------------------- > > > * Instead of adding a new file for the test, we could just add a new > section in the existing test. > > * The test also needs to supply -XX:+UnlockDiagnosticVMOptions. Meh, forgot -XX:+UnlockDiagnosticVMOptions in my patch. Updated: ---------------------------------------------------------- diff --git a/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java b/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java --- a/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java +++ b/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -35,6 +35,18 @@ * @summary Stress ZGC * @run main/othervm/timeout=200 -Xlog:gc*=info -Xmx384m -server -XX:+UnlockExperimentalVMOptions -XX:+UseZGC gc.stress.gcbasher.TestGCBasherWithZ 120000 */ + +/* + * @test TestGCBasherDeoptWithZ + * @key gc stress + * @library / + * @requires vm.gc.Z + * @requires vm.flavor == "server" & !vm.emulatedClient & !vm.graal.enabled & vm.opt.ClassUnloading != false + * @summary Stress ZGC with nmethod barrier forced deoptimization enabled + * @run main/othervm/timeout=200 -Xlog:gc*,nmethod+barrier=trace -Xmx384m -XX:+UnlockExperimentalVMOptions -XX:+UseZGC + * -XX:+UnlockDiagnosticVMOptions -XX:+DeoptimizeNMethodBarriersALot -XX:-Inline gc.stress.gcbasher.TestGCBasherWithZ 120000 + */ + public class TestGCBasherWithZ { public static void main(String[] args) throws IOException { TestGCBasher.main(args); ---------------------------------------------------------- cheers, Per > > Like: > > ---------------------------------------------------------- > diff --git > a/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java > b/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java > --- a/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java > +++ b/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -35,6 +35,18 @@ > ? * @summary Stress ZGC > ? * @run main/othervm/timeout=200 -Xlog:gc*=info -Xmx384m -server > -XX:+UnlockExperimentalVMOptions -XX:+UseZGC > gc.stress.gcbasher.TestGCBasherWithZ 120000 > ? */ > + > +/* > + * @test TestGCBasherDeoptWithZ > + * @key gc stress > + * @library / > + * @requires vm.gc.Z > + * @requires vm.flavor == "server" & !vm.emulatedClient & > !vm.graal.enabled & vm.opt.ClassUnloading != false > + * @summary Stress ZGC with nmethod barrier forced deoptimization enabled > + * @run main/othervm/timeout=200 -Xlog:gc*,nmethod+barrier=trace > -Xmx384m -XX:+UnlockExperimentalVMOptions -XX:+UseZGC > + *?????????????????????????????? -XX:+DeoptimizeNMethodBarriersALot > -XX:-Inline gc.stress.gcbasher.TestGCBasherWithZ 120000 > + */ > + > ?public class TestGCBasherWithZ { > ???? public static void main(String[] args) throws IOException { > ???????? TestGCBasher.main(args); > ---------------------------------------------------------- > > cheers, > Per > > >> >> >> BR, >> ???????? Stuart >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose >> the contents to any other person, use it for any purpose, or store or >> copy the information in any medium. Thank you. >> From christoph.langer at sap.com Fri Mar 27 09:47:20 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 27 Mar 2020 09:47:20 +0000 Subject: [aarch64-port-dev ] RFR [XS]: 8241586: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64 In-Reply-To: References: Message-ID: Hi Matthias, this looks fine to me. The test error that we observe seems to have gone with your fix. Cross-posting to aarch64-port-dev - maybe one of the folks involved in the aarch64 port can acknowledge (or object)? Thanks Christoph From: Baesken, Matthias Sent: Mittwoch, 25. M?rz 2020 13:33 To: 'hotspot-dev at openjdk.java.net' Cc: Langer, Christoph Subject: RFR [XS]: 8241586: compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64 Hello, please review this small aarch64 related fix. Currently the hotspot jtreg test compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java fails on aarch64. Reason is that in this test, we check the following message (that is printed on other CPU platforms): 51 private static final String AES_NOT_AVAILABLE_MSG = "warning: AES " 52 + "instructions are not available on this CPU"; However the aarch64 message differs and prints instead : warning: UseAES specified, but not supported on this CPU Same with the 'warning: AES intrinsics are not available on this CPU' that is checked by the test as well. (gives currently on aarch64 the warning: UseAESIntrinsics specified, but not supported on this CPU) So I think the aarch64 messages might be adjusted. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8241586 http://cr.openjdk.java.net/~mbaesken/webrevs/8241586.0/ Thanks, Matthias From aph at redhat.com Fri Mar 27 12:36:41 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Mar 2020 12:36:41 +0000 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> Message-ID: <105c4a4a-59c9-8095-6d45-642595f65539@redhat.com> On 3/26/20 10:42 PM, Stuart Monteith wrote: > > BarrierSetAssembler::nmethod_entry_barrier > This method emits the barrier code. In internal review it was suggested > the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not > done this as the BarrierSetNMethod code checks the exact instruction > sequence, and I prefer to be explicit. I understand, but LoadLoad is the semantics you need, and it's more important to say that. The mere existence of verification code shouldn't determine how you express the runtime code. I'll do a thorough review later. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Fri Mar 27 14:01:15 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 27 Mar 2020 10:01:15 -0400 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> Message-ID: <8e4978ac-e563-56df-72b9-81f37f8adc39@redhat.com> Hi Stuart, Great work! On 3/26/20 6:42 PM, Stuart Monteith wrote: > Hello, > Please review this change to implement nmethod entry barriers on > aarch64, and hence concurrent class unloading with ZGC. Shenandoah will > need to be separately tested and enabled - there are problems with this > on Shenandoah. I identified a problem that failed TestStringDedupStress.java, I have fix for it. Would you mind to share what else failed with Shenandoah? Thanks, -Zhengyu > > It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as > well as Netbeans. > > In terms of interesting features: > With nmethod entry barriers, immediate oops are removed by: > LIR_Assembler::jobject2reg and MacroAssembler::movoop > This is to ensure consistency with the entry barrier, as otherwise with > an immediate we'd otherwise need an ISB. > > I've added "-XX:DeoptNMethodBarrierALot". I found this functionality > useful in testing as deoptimisation is very infrequent. I've written it > as an atomic to avoid it happening too frequently. As it is a new > option, I'm not sure whether any more is needed than this review. A new > test has been added > "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to > test GC with that option enabled. > > BarrierSetAssembler::nmethod_entry_barrier > This method emits the barrier code. In internal review it was suggested > the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not > done this as the BarrierSetNMethod code checks the exact instruction > sequence, and I prefer to be explicit. > > Benchmarking method entry shows an increase of around 6ns with the > nmethod entry barrier. > > > The deoptimisation code was contributed by Andrew Haley. > > The bug: > https://bugs.openjdk.java.net/browse/JDK-8216557 > > The webrev: > http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ > > > BR, > Stuart > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > From stumon01 at arm.com Fri Mar 27 15:28:23 2020 From: stumon01 at arm.com (Stuart Monteith) Date: Fri, 27 Mar 2020 15:28:23 +0000 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <8e4978ac-e563-56df-72b9-81f37f8adc39@redhat.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> <8e4978ac-e563-56df-72b9-81f37f8adc39@redhat.com> Message-ID: Hello Zhengyu, That is the same test I had trouble with. One of the stack traces I had is: V [libjvm.so+0x4dd538] CompressedKlassPointers::decode_not_null(unsigned int)+0x70 V [libjvm.so+0xb87130] InterpreterRuntime::throw_ClassCastException(JavaThread*, oopDesc*)+0x148 j java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;I)Ljava/lang/Object;+1 java.base at 15-internal J 426 c2 java.lang.invoke.Invokers$Holder.linkToTargetMethod(ILjava/lang/Object;)Ljava/lang/Object; java.base at 15-internal (9 bytes) @ 0x0000ffff978ecc24 [0x0000ffff978ecbc0+0x0000000000000064] j TestStringDedupStress.main([Ljava/lang/String;)V+162 v ~StubRoutines::call_stub V [libjvm.so+0xb95328] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6f8 V [libjvm.so+0x12531d4] invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) [clone .isra.138]+0xd74 V [libjvm.so+0x125380c] Reflection::invoke_method(oop, Handle, objArrayHandle, Thread*)+0x1a4 V [libjvm.so+0xd05280] JVM_InvokeMethod+0x210 j jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base at 15-internal j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 java.base at 15-internal j jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 java.base at 15-internal j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 15-internal j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 j java.lang.Thread.run()V+11 java.base at 15-internal v ~StubRoutines::call_stub V [libjvm.so+0xb95328] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6f8 V [libjvm.so+0xb95784] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x2ac V [libjvm.so+0xb95974] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0xac V [libjvm.so+0xcefce8] thread_entry(JavaThread*, Thread*)+0x98 V [libjvm.so+0x1507cc8] JavaThread::thread_main_inner()+0x258 V [libjvm.so+0x150fdac] JavaThread::run()+0x27c V [libjvm.so+0x150d4a4] Thread::call_run()+0x10c V [libjvm.so+0x115ff70] thread_native_entry(Thread*)+0x120 C [libpthread.so.0+0x8880] start_thread+0x1a0 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;I)Ljava/lang/Object;+1 java.base at 15-internal J 426 c2 java.lang.invoke.Invokers$Holder.linkToTargetMethod(ILjava/lang/Object;)Ljava/lang/Object; java.base at 15-internal (9 bytes) @ 0x0000ffff978ecc24 [0x0000ffff978ecbc0+0x0000000000000064] j TestStringDedupStress.main([Ljava/lang/String;)V+162 v ~StubRoutines::call_stub j jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base at 15-internal j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 java.base at 15-internal j jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 java.base at 15-internal j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 15-internal j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 j java.lang.Thread.run()V+11 java.base at 15-internal v ~StubRoutines::call_stub There are variations on that theme, but that was one of the more common ones. Thanks, Stuart On 27/03/2020 14:01, Zhengyu Gu wrote: > Hi Stuart, > > Great work! > > On 3/26/20 6:42 PM, Stuart Monteith wrote: >> Hello, >> Please review this change to implement nmethod entry barriers on >> aarch64, and hence concurrent class unloading with ZGC. Shenandoah will >> need to be separately tested and enabled - there are problems with this >> on Shenandoah. > > I identified a problem that failed TestStringDedupStress.java, I have fix for it. > > Would you mind to share what else failed with Shenandoah? > > Thanks, > > -Zhengyu > > >> >> It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as >> well as Netbeans. >> >> In terms of interesting features: >> With nmethod entry barriers, immediate oops are removed by: >> LIR_Assembler::jobject2reg and MacroAssembler::movoop >> This is to ensure consistency with the entry barrier, as otherwise with >> an immediate we'd otherwise need an ISB. >> >> I've added "-XX:DeoptNMethodBarrierALot". I found this functionality >> useful in testing as deoptimisation is very infrequent. I've written it >> as an atomic to avoid it happening too frequently. As it is a new >> option, I'm not sure whether any more is needed than this review. A new >> test has been added >> "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to >> test GC with that option enabled. >> >> BarrierSetAssembler::nmethod_entry_barrier >> This method emits the barrier code. In internal review it was suggested >> the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not >> done this as the BarrierSetNMethod code checks the exact instruction >> sequence, and I prefer to be explicit. >> >> Benchmarking method entry shows an increase of around 6ns with the >> nmethod entry barrier. >> >> >> The deoptimisation code was contributed by Andrew Haley. >> >> The bug: >> https://bugs.openjdk.java.net/browse/JDK-8216557 >> >> The webrev: >> http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ >> >> >> BR, >> Stuart >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you >> are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other >> person, use it for any purpose, or store or copy the information in any medium. Thank you. >> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From zgu at redhat.com Fri Mar 27 15:30:31 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 27 Mar 2020 11:30:31 -0400 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> <8e4978ac-e563-56df-72b9-81f37f8adc39@redhat.com> Message-ID: <55a800b2-1564-1162-7177-485e674dc618@redhat.com> Hi Stuart, Yes, this is the same problem I saw. I filed JDK-8241765, will RFR once it passes all tests. Thanks, -Zhengyu On 3/27/20 11:28 AM, Stuart Monteith wrote: > Hello Zhengyu, > That is the same test I had trouble with. > > One of the stack traces I had is: > > V [libjvm.so+0x4dd538] CompressedKlassPointers::decode_not_null(unsigned int)+0x70 > V [libjvm.so+0xb87130] InterpreterRuntime::throw_ClassCastException(JavaThread*, oopDesc*)+0x148 > j java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;I)Ljava/lang/Object;+1 java.base at 15-internal > J 426 c2 java.lang.invoke.Invokers$Holder.linkToTargetMethod(ILjava/lang/Object;)Ljava/lang/Object; > java.base at 15-internal (9 bytes) @ 0x0000ffff978ecc24 [0x0000ffff978ecbc0+0x0000000000000064] > j TestStringDedupStress.main([Ljava/lang/String;)V+162 > v ~StubRoutines::call_stub > V [libjvm.so+0xb95328] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6f8 > V [libjvm.so+0x12531d4] invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, > objArrayHandle, bool, Thread*) [clone .isra.138]+0xd74 > V [libjvm.so+0x125380c] Reflection::invoke_method(oop, Handle, objArrayHandle, Thread*)+0x1a4 > V [libjvm.so+0xd05280] JVM_InvokeMethod+0x210 > j > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 > java.base at 15-internal > j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 > java.base at 15-internal > j jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 > java.base at 15-internal > j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 15-internal > j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 > j java.lang.Thread.run()V+11 java.base at 15-internal > v ~StubRoutines::call_stub > V [libjvm.so+0xb95328] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6f8 > V [libjvm.so+0xb95784] JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x2ac > V [libjvm.so+0xb95974] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0xac > V [libjvm.so+0xcefce8] thread_entry(JavaThread*, Thread*)+0x98 > V [libjvm.so+0x1507cc8] JavaThread::thread_main_inner()+0x258 > V [libjvm.so+0x150fdac] JavaThread::run()+0x27c > V [libjvm.so+0x150d4a4] Thread::call_run()+0x10c > V [libjvm.so+0x115ff70] thread_native_entry(Thread*)+0x120 > C [libpthread.so.0+0x8880] start_thread+0x1a0 > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;I)Ljava/lang/Object;+1 java.base at 15-internal > J 426 c2 java.lang.invoke.Invokers$Holder.linkToTargetMethod(ILjava/lang/Object;)Ljava/lang/Object; > java.base at 15-internal (9 bytes) @ 0x0000ffff978ecc24 [0x0000ffff978ecbc0+0x0000000000000064] > j TestStringDedupStress.main([Ljava/lang/String;)V+162 > v ~StubRoutines::call_stub > j > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 > java.base at 15-internal > j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 > java.base at 15-internal > j jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 > java.base at 15-internal > j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 15-internal > j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 > j java.lang.Thread.run()V+11 java.base at 15-internal > v ~StubRoutines::call_stub > > There are variations on that theme, but that was one of the more common ones. > > Thanks, > Stuart > > On 27/03/2020 14:01, Zhengyu Gu wrote: >> Hi Stuart, >> >> Great work! >> >> On 3/26/20 6:42 PM, Stuart Monteith wrote: >>> Hello, >>> Please review this change to implement nmethod entry barriers on >>> aarch64, and hence concurrent class unloading with ZGC. Shenandoah will >>> need to be separately tested and enabled - there are problems with this >>> on Shenandoah. >> >> I identified a problem that failed TestStringDedupStress.java, I have fix for it. >> >> Would you mind to share what else failed with Shenandoah? >> >> Thanks, >> >> -Zhengyu >> >> >>> >>> It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as >>> well as Netbeans. >>> >>> In terms of interesting features: >>> With nmethod entry barriers, immediate oops are removed by: >>> LIR_Assembler::jobject2reg and MacroAssembler::movoop >>> This is to ensure consistency with the entry barrier, as otherwise with >>> an immediate we'd otherwise need an ISB. >>> >>> I've added "-XX:DeoptNMethodBarrierALot". I found this functionality >>> useful in testing as deoptimisation is very infrequent. I've written it >>> as an atomic to avoid it happening too frequently. As it is a new >>> option, I'm not sure whether any more is needed than this review. A new >>> test has been added >>> "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to >>> test GC with that option enabled. >>> >>> BarrierSetAssembler::nmethod_entry_barrier >>> This method emits the barrier code. In internal review it was suggested >>> the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not >>> done this as the BarrierSetNMethod code checks the exact instruction >>> sequence, and I prefer to be explicit. >>> >>> Benchmarking method entry shows an increase of around 6ns with the >>> nmethod entry barrier. >>> >>> >>> The deoptimisation code was contributed by Andrew Haley. >>> >>> The bug: >>> https://bugs.openjdk.java.net/browse/JDK-8216557 >>> >>> The webrev: >>> http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ >>> >>> >>> BR, >>> Stuart >>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you >>> are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other >>> person, use it for any purpose, or store or copy the information in any medium. Thank you. >>> >> > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > From stumon01 at arm.com Fri Mar 27 15:32:53 2020 From: stumon01 at arm.com (Stuart Monteith) Date: Fri, 27 Mar 2020 15:32:53 +0000 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <55a800b2-1564-1162-7177-485e674dc618@redhat.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> <8e4978ac-e563-56df-72b9-81f37f8adc39@redhat.com> <55a800b2-1564-1162-7177-485e674dc618@redhat.com> Message-ID: <40210d3e-15f5-02b9-9197-d35549d40cf7@arm.com> Thanks, that's great. It's great we have two GCs able to exercise the new barrier. On 27/03/2020 15:30, Zhengyu Gu wrote: > Hi Stuart, > > Yes, this is the same problem I saw. I filed JDK-8241765, will RFR once it passes all tests. > > Thanks, > > -Zhengyu > > On 3/27/20 11:28 AM, Stuart Monteith wrote: >> Hello Zhengyu, >> That is the same test I had trouble with. >> >> One of the stack traces I had is: >> >> V [libjvm.so+0x4dd538]? CompressedKlassPointers::decode_not_null(unsigned int)+0x70 >> V [libjvm.so+0xb87130]? InterpreterRuntime::throw_ClassCastException(JavaThread*, oopDesc*)+0x148 >> j java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;I)Ljava/lang/Object;+1 java.base at 15-internal >> J 426 c2 java.lang.invoke.Invokers$Holder.linkToTargetMethod(ILjava/lang/Object;)Ljava/lang/Object; >> java.base at 15-internal (9 bytes) @ 0x0000ffff978ecc24 [0x0000ffff978ecbc0+0x0000000000000064] >> j TestStringDedupStress.main([Ljava/lang/String;)V+162 >> v ~StubRoutines::call_stub >> V [libjvm.so+0xb95328]? JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6f8 >> V [libjvm.so+0x12531d4]? invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, >> objArrayHandle, bool, Thread*) [clone .isra.138]+0xd74 >> V [libjvm.so+0x125380c]? Reflection::invoke_method(oop, Handle, objArrayHandle, Thread*)+0x1a4 >> V [libjvm.so+0xd05280]? JVM_InvokeMethod+0x210 >> j >> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >> >> java.base at 15-internal >> j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 >> java.base at 15-internal >> j jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 >> java.base at 15-internal >> j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 15-internal >> j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 >> j java.lang.Thread.run()V+11 java.base at 15-internal >> v ~StubRoutines::call_stub >> V [libjvm.so+0xb95328]? JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x6f8 >> V [libjvm.so+0xb95784]? JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x2ac >> V [libjvm.so+0xb95974]? JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0xac >> V [libjvm.so+0xcefce8]? thread_entry(JavaThread*, Thread*)+0x98 >> V [libjvm.so+0x1507cc8]? JavaThread::thread_main_inner()+0x258 >> V [libjvm.so+0x150fdac]? JavaThread::run()+0x27c >> V [libjvm.so+0x150d4a4]? Thread::call_run()+0x10c >> V [libjvm.so+0x115ff70]? thread_native_entry(Thread*)+0x120 >> C [libpthread.so.0+0x8880]? start_thread+0x1a0 >> >> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) >> j java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;I)Ljava/lang/Object;+1 java.base at 15-internal >> J 426 c2 java.lang.invoke.Invokers$Holder.linkToTargetMethod(ILjava/lang/Object;)Ljava/lang/Object; >> java.base at 15-internal (9 bytes) @ 0x0000ffff978ecc24 [0x0000ffff978ecbc0+0x0000000000000064] >> j TestStringDedupStress.main([Ljava/lang/String;)V+162 >> v ~StubRoutines::call_stub >> j >> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 >> >> java.base at 15-internal >> j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 >> java.base at 15-internal >> j jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+6 >> java.base at 15-internal >> j java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+59 java.base at 15-internal >> j com.sun.javatest.regtest.agent.MainWrapper$MainThread.run()V+172 >> j java.lang.Thread.run()V+11 java.base at 15-internal >> v ~StubRoutines::call_stub >> >> There are variations on that theme, but that was one of the more common ones. >> >> Thanks, >> Stuart >> >> On 27/03/2020 14:01, Zhengyu Gu wrote: >>> Hi Stuart, >>> >>> Great work! >>> >>> On 3/26/20 6:42 PM, Stuart Monteith wrote: >>>> Hello, >>>> Please review this change to implement nmethod entry barriers on >>>> aarch64, and hence concurrent class unloading with ZGC. Shenandoah will >>>> need to be separately tested and enabled - there are problems with this >>>> on Shenandoah. >>> >>> I identified a problem that failed TestStringDedupStress.java, I have fix for it. >>> >>> Would you mind to share what else failed with Shenandoah? >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>>> >>>> It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as >>>> well as Netbeans. >>>> >>>> In terms of interesting features: >>>> With nmethod entry barriers, immediate oops are removed by: >>>> LIR_Assembler::jobject2reg and MacroAssembler::movoop >>>> This is to ensure consistency with the entry barrier, as otherwise with >>>> an immediate we'd otherwise need an ISB. >>>> >>>> I've added "-XX:DeoptNMethodBarrierALot". I found this functionality >>>> useful in testing as deoptimisation is very infrequent. I've written it >>>> as an atomic to avoid it happening too frequently. As it is a new >>>> option, I'm not sure whether any more is needed than this review. A new >>>> test has been added >>>> "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to >>>> test GC with that option enabled. >>>> >>>> BarrierSetAssembler::nmethod_entry_barrier >>>> This method emits the barrier code. In internal review it was suggested >>>> the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not >>>> done this as the BarrierSetNMethod code checks the exact instruction >>>> sequence, and I prefer to be explicit. >>>> >>>> Benchmarking method entry shows an increase of around 6ns with the >>>> nmethod entry barrier. >>>> >>>> >>>> The deoptimisation code was contributed by Andrew Haley. >>>> >>>> The bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8216557 >>>> >>>> The webrev: >>>> http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ >>>> >>>> >>>> BR, >>>> Stuart >>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you >>>> are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other >>>> person, use it for any purpose, or store or copy the information in any medium. Thank you. >>>> >>> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you >> are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other >> person, use it for any purpose, or store or copy the information in any medium. Thank you. >> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From stumon01 at arm.com Fri Mar 27 15:35:30 2020 From: stumon01 at arm.com (Stuart Monteith) Date: Fri, 27 Mar 2020 15:35:30 +0000 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <105c4a4a-59c9-8095-6d45-642595f65539@redhat.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> <105c4a4a-59c9-8095-6d45-642595f65539@redhat.com> Message-ID: <9bd573db-1983-1dd3-dd11-f7803de3f851@arm.com> Thanks Andrew, I'll change that round. The code verifying the barrier would catch any change there anyway. On 27/03/2020 12:36, Andrew Haley wrote: > On 3/26/20 10:42 PM, Stuart Monteith wrote: >> >> BarrierSetAssembler::nmethod_entry_barrier >> This method emits the barrier code. In internal review it was suggested >> the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not >> done this as the BarrierSetNMethod code checks the exact instruction >> sequence, and I prefer to be explicit. > > I understand, but LoadLoad is the semantics you need, and it's more important > to say that. The mere existence of verification code shouldn't determine > how you express the runtime code. > > I'll do a thorough review later. > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From zgu at redhat.com Fri Mar 27 18:55:24 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 27 Mar 2020 14:55:24 -0400 Subject: [aarch64-port-dev ] [15] RFR 8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier Message-ID: <85e6e3c1-64fd-4873-5a5f-492171b8f9eb@redhat.com> This bug was discovered while testing aarch64 nmethod entry barrier patch posted by Stuart Monteith [1]. We had the same issues on x86 platforms, and fixed by JDK-8233500 and JDK-8237776, but never fixed aarch64. Bug: https://bugs.openjdk.java.net/browse/JDK-8241765 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8241765/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu [1] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-March/028998.html From rkennke at redhat.com Fri Mar 27 19:05:23 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 27 Mar 2020 20:05:23 +0100 Subject: [aarch64-port-dev ] [15] RFR 8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier In-Reply-To: <85e6e3c1-64fd-4873-5a5f-492171b8f9eb@redhat.com> References: <85e6e3c1-64fd-4873-5a5f-492171b8f9eb@redhat.com> Message-ID: <460ce94f-f4eb-95ca-5be1-2a19f4853bc1@redhat.com> Ok. Thank you! Roman > This bug was discovered while testing aarch64 nmethod entry barrier > patch posted by Stuart Monteith [1]. > > We had the same issues on x86 platforms, and fixed by JDK-8233500 and > JDK-8237776, but never fixed aarch64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241765 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8241765/webrev.00/ > > Test: > ? hotspot_gc_shenandoah > > Thanks, > > -Zhengyu > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-March/028998.html > > From stumon01 at arm.com Fri Mar 27 23:12:14 2020 From: stumon01 at arm.com (Stuart Monteith) Date: Fri, 27 Mar 2020 23:12:14 +0000 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <1dc6cf14-267a-2741-2011-3c3a1bb74a38@oracle.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> <1dc6cf14-267a-2741-2011-3c3a1bb74a38@oracle.com> Message-ID: Thanks Per, That all makes sense - I've made those changes, they'll appear in the next patch set. On 27/03/2020 11:36, Per Liden wrote: > Hi Stuart, > > Awesome, thanks a lot for doing this! > > On 3/26/20 11:42 PM, Stuart Monteith wrote: >> Hello, >> Please review this change to implement nmethod entry barriers on >> aarch64, and hence concurrent class unloading with ZGC. Shenandoah will >> need to be separately tested and enabled - there are problems with this >> on Shenandoah. >> >> It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as >> well as Netbeans. >> >> In terms of interesting features: >> With nmethod entry barriers, immediate oops are removed by: >> LIR_Assembler::jobject2reg and MacroAssembler::movoop >> This is to ensure consistency with the entry barrier, as otherwise with >> an immediate we'd otherwise need an ISB. >> >> I've added "-XX:DeoptNMethodBarrierALot". I found this functionality >> useful in testing as deoptimisation is very infrequent. I've written it >> as an atomic to avoid it happening too frequently. As it is a new >> option, I'm not sure whether any more is needed than this review. A new >> test has been added >> "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to >> test GC with that option enabled. >> >> BarrierSetAssembler::nmethod_entry_barrier >> This method emits the barrier code. In internal review it was suggested >> the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not >> done this as the BarrierSetNMethod code checks the exact instruction >> sequence, and I prefer to be explicit. >> >> Benchmarking method entry shows an increase of around 6ns with the >> nmethod entry barrier. >> >> >> The deoptimisation code was contributed by Andrew Haley. >> >> The bug: >> https://bugs.openjdk.java.net/browse/JDK-8216557 >> >> The webrev: >> http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ > > I'll leave the aarch64-specific part for others to review. I just have two minor comments on the rest. > > * May I suggest that we rename DeoptNMethodBarrierALot to DeoptimizeNMethodBarriersALot, to better match > -XX:DeoptimizeALot and friends? > > * The "counter" used should probably be an unsigned type, to avoid any overflow UB. That variable could also move into > the scope where it's used. > > Like: > > ---------------------------------------------------------- > diff --git a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > --- a/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > +++ b/src/hotspot/share/gc/shared/barrierSetNMethod.cpp > @@ -50,7 +50,6 @@ > int BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr) { > address return_address = *return_address_ptr; > CodeBlob* cb = CodeCache::find_blob(return_address); > - static volatile int counter=0; > > assert(cb != NULL, "invariant"); > > @@ -67,8 +66,9 @@ > > // Diagnostic option to force deoptimization 1 in 3 times. It is otherwise > // a very rare event. > - if (DeoptNMethodBarrierALot) { > - if (Atomic::add(&counter, 1) % 3 == 0) { > + if (DeoptimizeNMethodBarriersALot) { > + static volatile uint32_t counter = 0; > + if (Atomic::add(&counter, 1u) % 3 == 0) { > may_enter = false; > } > } > diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp > --- a/src/hotspot/share/runtime/globals.hpp > +++ b/src/hotspot/share/runtime/globals.hpp > @@ -2489,7 +2489,7 @@ > product(bool, UseEmptySlotsInSupers, true, \ > "Allow allocating fields in empty slots of super-classes") \ > > \ > - diagnostic(bool, DeoptNMethodBarrierALot, false, \ > + diagnostic(bool, DeoptimizeNMethodBarriersALot, false, \ > "Make nmethod barriers deoptimise a lot.") \ > > // Interface macros > ---------------------------------------------------------- > > > * Instead of adding a new file for the test, we could just add a new section in the existing test. > > * The test also needs to supply -XX:+UnlockDiagnosticVMOptions. > > Like: > > ---------------------------------------------------------- > diff --git a/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java > b/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java > --- a/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java > +++ b/test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2016, 2019, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2016, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -35,6 +35,18 @@ > * @summary Stress ZGC > * @run main/othervm/timeout=200 -Xlog:gc*=info -Xmx384m -server -XX:+UnlockExperimentalVMOptions -XX:+UseZGC > gc.stress.gcbasher.TestGCBasherWithZ 120000 > */ > + > +/* > + * @test TestGCBasherDeoptWithZ > + * @key gc stress > + * @library / > + * @requires vm.gc.Z > + * @requires vm.flavor == "server" & !vm.emulatedClient & !vm.graal.enabled & vm.opt.ClassUnloading != false > + * @summary Stress ZGC with nmethod barrier forced deoptimization enabled > + * @run main/othervm/timeout=200 -Xlog:gc*,nmethod+barrier=trace -Xmx384m -XX:+UnlockExperimentalVMOptions -XX:+UseZGC > + * -XX:+DeoptimizeNMethodBarriersALot -XX:-Inline gc.stress.gcbasher.TestGCBasherWithZ > 120000 > + */ > + > public class TestGCBasherWithZ { > public static void main(String[] args) throws IOException { > TestGCBasher.main(args); > ---------------------------------------------------------- > > cheers, > Per > > >> >> >> BR, >> Stuart >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you >> are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other >> person, use it for any purpose, or store or copy the information in any medium. Thank you. >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From stumon01 at arm.com Fri Mar 27 23:42:52 2020 From: stumon01 at arm.com (Stuart Monteith) Date: Fri, 27 Mar 2020 23:42:52 +0000 Subject: [aarch64-port-dev ] RFR: 8216557 Aarch64: Add support for Concurrent Class Unloading In-Reply-To: <8f317840-a2b2-3ccb-fbb2-a38b2ebcbf4b@oracle.com> References: <520f8085-eaa0-46bc-9eb9-c1244fca2531@arm.com> <8f317840-a2b2-3ccb-fbb2-a38b2ebcbf4b@oracle.com> Message-ID: <64351542-2e88-b918-025d-74456d507d1a@arm.com> Hi Erik, I'm scratching my head a little as to why I ventured into platform independent code. Anyhow, I've moved the code back to where it belongs, and that'll be in my next webrev. Thanks, Stuart On 27/03/2020 09:47, Erik ?sterlund wrote: > Hi Stuart, > > Thanks for sorting this out on AArch64. It is nice to see thatyou can implement these > barriers on platforms that do not have instruction cache coherency. > > One small change request: > It looks like in C1 you inject the entry barrier right after build_frame is done: > > 629 build_frame(); > 630 { > 631 // Insert nmethod entry barrier into frame. > 632 BarrierSetAssembler* bs = BarrierSet::barrier_set()->barrier_set_assembler(); > 633 bs->nmethod_entry_barrier(_masm); > 634 } > > Unfortunately, this is in the platform independent part of the LIR assembler. In the x86 version > we inject it at the very end of build_frame() instead, which is a platform-specific function. > The platform-specific function is in the C1 macro assembler file for that platform. > > We intentionally put it in the platform-specific path as it is a platform-specific feature. > Now on x86, the barrier code will be emitted once in build_frame() and once after returning > from build_frame, resulting in two nmethod entry barriers, and only the first one will get > patched, causing the second one to mostly take slow paths, which isn't necessarily wrong, > but will cause regressions. > > I would propose you just move those lines into the very end of the AArch64-specific part of > build_frame(). > > I don't need to see another webrev for that trivial code motion. This looks good to me. > Agan, thanks a lot for fixing this! It will allow me to go forward with concurrent stack > scanning on AArch64 as well. > > Thanks, > /Erik > > > On 2020-03-26 23:42, Stuart Monteith wrote: >> Hello, >> Please review this change to implement nmethod entry barriers on >> aarch64, and hence concurrent class unloading with ZGC. Shenandoah will >> need to be separately tested and enabled - there are problems with this >> on Shenandoah. >> >> It has been tested with JTreg, runs with SPECjbb, gcbench, and Lucene as >> well as Netbeans. >> >> In terms of interesting features: >> With nmethod entry barriers, immediate oops are removed by: >> LIR_Assembler::jobject2reg and MacroAssembler::movoop >> This is to ensure consistency with the entry barrier, as otherwise with >> an immediate we'd otherwise need an ISB. >> >> I've added "-XX:DeoptNMethodBarrierALot". I found this functionality >> useful in testing as deoptimisation is very infrequent. I've written it >> as an atomic to avoid it happening too frequently. As it is a new >> option, I'm not sure whether any more is needed than this review. A new >> test has been added >> "test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherDeoptWithZ.java" to >> test GC with that option enabled. >> >> BarrierSetAssembler::nmethod_entry_barrier >> This method emits the barrier code. In internal review it was suggested >> the "dmb( ISHLD )" should be replaced by "membar(LoadLoad)". I've not >> done this as the BarrierSetNMethod code checks the exact instruction >> sequence, and I prefer to be explicit. >> >> Benchmarking method entry shows an increase of around 6ns with the >> nmethod entry barrier. >> >> >> The deoptimisation code was contributed by Andrew Haley. >> >> The bug: >> https://bugs.openjdk.java.net/browse/JDK-8216557 >> >> The webrev: >> http://cr.openjdk.java.net/~smonteith/8216557/webrev.0/ >> >> >> BR, >> Stuart >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you >> are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other >> person, use it for any purpose, or store or copy the information in any medium. Thank you. > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From aph at redhat.com Sat Mar 28 12:23:50 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 28 Mar 2020 12:23:50 +0000 Subject: [aarch64-port-dev ] [15] RFR 8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier In-Reply-To: <85e6e3c1-64fd-4873-5a5f-492171b8f9eb@redhat.com> References: <85e6e3c1-64fd-4873-5a5f-492171b8f9eb@redhat.com> Message-ID: On 3/27/20 6:55 PM, Zhengyu Gu wrote: > This bug was discovered while testing aarch64 nmethod entry barrier > patch posted by Stuart Monteith [1]. > > We had the same issues on x86 platforms, and fixed by JDK-8233500 and > JDK-8237776, but never fixed aarch64. The patch looks OK. It's a bit odd that it wasn't applied to AArch64 at the time, but never mind. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Xiaohong.Gong at arm.com Mon Mar 30 09:20:11 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Mon, 30 Mar 2020 09:20:11 +0000 Subject: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. Message-ID: Hi, Recently we met the Renassiance benchmark hang issue on AArch64 when running with VM option "-XX:+UseBarriersForVolatile". We noticed that it should be the same memory sequentially consistent issue mentioned in JDK-8179954 which is caused by mixed using "LDR, DMB ISHLD" for java volatile load and "STLR/STLXR" for volatile store. JDK-8179954 resolved it by inserting a full barrier before the volatile load in C1/Interpreter. However it only happens with the VM option "UseBarriersForVolatile" closed, because C2 only uses "LDAR/STLR" to implement the volatile access under it. Here is a part of the fixing codes in Interpreter: if (! UseBarriersForVolatile) { Label notVolatile; __ tbz(raw_flags, ConstantPoolCacheEntry::is_volatile_shift, notVolatile); __ membar(MacroAssembler::AnyAny); __ bind(notVolatile); } However, there are also some other places that use "STLR/STLXR" in hotspot when "UseBarriersForVolatile" is true, like monitor and atomics. For atomics like CAS, they do not have a trailing "STORE_LOAD" barrier with "-XX:+UseBarriersForVolatile". This might have the memory consistent issue if there is a subsequent volatile load ("LDR, DMB ISHLD"). Here is the codes generated for CAS by C2 with "-XX:+UseBarriersForVolatile": dmb ish retry: ldxr w0, [address] cmp w0, w1 b.ne done stlxr w8, w2, [address] cbnz w8, retry done: dmb ishld // LOAD_LOAD | LOAD_STORE Without a STORE_LOAD barrier, the subsequent load could be float up before "stlxr" of the CAS. This might expected not to happen if the load is a volatile one. So my question is: what does the main usage of the option "-XX:+UseBarriersForVolatile" in real applications? Do we need to concern the issues with it? If we do, so maybe the issue is valuable to be fixed. I also created a JBS here: https://bugs.openjdk.java.net/browse/JDK-8241137. Thanks, Xiaohong Gong From aph at redhat.com Mon Mar 30 09:55:33 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Mar 2020 10:55:33 +0100 Subject: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. In-Reply-To: References: Message-ID: On 3/30/20 10:20 AM, Xiaohong Gong wrote: > So my question is: what does the main usage of the option "-XX:+UseBarriersForVolatile" in real applications? Do we need to concern > the issues with it? If we do, so maybe the issue is valuable to be fixed. > I also created a JBS here: https://bugs.openjdk.java.net/browse/JDK-8241137. There is no usage of "-XX:+UseBarriersForVolatile" in real applications. Any flags of this kind are dangerous because they tend to break over time because they are not tested. I was thinking we could make this a diagnostic-only flag, but perhaps it should be removed altogether. Patches welcome. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Xiaohong.Gong at arm.com Mon Mar 30 10:13:17 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Mon, 30 Mar 2020 10:13:17 +0000 Subject: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. In-Reply-To: References: Message-ID: Hi Andrew, Thanks for your replying! We will take a look and find a better way for it. Thanks, Xiaohong Gong -----Original Message----- From: Andrew Haley Sent: Monday, March 30, 2020 5:56 PM To: Xiaohong Gong ; aarch64-port-dev at openjdk.java.net Cc: nd Subject: Re: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. On 3/30/20 10:20 AM, Xiaohong Gong wrote: > So my question is: what does the main usage of the option > "-XX:+UseBarriersForVolatile" in real applications? Do we need to concern the issues with it? If we do, so maybe the issue is valuable to be fixed. > I also created a JBS here: https://bugs.openjdk.java.net/browse/JDK-8241137. There is no usage of "-XX:+UseBarriersForVolatile" in real applications. Any flags of this kind are dangerous because they tend to break over time because they are not tested. I was thinking we could make this a diagnostic-only flag, but perhaps it should be removed altogether. Patches welcome. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Mon Mar 30 10:13:51 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 30 Mar 2020 18:13:51 +0800 Subject: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. In-Reply-To: References: Message-ID: <85r1xap2u8.fsf@nicgas01-03-arm-vm.shanghai.arm.com> On 03/30/20 17:55 pm, Andrew Haley wrote: > > There is no usage of "-XX:+UseBarriersForVolatile" in real applications. > Any flags of this kind are dangerous because they tend to break over time > because they are not tested. > > I was thinking we could make this a diagnostic-only flag, but perhaps it > should be removed altogether. Patches welcome. There is this one use in vm_version_aarch64.cpp: if (FLAG_IS_DEFAULT(UseBarriersForVolatile)) { UseBarriersForVolatile = (_features & CPU_DMB_ATOMICS) != 0; } CPU_DMB_ATOMICS is set for one particular variant of one vendor's CPU. It came from "8079203: aarch64: need to cater for different partner implementations". But I can't find any explanation as to why it's required. Any ideas? CPU errata? http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2015-May/002315.html Thanks, Nick From aph at redhat.com Mon Mar 30 10:43:57 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Mar 2020 11:43:57 +0100 Subject: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. In-Reply-To: <85r1xap2u8.fsf@nicgas01-03-arm-vm.shanghai.arm.com> References: <85r1xap2u8.fsf@nicgas01-03-arm-vm.shanghai.arm.com> Message-ID: On 3/30/20 11:13 AM, Nick Gasson wrote: > There is this one use in vm_version_aarch64.cpp: > > if (FLAG_IS_DEFAULT(UseBarriersForVolatile)) { > UseBarriersForVolatile = (_features & CPU_DMB_ATOMICS) != 0; > } > > CPU_DMB_ATOMICS is set for one particular variant of one vendor's > CPU. It came from "8079203: aarch64: need to cater for different partner > implementations". But I can't find any explanation as to why it's > required. Any ideas? CPU errata? > > http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2015-May/002315.html I remember an early stepping where STLR/LDAR weren't sequentially consistent, so it was necessary to generate explicit DMBs. I doubt that parts with this bug ever reached the market. Having said that, maybe someone is still using one. It might be worth correcting UseBarriersForVolatile and making the flag diagnostic only. Having said that, the entire C library uses these instructions. Opinions? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From derekw at marvell.com Mon Mar 30 15:09:05 2020 From: derekw at marvell.com (Derek White) Date: Mon, 30 Mar 2020 15:09:05 +0000 Subject: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. Message-ID: I think that was us (a bit before my time!). I'll double-check if that variant ever made it out... - Derek -----Original Message----- From: aarch64-port-dev On Behalf Of Andrew Haley Sent: Monday, March 30, 2020 6:44 AM To: Nick Gasson ; aarch64-port-dev at openjdk.java.net Cc: nd ; Xiaohong Gong Subject: Re: [aarch64-port-dev ] Question about JVM option "-XX:+UseBarriersForVolatile" usage in aarch64. ---------------------------------------------------------------------- On 3/30/20 11:13 AM, Nick Gasson wrote: > There is this one use in vm_version_aarch64.cpp: > > if (FLAG_IS_DEFAULT(UseBarriersForVolatile)) { > UseBarriersForVolatile = (_features & CPU_DMB_ATOMICS) != 0; > } > > CPU_DMB_ATOMICS is set for one particular variant of one vendor's CPU. > It came from "8079203: aarch64: need to cater for different partner > implementations". But I can't find any explanation as to why it's > required. Any ideas? CPU errata? > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java. > net_pipermail_aarch64-2Dport-2Ddev_2015-2DMay_002315.html&d=DwIF-g&c=n > KjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m= > dY4p0rOQhLXVe5xRZZlJ8GqVaDTZuBaQrt_nb8fBMKA&s=Uh_9IoXOwz8i9My-P1YeUPZm > TkPUoQUenIVVvmoAIPw&e= I remember an early stepping where STLR/LDAR weren't sequentially consistent, so it was necessary to generate explicit DMBs. I doubt that parts with this bug ever reached the market. Having said that, maybe someone is still using one. It might be worth correcting UseBarriersForVolatile and making the flag diagnostic only. Having said that, the entire C library uses these instructions. Opinions? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_andrewhaley&d=DwIF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=dY4p0rOQhLXVe5xRZZlJ8GqVaDTZuBaQrt_nb8fBMKA&s=7liR09iA-HShWd3YYB5D3GPN35Ha9S_bwRIJX5VWpTI&e= EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Tue Mar 31 09:32:21 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Tue, 31 Mar 2020 09:32:21 +0000 Subject: [aarch64-port-dev ] RFR(S): 8241475: AArch64: Add missing support for PopCountVI node Message-ID: Hi, Please help review this another missing node support for AArch64. JBS: https://bugs.openjdk.java.net/browse/JDK-8241475 Webrev: http://cr.openjdk.java.net/~pli/rfr/8241475/webrev.01/ This adds missing support for C2 node "PopCountVI" for AArch64. This node is now used on x86 and ppc for the codegen of vectorized bit count of multiple lanes of ints. In this AArch64 implementation, CNT instruction is used firstly to get a per-byte bit count of the NEON register. Then two UADDLP instructions are used to convert the per-byte counts to per-int counts. [TESTS] Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. No new failure found. Intel has already contributed a jtreg case in the x86 patch [1] for this. JMH: Tested with a small JMH [2] Before: Benchmark Mode Cnt Score Error Units TestPopCount.testPopCount avgt 15 129.773 ? 36.120 us/op After: Benchmark Mode Cnt Score Error Units TestPopCount.testPopCount avgt 15 41.830 ? 0.068 us/op Thanks Dmitrij for the suggestion on this patch. [1] http://hg.openjdk.java.net/jdk/jdk/rev/b242a1e3f9cf [2] http://cr.openjdk.java.net/~pli/rfr/8241475/TestPopCount.java -- Thanks, Pengfei From aph at redhat.com Tue Mar 31 14:33:14 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Mar 2020 15:33:14 +0100 Subject: [aarch64-port-dev ] RFR(S): 8241475: AArch64: Add missing support for PopCountVI node In-Reply-To: References: Message-ID: <2ce24736-9b5c-5c23-bfde-14067d6d6b0d@redhat.com> Hi, On 3/31/20 10:32 AM, Pengfei Li wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8241475 > Webrev: http://cr.openjdk.java.net/~pli/rfr/8241475/webrev.01/ > > This adds missing support for C2 node "PopCountVI" for AArch64. This > node is now used on x86 and ppc for the codegen of vectorized bit count > of multiple lanes of ints. > > In this AArch64 implementation, CNT instruction is used firstly to get > a per-byte bit count of the NEON register. Then two UADDLP instructions > are used to convert the per-byte counts to per-int counts. > > [TESTS] > Jtreg: hotspot::hotspot_all_no_apps, jdk::jdk_core and langtools::tier1. > No new failure found. Intel has already contributed a jtreg case in the > x86 patch [1] for this. Looks fine. I take it the change to @@ -2278,12 +2279,13 @@ } INSN(absr, 0, 0b100000101110, 1); // accepted arrangements: T8B, T16B, T4H, T8H, T4S - INSN(negr, 1, 0b100000101110, 2); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S, T2D is actually related to some other work you are doing? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Tue Mar 31 19:39:22 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 31 Mar 2020 19:39:22 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <202003311939.02VJdMBE008637@aojmv0008.oracle.com> Changeset: 72a6d93679e5 Author: andrew Date: 2020-03-20 14:25 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/72a6d93679e5 Added tag jdk8u252-b07 for changeset 746815de8b5b ! .hgtags Changeset: 57a11875546a Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/57a11875546a Merge jdk8u252-b07 ! .hgtags Changeset: 72d8c6c077e1 Author: andrew Date: 2020-03-23 21:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/72d8c6c077e1 Added tag aarch64-shenandoah-jdk8u252-b07 for changeset 57a11875546a ! .hgtags From gnu.andrew at redhat.com Tue Mar 31 19:46:25 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 31 Mar 2020 19:46:25 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <202003311946.02VJkPvh011696@aojmv0008.oracle.com> Changeset: 63738d15bb7f Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/63738d15bb7f Added tag jdk8u252-b07 for changeset ee99eeee44ad ! .hgtags Changeset: cb7514c874ee Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/cb7514c874ee Merge jdk8u252-b07 ! .hgtags Changeset: 8bb2bcdd74ab Author: andrew Date: 2020-03-23 21:34 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/8bb2bcdd74ab Added tag aarch64-shenandoah-jdk8u252-b07 for changeset cb7514c874ee ! .hgtags From gnu.andrew at redhat.com Tue Mar 31 20:12:11 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 31 Mar 2020 20:12:11 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 3 new changesets Message-ID: <202003312012.02VKCB03027267@aojmv0008.oracle.com> Changeset: 95d61d0f326b Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/95d61d0f326b Added tag jdk8u252-b07 for changeset 0666ec7fe2b4 ! .hgtags Changeset: cbbbe5b13332 Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/cbbbe5b13332 Merge jdk8u252-b07 ! .hgtags Changeset: 62c5e270b91d Author: andrew Date: 2020-03-23 21:35 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/62c5e270b91d Added tag aarch64-shenandoah-jdk8u252-b07 for changeset cbbbe5b13332 ! .hgtags From gnu.andrew at redhat.com Tue Mar 31 20:23:14 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 31 Mar 2020 20:23:14 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 3 new changesets Message-ID: <202003312023.02VKNEmU003502@aojmv0008.oracle.com> Changeset: 00eaaa430a54 Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/00eaaa430a54 Added tag jdk8u252-b07 for changeset d17814ea88e3 ! .hgtags Changeset: 9f9d7938db16 Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9f9d7938db16 Merge jdk8u252-b07 ! .hgtags Changeset: 032c004c0b23 Author: andrew Date: 2020-03-23 21:35 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/032c004c0b23 Added tag aarch64-shenandoah-jdk8u252-b07 for changeset 9f9d7938db16 ! .hgtags