From shade at redhat.com Sat Feb 1 07:28:16 2020 From: shade at redhat.com (shade at redhat.com) Date: Sat, 01 Feb 2020 07:28:16 +0000 Subject: hg: shenandoah/jdk11: Added tag shenandoah-jdk-11.0.7+1 for changeset 037608498d95 Message-ID: <202002010728.0117SHa8015759@aojmv0008.oracle.com> Changeset: ac4129891412 Author: shade Date: 2020-02-01 08:22 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ac4129891412 Added tag shenandoah-jdk-11.0.7+1 for changeset 037608498d95 ! .hgtags From zgu at redhat.com Mon Feb 3 20:59:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 3 Feb 2020 15:59:28 -0500 Subject: [14] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" Message-ID: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> Shenandoah uses oop mark word's "marked" pattern to indicate forwarding. Unfortunately, JVMTI heap walk (VM_HeapWalkOperation) also uses this pattern to indicate visited. The conflicts present serious problems during Shenandoah's concurrent evacuation and concurrent reference update phases, as it blindly treats "marked" pattern as "forwarding". There are invariants we can use to distinguish "forwarding" and "visited" pattern. 1. Marked pattern in collection set indicates forwarding 2. Marked pattern off collection set indicates visited by ObjectMarker (because oops seen by ObjectMarker were LRB'd) 3. No off collection set marked pattern at any shenandoah safepoint. In fact, no off collection set marked pattern at any safepoints except VM_HeapWalkOperation safepoints. This is an important invariant, since traversal degenerated GC drops collection set before entering degenerated GC cycle. Note: We only downgrade some debug assertions, but preserve full capacities of verifier, because verifier always runs at safepoints. Bug: https://bugs.openjdk.java.net/browse/JDK-8237632 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.00/ Test: hotspot_gc_shenandoah vmTestbase_nsk_jvmti vmTestbase_nsk_jdi Thanks, -Zhengyu From zgu at redhat.com Tue Feb 4 13:35:43 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 4 Feb 2020 08:35:43 -0500 Subject: [15] RFR 8238162: Shenandoah: Remove ShenandoahTaskTerminator wrapper Message-ID: I can not recall why we still have terminator wrapper, probably a leftover after we upstreamed OWST terminator. Let's remove it. Bug: https://bugs.openjdk.java.net/browse/JDK-8238162 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8238162/webrev.00/index.html Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Tue Feb 4 19:15:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Feb 2020 20:15:16 +0100 Subject: [15] RFR 8238162: Shenandoah: Remove ShenandoahTaskTerminator wrapper In-Reply-To: References: Message-ID: On 2/4/20 2:35 PM, Zhengyu Gu wrote: > I can not recall why we still have terminator wrapper, probably a > leftover after we upstreamed OWST terminator. Let's remove it. I think we have upstreamed our version here? If so, please link it to 8238162: https://bugs.openjdk.java.net/browse/JDK-8204947 > Bug: https://bugs.openjdk.java.net/browse/JDK-8238162 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8238162/webrev.00/index.html Looks good. -- Thanks, -Aleksey From shade at redhat.com Tue Feb 4 19:23:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Feb 2020 20:23:05 +0100 Subject: [14] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" In-Reply-To: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> References: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> Message-ID: On 2/3/20 9:59 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8237632 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.00/ Uh. It seems to me the cure is worse than the disease: 1) It rewires sensitive parts of barrier paths, root handling, etc, which requires more thorough testing, and we are too deep in RDP2 for this; 2) It effectively disables asserts for anything not in collection set. Which means it disables most of asserts. The fact that Verifier still works is a small consolation. I propose to accept this failure in 14, and rework the JVMTI heap walk to stop messing around with mark words in 15. Since this relates to concurrent root handling, 11-shenandoah is already safe. -- Thanks, -Aleksey From zgu at redhat.com Tue Feb 4 19:29:52 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 4 Feb 2020 14:29:52 -0500 Subject: [14] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" In-Reply-To: References: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> Message-ID: <2121a97b-47fe-0205-51ad-a927576fbb93@redhat.com> On 2/4/20 2:23 PM, Aleksey Shipilev wrote: > On 2/3/20 9:59 PM, Zhengyu Gu wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8237632 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.00/ > > Uh. It seems to me the cure is worse than the disease: > 1) It rewires sensitive parts of barrier paths, root handling, etc, which requires more thorough > testing, and we are too deep in RDP2 for this; > 2) It effectively disables asserts for anything not in collection set. Which means it disables > most of asserts. The fact that Verifier still works is a small consolation. > > I propose to accept this failure in 14, and rework the JVMTI heap walk to stop messing around with > mark words in 15. Since this relates to concurrent root handling, 11-shenandoah is already safe. I have yet to test 11-shenandoah. But performing JVMTI heap walk during evacuation phase, still sounds the alarm to me. -Zhengyu > From shade at redhat.com Tue Feb 4 19:33:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Feb 2020 20:33:28 +0100 Subject: [14] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" In-Reply-To: <2121a97b-47fe-0205-51ad-a927576fbb93@redhat.com> References: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> <2121a97b-47fe-0205-51ad-a927576fbb93@redhat.com> Message-ID: On 2/4/20 8:29 PM, Zhengyu Gu wrote: > On 2/4/20 2:23 PM, Aleksey Shipilev wrote: >> On 2/3/20 9:59 PM, Zhengyu Gu wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237632 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.00/ >> >> Uh. It seems to me the cure is worse than the disease: >> 1) It rewires sensitive parts of barrier paths, root handling, etc, which requires more thorough >> testing, and we are too deep in RDP2 for this; >> 2) It effectively disables asserts for anything not in collection set. Which means it disables >> most of asserts. The fact that Verifier still works is a small consolation. >> >> I propose to accept this failure in 14, and rework the JVMTI heap walk to stop messing around with >> mark words in 15. Since this relates to concurrent root handling, 11-shenandoah is already safe. > > I have yet to test 11-shenandoah. But performing JVMTI heap walk during > evacuation phase, still sounds the alarm to me. Right. There is still plenty of time to fix 11. Let's not rush it in 14. -- Thanks, -Aleksey From shade at redhat.com Wed Feb 5 10:22:49 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 5 Feb 2020 11:22:49 +0100 Subject: RFC: Pick up 11.0.7+2 to sh/jdk11 Message-ID: Upstream had published jdk-11.0.7+2, let's pick it up to sh/jdk11. Merge is trivial. I would tag it as shenandoah-jdk-11.0.7+2 immediately. Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From rkennke at redhat.com Wed Feb 5 10:33:56 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 5 Feb 2020 11:33:56 +0100 Subject: RFC: Pick up 11.0.7+2 to sh/jdk11 In-Reply-To: References: Message-ID: <54ab1911-94fc-5040-4936-ba8072af0e4b@redhat.com> Yes, please do that! Thanks, Roman > Upstream had published jdk-11.0.7+2, let's pick it up to sh/jdk11. > Merge is trivial. I would tag it as shenandoah-jdk-11.0.7+2 immediately. > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From shade at redhat.com Wed Feb 5 10:33:34 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 05 Feb 2020 10:33:34 +0000 Subject: hg: shenandoah/jdk11: 7 new changesets Message-ID: <202002051033.015AXaMu016766@aojmv0008.oracle.com> Changeset: 20d1a1b806ce Author: iklam Date: 2018-08-14 09:59 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/20d1a1b806ce 8208658: Make CDS archived heap regions usable even if compressed oop encoding has changed Summary: Relocate and patch archive regions if necessary Reviewed-by: jiangli, tschatzl ! src/hotspot/share/classfile/compactHashtable.cpp ! src/hotspot/share/classfile/compactHashtable.inline.hpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupThread.cpp ! src/hotspot/share/include/cds.h ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/filemap.hpp ! src/hotspot/share/memory/heapShared.cpp ! src/hotspot/share/memory/heapShared.hpp + src/hotspot/share/memory/heapShared.inline.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! src/hotspot/share/memory/metaspaceShared.hpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/instanceMirrorKlass.cpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/utilities/bitMap.cpp ! src/hotspot/share/utilities/bitMap.hpp + test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java - test/hotspot/jtreg/runtime/appcds/cacheObject/RangeNotWithinHeap.java ! test/hotspot/jtreg/runtime/appcds/sharedStrings/IncompatibleOptions.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 23b27e86d491 Author: iklam Date: 2018-09-05 18:14 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/23b27e86d491 8210289: ArchivedKlassSubGraphInfoRecord is incomplete Reviewed-by: jiangli, ccheung ! src/hotspot/share/memory/heapShared.cpp ! src/hotspot/share/memory/heapShared.hpp ! src/hotspot/share/memory/metaspaceShared.cpp Changeset: 6721e038257a Author: valeriep Date: 2018-12-13 01:15 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/6721e038257a 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck Summary: Changed Provider class to use ConcurrentHashMap and default providers to use putService() Reviewed-by: weijun, mullan ! src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/sun/security/provider/Sun.java ! src/java.base/share/classes/sun/security/provider/SunEntries.java ! src/java.base/share/classes/sun/security/provider/VerificationProvider.java ! src/java.base/share/classes/sun/security/rsa/SunRsaSign.java ! src/java.base/share/classes/sun/security/rsa/SunRsaSignEntries.java ! src/java.base/share/classes/sun/security/ssl/SunJSSE.java Changeset: 15cc1c8a6371 Author: andrew Date: 2020-02-04 04:42 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/15cc1c8a6371 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 Reviewed-by: shade, aph, sgehwolf ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64_log.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64_trig.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp ! src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.s ! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp Changeset: 69ed892f0be5 Author: goetz Date: 2020-02-05 09:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/69ed892f0be5 Added tag jdk-11.0.7+2 for changeset 15cc1c8a6371 ! .hgtags Changeset: 1192ae1875d9 Author: shade Date: 2020-02-05 10:44 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/1192ae1875d9 Merge ! .hgtags ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/share/utilities/bitMap.cpp ! src/hotspot/share/utilities/bitMap.hpp - test/hotspot/jtreg/runtime/appcds/cacheObject/RangeNotWithinHeap.java Changeset: f382bcfcc02f Author: shade Date: 2020-02-05 10:44 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/f382bcfcc02f Added tag shenandoah-jdk-11.0.7+2 for changeset 1192ae1875d9 ! .hgtags From amirhadadi at hotmail.com Wed Feb 5 14:23:09 2020 From: amirhadadi at hotmail.com (Amir Hadadi) Date: Wed, 5 Feb 2020 14:23:09 +0000 Subject: Shenandoah JDK 8 backport crashes when running Cassandra Message-ID: Hi all, After deploying Cassandra 3.11.4 with Shenandoah's backport to JDK 8, the JVM occasionally crashes. I can share the full crash log privately, here's the start: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f2fd6a1a559, pid=102562, tid=0x00007f28885f7700 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8-b517-20191231) # Java VM: OpenJDK 64-Bit Server VM (25.71-b517-20191231 mixed mode linux-amd64 compressed oops) # Problematic frame: # J 10739 C1 org.caffinitas.ohc.linked.OffHeapMap$Table.removeLinkInternal(JJJJ)V (83 bytes) @ 0x00007f2fd6a1a559 [0x00007f2fd6a19e00+0x759] # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00007f27d8007620): JavaThread "ReadStage-2" daemon [_thread_in_Java, id=103716, stack(0x00007f28885b7000,0x00007f28885f8000)] siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000000f Registers: RAX=0x0000000000000000, RBX=0x000000000000000d, RCX=0x0000000000000008, RDX=0x0000000000000010 RSP=0x00007f28885f6090, RBP=0x00007f28885f63e8, RSI=0xffffffffffffffff, RDI=0x0000000000000010 R8 =0x000000000000000f, R9 =0x0000000000000000, R10=0x00007f2fed1b5360, R11=0x00007f2f4c6f7d18 R12=0x0000000000000000, R13=0x0000000000560040, R14=0x00007f28885f6408, R15=0x00007f27d8007620 RIP=0x00007f2fd6a1a559, EFLAGS=0x0000000000010207, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 TRAPNO=0x000000000000000e Top of Stack: (sp=0x00007f28885f6090) 0x00007f28885f6090: 0000000000000005 00007f2fd7a1e42c 0x00007f28885f60a0: 0000000700000001 00000007bb964570 0x00007f28885f60b0: 00000007bb964700 0000000600000005 0x00007f28885f60c0: 00000007beb6bb20 00007f2f00000001 0x00007f28885f60d0: 00000003f5d8e200 00000007bb964570 0x00007f28885f60e0: 0000000000000001 00007f2fd74214b0 0x00007f28885f60f0: 0000000000000004 00007f2fd6312118 0x00007f28885f6100: f80914d8e6dd26ab e312c4a300000000 0x00007f28885f6110: 00000003f5d8e200 00007f2fd9335344 0x00007f28885f6120: 0000000000000014 00007f2fd6a1a764 0x00007f28885f6130: 00000003f808eaf3 00007f2f00000000 0x00007f28885f6140: 00000007baaa4830 00007f292b45b2c0 0x00007f28885f6150: 0000000000329b88 00007f2fe6432320 0x00007f28885f6160: ffffffffffffffff 0000000000000000 0x00007f28885f6170: 00000006e3f4c168 5205e883464e5371 0x00007f28885f6180: 00000003f5d8d868 0000000000000005 0x00007f28885f6190: ffffffffffffffff 0000000000000010 0x00007f28885f61a0: 00000003f5d8ce58 00000007bea177b0 0x00007f28885f61b0: 00000003f5d8e0d8 00007f2fd60fca74 0x00007f28885f61c0: 00007f28885f63e8 00007f2fd8b5225c 0x00007f28885f61d0: 00000003f5d8d7e0 00000003f5d8e1f0 0x00007f28885f61e0: 0000000400000004 00007f292b45b2c0 0x00007f28885f61f0: 0000000000165ae8 00007f25398fff50 0x00007f28885f6200: 0000000000000000 0000000000000000 0x00007f28885f6210: 00000006e3f4c168 518c1e395d6acb5d 0x00007f28885f6220: 0000000700000005 0000000000000014 0x00007f28885f6230: 00000003f5d8d5d8 00000003f5d8d840 0x00007f28885f6240: 00007f292b45b2c0 0000000000165ae8 0x00007f28885f6250: 00007f28885f62b8 00007f2fd5007a40 0x00007f28885f6260: 00007f2fd5007a40 0000000000000000 0x00007f28885f6270: 0000000000000010 00007f28885f6278 0x00007f28885f6280: 00007f2f4d0430ed 00007f28885f62d0 Instructions: (pc=0x00007f2fd6a1a559) 0x00007f2fd6a1a539: 01 00 00 48 8b bc 24 08 01 00 00 4c 03 c7 48 b8 0x00007f2fd6a1a549: 00 00 00 00 00 00 00 00 4c 8b 8c 24 d8 00 00 00 0x00007f2fd6a1a559: 4e 89 0c 00 48 81 c4 30 01 00 00 5d 85 05 95 7b 0x00007f2fd6a1a569: 5c 17 c3 48 8b 94 24 e8 00 00 00 48 8b b4 24 e0 Register to memory mapping: RAX=0x0000000000000000 is an unknown value RBX=0x000000000000000d is an unknown value RCX=0x0000000000000008 is an unknown value RDX=0x0000000000000010 is an unknown value RSP=0x00007f28885f6090 is pointing into the stack for thread: 0x00007f27d8007620 RBP=0x00007f28885f63e8 is pointing into the stack for thread: 0x00007f27d8007620 RSI=0xffffffffffffffff is an unknown value RDI=0x0000000000000010 is an unknown value R8 =0x000000000000000f is an unknown value R9 =0x0000000000000000 is an unknown value R10=0x00007f2fed1b5360: in /usr/lib/jvm/jdk1.8.0_builds.shipilev.net-openjdk-shenandoah-jdk8/jre/lib/amd64/server/libjvm.so at 0x00007f2fec1ad000 R11=0x00007f2f4c6f7d18 is pointing into metadata R12=0x0000000000000000 is an unknown value R13=0x0000000000560040 is an unknown value R14=0x00007f28885f6408 is pointing into the stack for thread: 0x00007f27d8007620 R15=0x00007f27d8007620 is a thread Stack: [0x00007f28885b7000,0x00007f28885f8000], sp=0x00007f28885f6090, free space=252k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) J 10739 C1 org.caffinitas.ohc.linked.OffHeapMap$Table.removeLinkInternal(JJJJ)V (83 bytes) @ 0x00007f2fd6a1a559 [0x00007f2fd6a19e00+0x759] J 19594 C1 org.caffinitas.ohc.linked.OffHeapMap.removeInternal(JJZ)V (129 bytes) @ 0x00007f2fd8b5225c [0x00007f2fd8b51e40+0x41c] j org.caffinitas.ohc.linked.OffHeapMap.removeEldest()J+19 J 27364 C1 org.caffinitas.ohc.linked.OffHeapMap.putEntry(JJJJZJJJJ)Z (604 bytes) @ 0x00007f2fd95d177c [0x00007f2fd95d0140+0x163c] J 15835 C2 org.caffinitas.ohc.linked.OHCacheImpl.putInternal(Ljava/lang/Object;Ljava/lang/Object;ZLjava/lang/Object;J)Z (317 bytes) @ 0x00007f2fd8722fc8 [0x00007f2fd8722a00+0x5c8] J 20313 C2 org.apache.cassandra.db.SinglePartitionReadCommand.getThroughCache(Lorg/apache/cassandra/db/ColumnFamilyStore;Lorg/apache/cassandra/db/ReadExecutionController;)Lorg/apache/cassandra/db/rows/UnfilteredRowIterator; (604 bytes) @ 0x00007f2fd6a74388 [0x00007f2fd6a70d00+0x3688] J 11197 C2 org.apache.cassandra.db.ReadCommand.executeLocally(Lorg/apache/cassandra/db/ReadExecutionController;)Lorg/apache/cassandra/db/partitions/UnfilteredPartitionIterator; (258 bytes) @ 0x00007f2fd7b8a538 [0x00007f2fd7b8a0a0+0x498] J 15994 C2 org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow()V (356 bytes) @ 0x00007f2fd6116774 [0x00007f2fd6116620+0x154] J 15992 C2 org.apache.cassandra.service.StorageProxy$DroppableRunnable.run()V (51 bytes) @ 0x00007f2fd79ab02c [0x00007f2fd79aaf80+0xac] J 24963% C2 org.apache.cassandra.concurrent.SEPWorker.run()V (306 bytes) @ 0x00007f2fd9aefa10 [0x00007f2fd9aeeba0+0xe70] J 6632 C1 java.lang.Thread.run()V (17 bytes) @ 0x00007f2fd5329564 [0x00007f2fd5329400+0x164] v ~StubRoutines::call_stub V [libjvm.so+0x67f2c0] JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)+0xfb0 V [libjvm.so+0x67c7c7] JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x277 V [libjvm.so+0x67cda7] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x57 V [libjvm.so+0x6bac95] thread_entry(JavaThread*, Thread*)+0x75 V [libjvm.so+0xaa5c7f] JavaThread::thread_main_inner()+0xdf V [libjvm.so+0xaa5fd9] JavaThread::run()+0x329 V [libjvm.so+0x8cdcb2] java_start(Thread*)+0xf2 C [libpthread.so.0+0x8184] start_thread+0xc4 From shade at redhat.com Wed Feb 5 14:43:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 5 Feb 2020 15:43:00 +0100 Subject: Shenandoah JDK 8 backport crashes when running Cassandra In-Reply-To: References: Message-ID: <60cb3e90-59a9-73be-db99-336deb4d37ef@redhat.com> Hi Amir, On 2/5/20 3:23 PM, Amir Hadadi wrote: > # SIGSEGV (0xb) at pc=0x00007f2fd6a1a559, pid=102562, tid=0x00007f28885f7700 > # > # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8-b517-20191231) Trying a bit more modern build would be a plus. > --------------- T H R E A D --------------- > Current thread (0x00007f27d8007620): JavaThread "ReadStage-2" daemon [_thread_in_Java, id=103716, stack(0x00007f28885b7000,0x00007f28885f8000)] > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000000f > Registers: > RAX=0x0000000000000000, RBX=0x000000000000000d, RCX=0x0000000000000008, RDX=0x0000000000000010 > RSP=0x00007f28885f6090, RBP=0x00007f28885f63e8, RSI=0xffffffffffffffff, RDI=0x0000000000000010 > R8 =0x000000000000000f, R9 =0x0000000000000000, R10=0x00007f2fed1b5360, R11=0x00007f2f4c6f7d18 > R12=0x0000000000000000, R13=0x0000000000560040, R14=0x00007f28885f6408, R15=0x00007f27d8007620 > RIP=0x00007f2fd6a1a559, EFLAGS=0x0000000000010207, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > Instructions: (pc=0x00007f2fd6a1a559) > 0x00007f2fd6a1a539: 01 00 00 48 8b bc 24 08 01 00 00 4c 03 c7 48 b8 > 0x00007f2fd6a1a549: 00 00 00 00 00 00 00 00 4c 8b 8c 24 d8 00 00 00 > 0x00007f2fd6a1a559: 4e 89 0c 00 48 81 c4 30 01 00 00 5d 85 05 95 7b > 0x00007f2fd6a1a569: 5c 17 c3 48 8b 94 24 e8 00 00 00 48 8b b4 24 e0 This decodes to: 48 b8 00 00 00 00 00 00 00 00 movabs rax,0x0 4c 8b 8c 24 d8 00 00 00 mov r9,QWORD PTR [rsp+0xd8] 4e 89 0c 00 mov QWORD PTR [rax+r8*1],r9 <--- crash here 48 81 c4 30 01 00 00 add rsp,0x130 The prior store of literal zero to %rax is weird, is that a code root or a C1 patch going wrong? How reproducible is this? Are there specific steps to reproduce? Please try with -XX:+ShenandoahVerify and/or fastdebug builds. -- Thanks, -Aleksey From amirhadadi at hotmail.com Wed Feb 5 16:40:50 2020 From: amirhadadi at hotmail.com (Amir Hadadi) Date: Wed, 5 Feb 2020 16:40:50 +0000 Subject: Shenandoah JDK 8 backport crashes when running Cassandra Message-ID: "Trying a bit more modern build would be a plus" - this is a build from 31/12/2019, by more modern you mean a JDK 8 backport from 2020? I'm forced to use JDK 8 as Cassandra 3.X is not compatible with JDK versions above 8. I currently don't have a reproducer, will try -XX:+ShenandoahVerify. BTW this code in Cassandra involves an off heap structure manipulated with Unsafe. This library is handling the off heap structure: https://github.com/snazy/ohc/tree/develop/ohc-core/src/main/java/org/caffinitas/ohc ________________________________ From: Aleksey Shipilev Sent: Wednesday, February 5, 2020 4:43 PM To: Amir Hadadi; shenandoah-dev at openjdk.java.net Subject: Re: Shenandoah JDK 8 backport crashes when running Cassandra Hi Amir, On 2/5/20 3:23 PM, Amir Hadadi wrote: > # SIGSEGV (0xb) at pc=0x00007f2fd6a1a559, pid=102562, tid=0x00007f28885f7700 > # > # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8-b517-20191231) Trying a bit more modern build would be a plus. > --------------- T H R E A D --------------- > Current thread (0x00007f27d8007620): JavaThread "ReadStage-2" daemon [_thread_in_Java, id=103716, stack(0x00007f28885b7000,0x00007f28885f8000)] > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000000f > Registers: > RAX=0x0000000000000000, RBX=0x000000000000000d, RCX=0x0000000000000008, RDX=0x0000000000000010 > RSP=0x00007f28885f6090, RBP=0x00007f28885f63e8, RSI=0xffffffffffffffff, RDI=0x0000000000000010 > R8 =0x000000000000000f, R9 =0x0000000000000000, R10=0x00007f2fed1b5360, R11=0x00007f2f4c6f7d18 > R12=0x0000000000000000, R13=0x0000000000560040, R14=0x00007f28885f6408, R15=0x00007f27d8007620 > RIP=0x00007f2fd6a1a559, EFLAGS=0x0000000000010207, CSGSFS=0x0000000000000033, ERR=0x0000000000000006 > TRAPNO=0x000000000000000e > Instructions: (pc=0x00007f2fd6a1a559) > 0x00007f2fd6a1a539: 01 00 00 48 8b bc 24 08 01 00 00 4c 03 c7 48 b8 > 0x00007f2fd6a1a549: 00 00 00 00 00 00 00 00 4c 8b 8c 24 d8 00 00 00 > 0x00007f2fd6a1a559: 4e 89 0c 00 48 81 c4 30 01 00 00 5d 85 05 95 7b > 0x00007f2fd6a1a569: 5c 17 c3 48 8b 94 24 e8 00 00 00 48 8b b4 24 e0 This decodes to: 48 b8 00 00 00 00 00 00 00 00 movabs rax,0x0 4c 8b 8c 24 d8 00 00 00 mov r9,QWORD PTR [rsp+0xd8] 4e 89 0c 00 mov QWORD PTR [rax+r8*1],r9 <--- crash here 48 81 c4 30 01 00 00 add rsp,0x130 The prior store of literal zero to %rax is weird, is that a code root or a C1 patch going wrong? How reproducible is this? Are there specific steps to reproduce? Please try with -XX:+ShenandoahVerify and/or fastdebug builds. -- Thanks, -Aleksey From shade at redhat.com Wed Feb 5 16:48:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 5 Feb 2020 17:48:57 +0100 Subject: Shenandoah JDK 8 backport crashes when running Cassandra In-Reply-To: References: Message-ID: On 2/5/20 5:40 PM, Amir Hadadi wrote: > "Trying a bit more modern build would be a plus" - this is a build from 31/12/2019, by more modern > you mean a JDK 8 backport from 2020? Yeah, pick the latest JDK 8 backport nightly build: https://builds.shipilev.net/openjdk-shenandoah-jdk8/ > This library is handling the off heap > structure:?https://github.com/snazy/ohc/tree/develop/ohc-core/src/main/java/org/caffinitas/ohc Oh, okay. Let me try and run some unit tests from that library with Shenandoah. -- Thanks, -Aleksey From shade at redhat.com Thu Feb 6 12:34:49 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Feb 2020 13:34:49 +0100 Subject: [14u] RFR 8237223: Shenandoah: important flags should not be ergonomic for concurrent class unloading Message-ID: Please review this backport of: https://bugs.openjdk.java.net/browse/JDK-8237223 https://hg.openjdk.java.net/jdk/jdk/rev/d5c222f181b4 The VerifyOnExit block was added by JDK-8228818 in 15, so the original patch does not apply cleanly. 14u variant: diff -r 1c7a24611159 src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp Tue Jan 21 13:40:10 2020 +0100 +++ b/src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp Thu Feb 06 13:28:25 2020 +0100 @@ -29,15 +29,16 @@ #include "gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp" #include "logging/log.hpp" #include "logging/logTag.hpp" void ShenandoahNormalMode::initialize_flags() const { + if (ShenandoahConcurrentRoots::can_do_concurrent_class_unloading()) { + FLAG_SET_DEFAULT(ShenandoahSuspendibleWorkers, true); + } + SHENANDOAH_ERGO_ENABLE_FLAG(ExplicitGCInvokesConcurrent); SHENANDOAH_ERGO_ENABLE_FLAG(ShenandoahImplicitGCInvokesConcurrent); - if (ShenandoahConcurrentRoots::can_do_concurrent_class_unloading()) { - SHENANDOAH_ERGO_ENABLE_FLAG(ShenandoahSuspendibleWorkers); - } // Final configuration checks SHENANDOAH_CHECK_FLAG_SET(ShenandoahLoadRefBarrier); SHENANDOAH_CHECK_FLAG_SET(ShenandoahSATBBarrier); SHENANDOAH_CHECK_FLAG_SET(ShenandoahKeepAliveBarrier); Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Thu Feb 6 12:54:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Feb 2020 13:54:58 +0100 Subject: [11] Bulk backports to sh/jdk11 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200206/webrev.01/ This batch backports these simple fixes: [backport] 8237570: Shenandoah: cleanup uses of allocation/free threshold in static heuristics [backport] 8237586: Shenandoah: provide option to disable periodic GC [backport] 8238153: CTW: C2 (Shenandoah) compilation fails with "Unknown node in get_load_addr: CreateEx" [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware [backport] 8236851: Shenandoah: More details in Traversal GC event messages All apply cleanly. Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From zgu at redhat.com Thu Feb 6 13:30:29 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 6 Feb 2020 08:30:29 -0500 Subject: [14u] RFR 8237223: Shenandoah: important flags should not be ergonomic for concurrent class unloading In-Reply-To: References: Message-ID: <1b8dc04b-6356-fb70-dbb4-1d96e846781f@redhat.com> Looks good to me. Thanks, -Zhengyu On 2/6/20 7:34 AM, Aleksey Shipilev wrote: > Please review this backport of: > https://bugs.openjdk.java.net/browse/JDK-8237223 > https://hg.openjdk.java.net/jdk/jdk/rev/d5c222f181b4 > > The VerifyOnExit block was added by JDK-8228818 in 15, so the original patch does not apply cleanly. > > 14u variant: > > diff -r 1c7a24611159 src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp Tue Jan 21 13:40:10 2020 +0100 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahNormalMode.cpp Thu Feb 06 13:28:25 2020 +0100 > @@ -29,15 +29,16 @@ > #include "gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp" > #include "logging/log.hpp" > #include "logging/logTag.hpp" > > void ShenandoahNormalMode::initialize_flags() const { > + if (ShenandoahConcurrentRoots::can_do_concurrent_class_unloading()) { > + FLAG_SET_DEFAULT(ShenandoahSuspendibleWorkers, true); > + } > + > SHENANDOAH_ERGO_ENABLE_FLAG(ExplicitGCInvokesConcurrent); > SHENANDOAH_ERGO_ENABLE_FLAG(ShenandoahImplicitGCInvokesConcurrent); > - if (ShenandoahConcurrentRoots::can_do_concurrent_class_unloading()) { > - SHENANDOAH_ERGO_ENABLE_FLAG(ShenandoahSuspendibleWorkers); > - } > > // Final configuration checks > SHENANDOAH_CHECK_FLAG_SET(ShenandoahLoadRefBarrier); > SHENANDOAH_CHECK_FLAG_SET(ShenandoahSATBBarrier); > SHENANDOAH_CHECK_FLAG_SET(ShenandoahKeepAliveBarrier); > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Thu Feb 6 16:44:30 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 6 Feb 2020 17:44:30 +0100 Subject: [11] Bulk backports to sh/jdk11 In-Reply-To: References: Message-ID: <76598afd-003a-d468-2355-a5f75934b2f7@redhat.com> Hi Aleksey, > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200206/webrev.01/ > > This batch backports these simple fixes: > [backport] 8237570: Shenandoah: cleanup uses of allocation/free threshold in static heuristics > [backport] 8237586: Shenandoah: provide option to disable periodic GC > [backport] 8238153: CTW: C2 (Shenandoah) compilation fails with "Unknown node in get_load_addr: > CreateEx" > [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test > [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware > [backport] 8236851: Shenandoah: More details in Traversal GC event messages > > All apply cleanly. > > Testing: hotspot_gc_shenandoah {fastdebug, release} Looks good! Thank you! Roman From zgu at redhat.com Thu Feb 6 17:34:10 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 6 Feb 2020 12:34:10 -0500 Subject: [15] RFR 8238574: Shenandoah: Assertion failure due to missing null check Message-ID: Please review this small change that adds a null check before calling keep alive barrier to avoid assertion failure. Native barrier may return null for a not null oop, if it is dead. Bug: https://bugs.openjdk.java.net/browse/JDK-8238574 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8238574/webrev.00/ Test: hotspot_gc_shenandoah, vmTestbase_nsk_jdi where the problem was observed. Thanks, -Zhengyu From shade at redhat.com Thu Feb 6 17:36:51 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 06 Feb 2020 17:36:51 +0000 Subject: hg: shenandoah/jdk11: 6 new changesets Message-ID: <202002061736.016HaqjS016303@aojmv0008.oracle.com> Changeset: 0318bd570384 Author: shade Date: 2020-01-21 13:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/0318bd570384 [backport] 8237570: Shenandoah: cleanup uses of allocation/free threshold in static heuristics Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! test/hotspot/jtreg/gc/shenandoah/options/TestArgumentRanges.java Changeset: 03d93399c30a Author: shade Date: 2020-01-21 20:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/03d93399c30a [backport] 8237586: Shenandoah: provide option to disable periodic GC Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! test/hotspot/jtreg/gc/shenandoah/TestPeriodicGC.java Changeset: 44e3dcd3c8db Author: shade Date: 2020-01-29 14:34 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/44e3dcd3c8db [backport] 8238153: CTW: C2 (Shenandoah) compilation fails with "Unknown node in get_load_addr: CreateEx" Reviewed-by: roland, rkennke ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp Changeset: 4973161961fb Author: zgu Date: 2020-01-13 13:53 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/4973161961fb [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test Reviewed-by: shade ! test/hotspot/jtreg/gc/shenandoah/TestEvilSyncBug.java Changeset: 3de76a86710e Author: zgu Date: 2019-11-08 11:41 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/3de76a86710e [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: 28e83a06a3a1 Author: rkennke Date: 2020-01-10 12:42 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/28e83a06a3a1 [backport] 8236851: Shenandoah: More details in Traversal GC event messages Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp From shade at redhat.com Thu Feb 6 17:42:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 6 Feb 2020 18:42:44 +0100 Subject: [15] RFR 8238574: Shenandoah: Assertion failure due to missing null check In-Reply-To: References: Message-ID: <43248314-c8b1-d78a-5bff-415aaaa957cd@redhat.com> On 2/6/20 6:34 PM, Zhengyu Gu wrote: > Please review this small change that adds a null check before calling > keep alive barrier to avoid assertion failure. > > Native barrier may return null for a not null oop, if it is dead. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8238574 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8238574/webrev.00/ The patch looks good. But I have a broader question: are all other paths that use the returned value from LRB-native safe? E.g. calling from assembler/C1/C2? Thanks, -Aleksey From zgu at redhat.com Thu Feb 6 17:56:11 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 6 Feb 2020 12:56:11 -0500 Subject: [15] RFR 8238574: Shenandoah: Assertion failure due to missing null check In-Reply-To: <43248314-c8b1-d78a-5bff-415aaaa957cd@redhat.com> References: <43248314-c8b1-d78a-5bff-415aaaa957cd@redhat.com> Message-ID: On 2/6/20 12:42 PM, Aleksey Shipilev wrote: > On 2/6/20 6:34 PM, Zhengyu Gu wrote: >> Please review this small change that adds a null check before calling >> keep alive barrier to avoid assertion failure. >> >> Native barrier may return null for a not null oop, if it is dead. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8238574 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8238574/webrev.00/ > The patch looks good. > > But I have a broader question: are all other paths that use the returned value from LRB-native safe? > E.g. calling from assembler/C1/C2? In C1/C2, we just make runtime call to this implementation. -Zhengyu > > Thanks, > -Aleksey > From zgu at redhat.com Thu Feb 6 18:32:46 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 6 Feb 2020 13:32:46 -0500 Subject: [15] RFR 8238574: Shenandoah: Assertion failure due to missing null check In-Reply-To: References: <43248314-c8b1-d78a-5bff-415aaaa957cd@redhat.com> Message-ID: <5085eff3-c6b4-c4d7-e3d6-7928ff77561a@redhat.com> On 2/6/20 12:56 PM, Zhengyu Gu wrote: > > > On 2/6/20 12:42 PM, Aleksey Shipilev wrote: >> On 2/6/20 6:34 PM, Zhengyu Gu wrote: >>> Please review this small change that adds a null check before calling >>> keep alive barrier to avoid assertion failure. >>> >>> Native barrier may return null for a not null oop, if it is dead. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238574 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8238574/webrev.00/ >> The patch looks good. >> >> But I have a broader question: are all other paths that use the >> returned value from LRB-native safe? >> E.g. calling from assembler/C1/C2? > > In C1/C2, we just make runtime call to this implementation. Sorry, jump the gun to fast. I don't think I answered your question :-( C1/C2's pre-val barriers seem to have null check. Roman, could you confirm? Thanks, -Zhengyu > > -Zhengyu > >> >> Thanks, >> -Aleksey >> From rkennke at redhat.com Thu Feb 6 19:39:08 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 6 Feb 2020 20:39:08 +0100 Subject: [15] RFR 8238574: Shenandoah: Assertion failure due to missing null check In-Reply-To: <5085eff3-c6b4-c4d7-e3d6-7928ff77561a@redhat.com> References: <43248314-c8b1-d78a-5bff-415aaaa957cd@redhat.com> <5085eff3-c6b4-c4d7-e3d6-7928ff77561a@redhat.com> Message-ID: <028fc92b-b660-354f-1c4b-4a78bae8319a@redhat.com> Hi folks, >>>> Please review this small change that adds a null check before calling >>>> keep alive barrier to avoid assertion failure. >>>> >>>> Native barrier may return null for a not null oop, if it is dead. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238574 >>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8238574/webrev.00/ >>> The patch looks good. >>> >>> But I have a broader question: are all other paths that use the >>> returned value from LRB-native safe? >>> E.g. calling from assembler/C1/C2? >> >> In C1/C2, we just make runtime call to this implementation. > > Sorry, jump the gun to fast. I don't think I answered your question :-( > > C1/C2's pre-val barriers seem to have null check. Roman, could you confirm? Yes, I think this is correct. Thanks, Roman From shade at redhat.com Fri Feb 7 12:30:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 7 Feb 2020 13:30:27 +0100 Subject: [8] RFR: 2020-02-07, Bulk backports to sh/jdk8 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200207/ Some changes required quite a bit of adaptation, so please review carefully. List of changes: [backport] 8227327: Shenandoah: Faster and more parallel tests [backport] 8237570: Shenandoah: cleanup uses of allocation/free threshold in static heuristics [backport] 8237586: Shenandoah: provide option to disable periodic GC [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware [backport] 8236851: Shenandoah: More details in Traversal GC event messages [backport] 8236106: [TESTBUG] Shenandoah: Make TestThreadFailure more resilient [backport] 8235729: Shenandoah: Remove useless casting to non-constant [backport] 8233520: Shenandoah: do not sleep when thread is attaching [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically Testing: x86_64, hotspot_gc_shenandoah, fastdebug/release -- Thanks, -Aleksey From rkennke at redhat.com Fri Feb 7 13:07:50 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 7 Feb 2020 14:07:50 +0100 Subject: [8] RFR: 2020-02-07, Bulk backports to sh/jdk8 In-Reply-To: References: Message-ID: It looks good to me, thank you! Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200207/ > > Some changes required quite a bit of adaptation, so please review carefully. > > List of changes: > [backport] 8227327: Shenandoah: Faster and more parallel tests > [backport] 8237570: Shenandoah: cleanup uses of allocation/free threshold in static heuristics > [backport] 8237586: Shenandoah: provide option to disable periodic GC > [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test > [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware > [backport] 8236851: Shenandoah: More details in Traversal GC event messages > [backport] 8236106: [TESTBUG] Shenandoah: Make TestThreadFailure more resilient > [backport] 8235729: Shenandoah: Remove useless casting to non-constant > [backport] 8233520: Shenandoah: do not sleep when thread is attaching > [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically > > Testing: x86_64, hotspot_gc_shenandoah, fastdebug/release > From shade at redhat.com Sun Feb 9 18:23:52 2020 From: shade at redhat.com (shade at redhat.com) Date: Sun, 09 Feb 2020 18:23:52 +0000 Subject: hg: shenandoah/jdk8/hotspot: 10 new changesets Message-ID: <202002091823.019INrQU019863@aojmv0008.oracle.com> Changeset: ba4f0a8d23dc Author: shade Date: 2019-07-05 23:31 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ba4f0a8d23dc [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: 62c999b9263a Author: shade Date: 2020-01-21 13:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/62c999b9263a [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: 7a9bf9827a9f Author: shade Date: 2020-01-21 20:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7a9bf9827a9f [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: 6a20ec13caa8 Author: zgu Date: 2020-01-13 13:53 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6a20ec13caa8 [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test Reviewed-by: shade ! test/gc/shenandoah/TestEvilSyncBug.java Changeset: 36c42f7a94c2 Author: zgu Date: 2019-11-08 11:41 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/36c42f7a94c2 [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp Changeset: effaa06c0f93 Author: rkennke Date: 2020-01-10 12:42 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/effaa06c0f93 [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: d67769bf63ce Author: rkennke Date: 2019-12-17 18:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d67769bf63ce [backport] 8236106: [TESTBUG] Shenandoah: Make TestThreadFailure more resilient Reviewed-by: zgu ! test/gc/shenandoah/oom/TestThreadFailure.java Changeset: ed1dc6cce765 Author: rkennke Date: 2019-12-11 16:43 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ed1dc6cce765 [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: 7a69d5e47cab Author: shade Date: 2019-11-04 19:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7a69d5e47cab [backport] 8233520: Shenandoah: do not sleep when thread is attaching Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 6db8d75e4f46 Author: shade Date: 2019-11-01 16:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6db8d75e4f46 [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp From shade at redhat.com Mon Feb 10 08:35:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 10 Feb 2020 09:35:34 +0100 Subject: [8] RFR: Revert leftover changes in type.{cpp|hpp} Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/8u-type-revert/webrev.01/ Comparing to upstream, there is an awkward change in Type::make_oopptr. If we remove it, tests start to assert in need_barrier_impl. I prefer to work that around in Shenandoah code, rather than let it leak into the shared one. Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rwestrel at redhat.com Mon Feb 10 09:22:02 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 10 Feb 2020 10:22:02 +0100 Subject: [8] RFR: Revert leftover changes in type.{cpp|hpp} In-Reply-To: References: Message-ID: <877e0ussp1.fsf@redhat.com> > https://cr.openjdk.java.net/~shade/shenandoah/8u-type-revert/webrev.01/ Looks good. Roland. From rkennke at redhat.com Mon Feb 10 10:28:42 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 10 Feb 2020 11:28:42 +0100 Subject: [8] RFR: Revert leftover changes in type.{cpp|hpp} In-Reply-To: References: Message-ID: Yes, that looks good. How's that working in later versions? Roman > https://cr.openjdk.java.net/~shade/shenandoah/8u-type-revert/webrev.01/ > > Comparing to upstream, there is an awkward change in Type::make_oopptr. If we remove it, tests start > to assert in need_barrier_impl. I prefer to work that around in Shenandoah code, rather than let it > leak into the shared one. > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Mon Feb 10 13:01:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 10 Feb 2020 14:01:48 +0100 Subject: [8] RFR: Revert leftover changes in type.{cpp|hpp} In-Reply-To: References: Message-ID: <44b8d750-95f3-750b-cdde-320b5535c5c1@redhat.com> On 2/10/20 11:28 AM, Roman Kennke wrote: > How's that working in later versions? See the code comment. Later fixes changed it to the same thing we have. But we cannot risk it in 8u. -- Thanks, -Aleksey From rkennke at redhat.com Mon Feb 10 13:19:48 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 10 Feb 2020 14:19:48 +0100 Subject: [8] RFR: Revert leftover changes in type.{cpp|hpp} In-Reply-To: <44b8d750-95f3-750b-cdde-320b5535c5c1@redhat.com> References: <44b8d750-95f3-750b-cdde-320b5535c5c1@redhat.com> Message-ID: <47ad40e1-f933-9ffc-2ca7-cd63a1d5f4e5@redhat.com> >> How's that working in later versions? > > See the code comment. Later fixes changed it to the same thing we have. But we cannot risk it in 8u. Ok, great. Go! Roman From shade at redhat.com Mon Feb 10 16:10:20 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 10 Feb 2020 17:10:20 +0100 Subject: [8] RFR: Rectify JDK-8191227 workaround for Shenandoah Message-ID: <9a06daf8-4d1e-4685-1eb5-1f0711ab7b28@redhat.com> When we were developing 10, we came across the Trouble, and worked that around: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-November/004296.html With LRB in 8u and other fixes, this does not directly affect Shenandoah anymore. However, touching naked oops is still dangerous, and we would want to backport the whole change to 8u upstream: https://bugs.openjdk.java.net/browse/JDK-8191227 We have reverted the workaround in 11+ already in favor of JDK-8191227: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d82146d195fc Until that the backport happens in 8u, I think we want to reshape the workaround to do only the necessary things like JDK-8191227 does it. For example, I believe entering VM there is unnecessary and even harmful (for example for JVMCI entering there already in VM state!) for product builds. JDK-8191227 has some bugtail, I don't want to cherry-pick that directly. 8u webrev: https://cr.openjdk.java.net/~shade/shenandoah/8u-rectify-debugInfo/webrev.01/ Full diff against 8u would be: https://cr.openjdk.java.net/~shade/shenandoah/8u-rectify-debugInfo/8u-upstream.diff Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Mon Feb 10 16:20:12 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 10 Feb 2020 17:20:12 +0100 Subject: [8] RFR: Rectify JDK-8191227 workaround for Shenandoah In-Reply-To: <9a06daf8-4d1e-4685-1eb5-1f0711ab7b28@redhat.com> References: <9a06daf8-4d1e-4685-1eb5-1f0711ab7b28@redhat.com> Message-ID: <8130a356-eb98-72ab-43bc-b36aed277ee1@redhat.com> Yes, that looks much better. Thank you! Roman > When we were developing 10, we came across the Trouble, and worked that around: > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-November/004296.html > > With LRB in 8u and other fixes, this does not directly affect Shenandoah anymore. However, touching > naked oops is still dangerous, and we would want to backport the whole change to 8u upstream: > https://bugs.openjdk.java.net/browse/JDK-8191227 > > We have reverted the workaround in 11+ already in favor of JDK-8191227: > https://hg.openjdk.java.net/shenandoah/jdk11/rev/d82146d195fc > > Until that the backport happens in 8u, I think we want to reshape the workaround to do only the > necessary things like JDK-8191227 does it. For example, I believe entering VM there is unnecessary > and even harmful (for example for JVMCI entering there already in VM state!) for product builds. > JDK-8191227 has some bugtail, I don't want to cherry-pick that directly. > > 8u webrev: > https://cr.openjdk.java.net/~shade/shenandoah/8u-rectify-debugInfo/webrev.01/ > > Full diff against 8u would be: > https://cr.openjdk.java.net/~shade/shenandoah/8u-rectify-debugInfo/8u-upstream.diff > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Mon Feb 10 18:00:15 2020 From: shade at redhat.com (shade at redhat.com) Date: Mon, 10 Feb 2020 18:00:15 +0000 Subject: hg: shenandoah/jdk8/hotspot: 2 new changesets Message-ID: <202002101800.01AI0GjX024867@aojmv0008.oracle.com> Changeset: 35beac7c8b66 Author: shade Date: 2020-02-10 14:41 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/35beac7c8b66 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: 786d56b6de04 Author: shade Date: 2020-02-10 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/786d56b6de04 Rectify JDK-8191227 workaround for Shenandoah ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/debugInfo.hpp From shade at redhat.com Tue Feb 11 12:36:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 11 Feb 2020 13:36:27 +0100 Subject: [11] RFR: Fix ShenandoahBarrierSetC2::enqueue_useful_gc_barrier (part of JDK-8212611) In-Reply-To: <6f7660a4-286b-610d-3f7b-a93067e8171a@redhat.com> References: <6f7660a4-286b-610d-3f7b-a93067e8171a@redhat.com> Message-ID: <4183be94-cf89-478e-c83f-26a54f633a1e@redhat.com> On 9/6/19 4:58 PM, Aleksey Shipilev wrote: > There is a discrepancy between jdk/jdk and sh/jdk11 definition of BSC2::enqueue_useful_gc_barrier, > where one thing adds the node to the IGVN worklist [1], and another adds all users to it [2]. It was > introduced by JDK-8212611 [3], and we should consider backporting it to 11u. > > Meanwhile, sh/jdk11 x86_32 CTW fails without that patch: > > $ CONF=linux-x86-normal-server-fastdebug make run-test TEST_VM_OPTS="-XX:-TieredCompilation > -XX:+UseShenandoahGC" TEST=applications/ctw/modules/jdk_scripting_nashorn.java > > # > # Internal Error (/home/shade/trunks/shenandoah-jdk11/src/hotspot/share/opto/compile.cpp:2851), > pid=23210, tid=23220 > # assert(!ShenandoahBarrierSetC2::has_only_shenandoah_wb_pre_uses(addp)) failed: useless address > computation? > # Seeing exactly the same failure in sh/jdk11. > I believe the best course of action would be to pick up safer parts of JDK-8212611 to sh/jdk11: > https://cr.openjdk.java.net/~shade/shenandoah/11u-fix-bsc2-eugcb/webrev.01/ Eh. This got somehow reverted from sh/jdk11 during this merge: changeset: 53541:bc2d5a439bc2 parent: 53359:743587c28e0f parent: 53540:ae7ed8c70ecc user: shade date: Wed Oct 30 12:24:36 2019 +0100 summary: Merge The same webrev applies cleanly to sh/jdk11. > Testing: {x86_64, x86_32} CTW tests, {x86_64, x86_32} hotspot_gc_shenandoah (running) ...and passes the same testing. I am thinking to re-push this to sh/jdk11. The downside: it increases our upstream exposure until JDK-8212611 and dependent issues are in 11u. Thoughts? -- Thanks, -Aleksey From rkennke at redhat.com Tue Feb 11 15:38:38 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 11 Feb 2020 16:38:38 +0100 Subject: RFR: JDK-8238851: Shenandoah: C1: Resolve into registers of correct type Message-ID: In ShBSC1::ensure_in_register() we are blindly creating registers of type T_OBJECT, even though in some cases we actually need T_ADDRESS. This blows up when we verify oop registers: when the argument is of type T_OBJECT we perform extra checks that fail when the value in register is not actually an object. Bug: https://bugs.openjdk.java.net/browse/JDK-8238851 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01/ Testing: the provided testcase passes now. hotspot_gc_shenandoah Ok? Thanks, Roman From shade at redhat.com Tue Feb 11 16:18:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 11 Feb 2020 17:18:48 +0100 Subject: RFR: JDK-8238851: Shenandoah: C1: Resolve into registers of correct type In-Reply-To: References: Message-ID: On 2/11/20 4:38 PM, Roman Kennke wrote: > In ShBSC1::ensure_in_register() we are blindly creating registers of > type T_OBJECT, even though in some cases we actually need T_ADDRESS. > This blows up when we verify oop registers: when the argument is of type > T_OBJECT we perform extra checks that fail when the value in register is > not actually an object. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8238851 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01/ > Testing: the provided testcase passes now. hotspot_gc_shenandoah This path probably needs adjustment too: 167 #ifdef AARCH64 168 // AArch64 expects double-size register. 169 obj_reg = gen->new_pointer_register(); 170 #else -- Thanks, -Aleksey From rkennke at redhat.com Tue Feb 11 19:09:58 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 11 Feb 2020 20:09:58 +0100 Subject: RFR: JDK-8238851: Shenandoah: C1: Resolve into registers of correct type In-Reply-To: References: Message-ID: >> In ShBSC1::ensure_in_register() we are blindly creating registers of >> type T_OBJECT, even though in some cases we actually need T_ADDRESS. >> This blows up when we verify oop registers: when the argument is of type >> T_OBJECT we perform extra checks that fail when the value in register is >> not actually an object. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8238851 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01/ >> Testing: the provided testcase passes now. hotspot_gc_shenandoah > > This path probably needs adjustment too: > > 167 #ifdef AARCH64 > 168 // AArch64 expects double-size register. > 169 obj_reg = gen->new_pointer_register(); > 170 #else The provided test passes on aarch64 without any additional changes. I tried removing the block, hoping that the suggested change does perhaps make it unnecessary, but no. It's still needed. Further suggestions welcome. This whole thing kinda smells. Roman From zgu at redhat.com Tue Feb 11 20:49:35 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 11 Feb 2020 15:49:35 -0500 Subject: [Shenandoah 11u backport] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms Message-ID: I would like backport JDK-8229919 to Shenandoah 11u. http://cr.openjdk.java.net/~zgu/JDK-8229919/11u/webrev.00/ Test: hotspot_gc_shenandoah x86_32 on Linux Thanks, -Zhengyu From shade at redhat.com Wed Feb 12 09:10:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 10:10:23 +0100 Subject: RFR: JDK-8238851: Shenandoah: C1: Resolve into registers of correct type In-Reply-To: References: Message-ID: <80502580-be2e-7cc8-c0e8-e9a9d11adffc@redhat.com> On 2/11/20 8:09 PM, Roman Kennke wrote: >>> In ShBSC1::ensure_in_register() we are blindly creating registers of >>> type T_OBJECT, even though in some cases we actually need T_ADDRESS. >>> This blows up when we verify oop registers: when the argument is of type >>> T_OBJECT we perform extra checks that fail when the value in register is >>> not actually an object. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8238851 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01/ >>> Testing: the provided testcase passes now. hotspot_gc_shenandoah >> >> This path probably needs adjustment too: >> >> 167 #ifdef AARCH64 >> 168 // AArch64 expects double-size register. >> 169 obj_reg = gen->new_pointer_register(); >> 170 #else > > The provided test passes on aarch64 without any additional changes. > > I tried removing the block, hoping that the suggested change does > perhaps make it unnecessary, but no. It's still needed. Gaawh. The non-AARCH64 path still looks good, so we can push it in current form. We really need to figure out AARCH64 thingie, please file the follow-up RFR? -- Thanks, -Aleksey From zgu at redhat.com Wed Feb 12 13:53:22 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 12 Feb 2020 08:53:22 -0500 Subject: [Shenandoah 8u] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms Message-ID: I would like backport JDK-8229919 to Shenandoah 8u. The major difference between original patch and the backport is in tests. http://cr.openjdk.java.net/~zgu/JDK-8229919/8u/webrev.00/ Test: hotspot_gc_shenandoah x86_32 on Linux Thanks, -Zhengyu From rkennke at redhat.com Wed Feb 12 14:21:12 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 12 Feb 2020 15:21:12 +0100 Subject: RFR: JDK-8238851: Shenandoah: C1: Resolve into registers of correct type In-Reply-To: <80502580-be2e-7cc8-c0e8-e9a9d11adffc@redhat.com> References: <80502580-be2e-7cc8-c0e8-e9a9d11adffc@redhat.com> Message-ID: >>>> In ShBSC1::ensure_in_register() we are blindly creating registers of >>>> type T_OBJECT, even though in some cases we actually need T_ADDRESS. >>>> This blows up when we verify oop registers: when the argument is of type >>>> T_OBJECT we perform extra checks that fail when the value in register is >>>> not actually an object. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8238851 >>>> Webrev: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01/ >>>> Testing: the provided testcase passes now. hotspot_gc_shenandoah >>> >>> This path probably needs adjustment too: >>> >>> 167 #ifdef AARCH64 >>> 168 // AArch64 expects double-size register. >>> 169 obj_reg = gen->new_pointer_register(); >>> 170 #else >> >> The provided test passes on aarch64 without any additional changes. >> >> I tried removing the block, hoping that the suggested change does >> perhaps make it unnecessary, but no. It's still needed. > > Gaawh. The non-AARCH64 path still looks good, so we can push it in current form. We really need to > figure out AARCH64 thingie, please file the follow-up RFR? Turns out that we can fix this rather easily. It is the non-aarch64 path that is wrong though: Differential: http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01.diff/ Full: http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01/ This is also consistent with the implementations of LIRAssembler::leal() both x86 and aarch64. Testing: passes hotspot_gc_shenandoah both aarch64 and x86 Good? Roman From shade at redhat.com Wed Feb 12 14:25:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 12 Feb 2020 15:25:23 +0100 Subject: RFR: JDK-8238851: Shenandoah: C1: Resolve into registers of correct type In-Reply-To: References: <80502580-be2e-7cc8-c0e8-e9a9d11adffc@redhat.com> Message-ID: On 2/12/20 3:21 PM, Roman Kennke wrote: > Differential: > http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8238851/webrev.01/ > > This is also consistent with the implementations of LIRAssembler::leal() > both x86 and aarch64. Looks good. -- Thanks, -Aleksey From shade at redhat.com Thu Feb 13 10:13:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 13 Feb 2020 11:13:42 +0100 Subject: [11] RFR: Pick up 11.0.7+3 to sh/jdk11 Message-ID: <305eba4d-1343-af7a-0aab-aad56a29f339@redhat.com> Upstream published 11.0.7+3 tag. Let's pick it up to sh/jdk11. The merge is not trivial, but simple enough. Changeset list: https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.7%2b3/changesets.txt Merge changeset: https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.7%2b3/merge.changeset Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Thu Feb 13 11:32:59 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 13 Feb 2020 12:32:59 +0100 Subject: [11] RFR: Pick up 11.0.7+3 to sh/jdk11 In-Reply-To: <305eba4d-1343-af7a-0aab-aad56a29f339@redhat.com> References: <305eba4d-1343-af7a-0aab-aad56a29f339@redhat.com> Message-ID: <969be85a-c523-ce43-b4ad-f24ecf6a1ee7@redhat.com> Ok, looks good! Thank you! Roman On 2/13/20 11:13 AM, Aleksey Shipilev wrote: > Upstream published 11.0.7+3 tag. Let's pick it up to sh/jdk11. > > The merge is not trivial, but simple enough. Changeset list: > https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.7%2b3/changesets.txt > > Merge changeset: > https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.7%2b3/merge.changeset > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Thu Feb 13 11:29:23 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 13 Feb 2020 11:29:23 +0000 Subject: hg: shenandoah/jdk11: 33 new changesets Message-ID: <202002131129.01DBTQcW027656@aojmv0008.oracle.com> Changeset: 55a3b1de2737 Author: ccheung Date: 2019-07-12 08:40 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/55a3b1de2737 8226406: JVM fails to detect mismatched or corrupt CDS archive Summary: Check important archive header fields such as _jvm_ident before processing other fields. Reviewed-by: iklam, jiangli ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/prims/cdsoffsets.cpp ! test/hotspot/jtreg/runtime/appcds/SharedArchiveConsistency.java ! test/hotspot/jtreg/runtime/appcds/TestCommon.java Changeset: 145df6cd3046 Author: ccheung Date: 2019-07-17 08:34 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/145df6cd3046 8227646: [TESTBUG] appcds/SharedArchiveConsistency timed out Summary: Remove the FileChannel.force() calls. Reviewed-by: dcubed, iklam ! test/hotspot/jtreg/runtime/appcds/SharedArchiveConsistency.java Changeset: 67268881398e Author: weijun Date: 2019-10-29 09:34 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/67268881398e 8228969: 2019-09-28 public suffix list update Reviewed-by: mullan ! make/data/publicsuffixlist/VERSION ! make/data/publicsuffixlist/public_suffix_list.dat ! src/java.base/share/legal/public_suffix.md + test/jdk/sun/security/util/RegisteredDomain/ParseNames.java + test/jdk/sun/security/util/RegisteredDomain/tests.dat Changeset: c87999d80d6c Author: pchilanomate Date: 2019-07-30 17:31 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c87999d80d6c 8227528: TestAbortVMOnSafepointTimeout.java failed due to "RuntimeException: 'Safepoint sync time longer than' missing from stdout/stderr" Summary: Biased locking was disable for this test. Reviewed-by: dcubed, mdoerr, dholmes ! test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java Changeset: de05051a9dfe Author: hannesw Date: 2018-11-22 15:38 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/de05051a9dfe 8200432: javadoc fails with ClassCastException on {@link byte[]} Reviewed-by: jjg, sundar ! src/jdk.compiler/share/classes/com/sun/tools/doclint/Checker.java ! src/jdk.compiler/share/classes/com/sun/tools/doclint/resources/doclint.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTrees.java ! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTag.java + test/langtools/jdk/javadoc/doclet/testSeeTag/badref/Test.java ! test/langtools/tools/doclint/ReferenceTest.java ! test/langtools/tools/doclint/ReferenceTest.out Changeset: 3b07484b56e4 Author: roland Date: 2018-11-27 08:44 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/3b07484b56e4 8214344: C2: assert(con.basic_type() != T_ILLEGAL) failed: elembt=byte; loadbt=void; unsigned=0 Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/vectornode.hpp + test/hotspot/jtreg/compiler/loopopts/LoadVectorFromStableArray.java Changeset: 75fcad4f0447 Author: sviswanathan Date: 2019-11-26 19:19 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/75fcad4f0447 8234610: MaxVectorSize set wrongly when UseAVX=3 is specified after JDK-8221092 Reviewed-by: kvn, vlivanov ! src/hotspot/cpu/x86/vm_version_x86.cpp Changeset: 4c7199b77d81 Author: tnakamura Date: 2019-12-05 15:36 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/4c7199b77d81 8234386: [macos] NPE was thrown at expanding Choice from maximized frame Reviewed-by: serb ! src/java.desktop/share/classes/javax/swing/JPopupMenu.java + test/jdk/java/awt/Choice/ChoiceFromMaximizedFrame/ChoiceFromMaximizedFrame.java Changeset: 7777c88542fd Author: ngasson Date: 2019-03-22 03:04 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/7777c88542fd 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event" Reviewed-by: sspitsyn, dcubed, gadams ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l004/TestDescription.java Changeset: 97d9d5519024 Author: gadams Date: 2019-04-22 07:13 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/97d9d5519024 8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException Reviewed-by: cjplummer, jcbeyler ! test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove/remove004.java Changeset: ed077d50afef Author: mbaesken Date: 2020-01-27 17:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ed077d50afef 8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities Reviewed-by: clanger, mullan ! test/jdk/ProblemList.txt Changeset: aa57b7df15fc Author: weijun Date: 2020-02-04 13:15 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/aa57b7df15fc 8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Reviewed-by: wetmore, coffeys, mullan ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp Changeset: 3ddd96efac2a Author: roland Date: 2018-08-22 10:36 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/3ddd96efac2a 8209686: cleanup arguments to PhaseIdealLoop() constructor Reviewed-by: thartmann, kvn, pliden ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp Changeset: dd6da9bafb4a Author: mbaesken Date: 2020-01-08 08:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/dd6da9bafb4a 8236709: struct SwitchRange in HS violates C++ One Definition Rule Reviewed-by: dholmes, kbarrett ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp Changeset: cead343f537d Author: mbaesken Date: 2020-01-24 13:48 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/cead343f537d 8237819: s390x - remove unused pd_zero_to_words_large Reviewed-by: clanger, mdoerr ! src/hotspot/cpu/s390/copy_s390.hpp Changeset: a8dbe150c5dc Author: iklam Date: 2018-09-12 17:45 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/a8dbe150c5dc 8210523: runtime/appcds/cacheObject/DifferentHeapSizes.java crash Reviewed-by: jiangli, ccheung ! src/hotspot/share/classfile/compactHashtable.cpp ! src/hotspot/share/classfile/compactHashtable.inline.hpp ! src/hotspot/share/memory/filemap.cpp ! src/hotspot/share/memory/filemap.hpp ! src/hotspot/share/memory/heapShared.cpp ! src/hotspot/share/memory/heapShared.hpp ! src/hotspot/share/memory/heapShared.inline.hpp ! src/hotspot/share/memory/metaspaceShared.cpp ! test/hotspot/jtreg/runtime/appcds/cacheObject/DifferentHeapSizes.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 1ac2c2d8d002 Author: mbalao Date: 2020-02-08 00:12 -0300 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/1ac2c2d8d002 8237600: Test SunJSSEFIPSInit fails on Ubuntu Reviewed-by: shade ! test/jdk/sun/security/pkcs11/fips/SunJSSEFIPSInit.java Changeset: bc26354370e5 Author: aefimov Date: 2019-10-24 11:54 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/bc26354370e5 8232713: Update BCEL version to 6.3.1 in license file Reviewed-by: joehw ! src/java.xml/share/legal/bcel.md Changeset: e1b6631cbd2f Author: stuefe Date: 2019-10-31 07:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/e1b6631cbd2f 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit Reviewed-by: mdoerr, dlong, aph ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! test/hotspot/jtreg/compiler/intrinsics/klass/TestIsPrimitive.java Changeset: c759708d547e Author: coffeys Date: 2020-01-13 21:16 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c759708d547e 8234466: Class loading deadlock involving X509Factory#commitEvent() Reviewed-by: alanb, chegar, dfuchs ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/java.base/share/classes/jdk/internal/event/EventHelper.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilJarAccess.java + test/jdk/java/util/jar/JarFile/jarVerification/FooService.java + test/jdk/java/util/jar/JarFile/jarVerification/MultiProviderTest.java + test/jdk/java/util/jar/JarFile/jarVerification/MultiThreadLoad.java + test/jdk/java/util/jar/JarFile/jarVerification/logging.properties Changeset: 6095256b74a2 Author: redestad Date: 2020-01-20 14:24 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/6095256b74a2 8237508: Simplify JarFile.isInitializing Reviewed-by: dfuchs, coffeys, lancea ! src/java.base/share/classes/java/util/jar/JarFile.java ! src/java.base/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/java.base/share/classes/jdk/internal/misc/JavaUtilJarAccess.java Changeset: 39de0a772968 Author: ceisserer Date: 2020-01-14 15:19 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/39de0a772968 8235904: Infinite loop when rendering huge lines Reviewed-by: prr, kizune ! src/java.desktop/unix/classes/sun/java2d/xr/XRDrawLine.java + test/jdk/java/awt/Graphics/DrawLineTest.java Changeset: 3f41514eef8a Author: zgu Date: 2020-02-10 10:05 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/3f41514eef8a 8216472: (se) Stack overflow during selection operation leads to crash (win) Reviewed-by: alanb Contributed-by: akashche at redhat.com ! src/java.base/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c + test/jdk/java/nio/channels/Selector/StackOverflowTest.java Changeset: 402140a9cbff Author: clanger Date: 2020-01-10 15:38 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/402140a9cbff 8236488: Support for configure option --with-native-debug-symbols=internal is impossible on Windows Reviewed-by: erikj ! make/autoconf/jdk-options.m4 ! make/hotspot/test/GtestImage.gmk Changeset: 128739be82b6 Author: erikj Date: 2020-02-05 09:33 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/128739be82b6 8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary Reviewed-by: clanger, alanb, ihse ! make/test/JtregNativeJdk.gmk ! src/java.base/macosx/native/libjli/java_md_macosx.c + test/jdk/tools/launcher/JliLaunchTest.java + test/jdk/tools/launcher/exeJliLaunchTest.c ! test/lib/jdk/test/lib/Platform.java Changeset: fa28c8e95644 Author: mbaesken Date: 2019-12-10 16:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/fa28c8e95644 8235671: enhance print_rlimit_info in os_posix Reviewed-by: clanger, mdoerr ! src/hotspot/os/posix/os_posix.cpp Changeset: d2cf0f5cc7b2 Author: bpb Date: 2019-02-13 07:58 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d2cf0f5cc7b2 8218882: NET_Writev is declared, NET_WriteV is defined Reviewed-by: alanb, chegar ! src/java.base/aix/native/libnet/aix_close.c ! src/java.base/linux/native/libnet/linux_close.c ! src/java.base/macosx/native/libnet/bsd_close.c ! src/java.base/solaris/native/libnet/solaris_close.c ! src/java.base/unix/native/libnet/net_util_md.h Changeset: ef2935a942a2 Author: mbaesken Date: 2019-11-20 14:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ef2935a942a2 8234501: remove obsolete NET_ReadV Reviewed-by: alanb, vtewari ! src/java.base/aix/native/libnet/aix_close.c ! src/java.base/linux/native/libnet/linux_close.c ! src/java.base/macosx/native/libnet/bsd_close.c ! src/java.base/solaris/native/libnet/solaris_close.c ! src/java.base/unix/native/libnet/net_util_md.h Changeset: e868302b0772 Author: mgronlun Date: 2020-02-03 20:27 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/e868302b0772 8230400: Missing constant pool entry for a method in stacktrace Reviewed-by: egahlin ! src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp ! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java Changeset: f2d8162261ae Author: erikj Date: 2018-11-16 08:25 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/f2d8162261ae 8213906: Update arm devkits with libXrandr headers Reviewed-by: tbell, prr ! make/conf/jib-profiles.js Changeset: fcbb2d301538 Author: clanger Date: 2020-02-13 07:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/fcbb2d301538 Added tag jdk-11.0.7+3 for changeset f2d8162261ae ! .hgtags Changeset: 7226495a5d64 Author: shade Date: 2020-02-13 11:08 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/7226495a5d64 Merge ! .hgtags ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp ! src/hotspot/cpu/sparc/c1_LIRAssembler_sparc.cpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/gc/z/c2/zBarrierSetC2.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp Changeset: 5a679b2e0988 Author: shade Date: 2020-02-13 11:08 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/5a679b2e0988 Added tag shenandoah-jdk-11.0.7+3 for changeset 7226495a5d64 ! .hgtags From rkennke at redhat.com Fri Feb 14 19:00:41 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 14 Feb 2020 20:00:41 +0100 Subject: RFR: JDK-8239081: Shenandoah: Consolidate C1 LRB and native barriers Message-ID: This is a fall-out from the recent Lucene debugging session. Currently, when emitting IN_NATIVE LRB in C1, we generate a simple runtime call directly in LIR. It'd arguably be more straightforward and maintainable to simply re-use what we do for regular LRB, with the only exception to call into a different runtime endpoint from the stub. It might also be more efficient because it checks heap-stable before calling into runtime. If we ever have to backport C1 IN_NATIVE barriers (JDK-8226695) to 11u (although, we should not strictly need native barriers there right now), it also means we can skip backporting JDK-8226822, that would no longer be needed. Bug: https://bugs.openjdk.java.net/browse/JDK-8239081 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.00/ Testing: hotspot_gc_shenandoah (x86_64, x86_32 and aarch64) Can I please get a review? Thanks, Roman From rkennke at redhat.com Fri Feb 14 19:29:34 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 14 Feb 2020 20:29:34 +0100 Subject: RFR: JDK-8237780: Shenandoah: More reliable nmethod verification Message-ID: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> This is another fallout from the Lucene debugging sessions :-) Our nmethod verification has a number of problems: - the assert(oops->length() == oop_count(), "Must match") is too too strict. Weirdly, while we are registering an nmethod in one thread (under CodeCache_lock), another thread can already patch the same nmethod (under Patching_lock). Which can throw off the countings. - We need to skip Universe::non_oop_word() because that what standard oop iterator would do too. It's fixed by: 1. counting actual oops, skipping Universe::non_oop_word() instead of comparing with oop_count() 2. relaxing the assert from == to >= I've also added a sanity check: + assert(nm == data->nm(), "must be same nmethod"); I've also left in some debug-output but under #ifdef ASSERT_DISABLED. I found that very useful and wouldn't want to throw it away. All of this has proven to be useful (if only to exclude the possibility that we mess up something in handling Nmethods). Bug: https://bugs.openjdk.java.net/browse/JDK-8237780 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.00/ Testing: provided testcase passes now (failed before). hotspot_gc_shenandoah is fine Can I please get a review? Thanks, Roman From shade at redhat.com Fri Feb 14 21:18:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Feb 2020 22:18:11 +0100 Subject: RFR: JDK-8237780: Shenandoah: More reliable nmethod verification In-Reply-To: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> References: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> Message-ID: <958d35c7-1dfd-39aa-6139-80c794af5791@redhat.com> On 2/14/20 8:29 PM, Roman Kennke wrote: > I've also left in some debug-output but under #ifdef ASSERT_DISABLED. I > found that very useful and wouldn't want to throw it away. I think the proper way to do this is: #if 0 // Helpful for debugging ...but then I wonder, why not turn it into the actual fastdebug diagnostics? Our verifier/asserts very helpfully include a lot of debugging info into hs_err when asserts fail. Surely if we are chasing a very rare bug, it would be more convenient for hs_err to include that right away, not require us recompile the VM. > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.00/ *) Looks like you can just initialize "int count = _oop_count" and skip increments in the first loop. *) Capitalization in "Must", to match the style of other asserts: 305 assert(nm == data->nm(), "must be same nmethod"); *) assert(false, ...) is probably just fatal(...) -- Thanks, -Aleksey From shade at redhat.com Fri Feb 14 21:23:30 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 14 Feb 2020 22:23:30 +0100 Subject: RFR: JDK-8239081: Shenandoah: Consolidate C1 LRB and native barriers In-Reply-To: References: Message-ID: <83a0a264-f958-6921-0ed7-7859bfe9505f@redhat.com> On 2/14/20 8:00 PM, Roman Kennke wrote: > https://bugs.openjdk.java.net/browse/JDK-8239081 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.00/ Only some stylistic nits: *) I believe the convention is to name these boolean arguments "is_native"? *) C1ShenandoahLoadReferenceBarrierCodeGenClosure::_native should probably be const? -- Thanks, -Aleksey From rkennke at redhat.com Sat Feb 15 12:35:10 2020 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 15 Feb 2020 13:35:10 +0100 Subject: RFR: JDK-8239081: Shenandoah: Consolidate C1 LRB and native barriers In-Reply-To: <83a0a264-f958-6921-0ed7-7859bfe9505f@redhat.com> References: <83a0a264-f958-6921-0ed7-7859bfe9505f@redhat.com> Message-ID: <3b4e78f3-a82c-2801-9d35-292ac18e6907@redhat.com> >> https://bugs.openjdk.java.net/browse/JDK-8239081 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.00/ > > Only some stylistic nits: > > *) I believe the convention is to name these boolean arguments "is_native"? > > *) C1ShenandoahLoadReferenceBarrierCodeGenClosure::_native should probably be const? Right, good points! Both fixed here: http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.01/ Good now? Thanks for reviewing! Roman From shade at redhat.com Mon Feb 17 08:12:18 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 09:12:18 +0100 Subject: RFR: JDK-8239081: Shenandoah: Consolidate C1 LRB and native barriers In-Reply-To: <3b4e78f3-a82c-2801-9d35-292ac18e6907@redhat.com> References: <83a0a264-f958-6921-0ed7-7859bfe9505f@redhat.com> <3b4e78f3-a82c-2801-9d35-292ac18e6907@redhat.com> Message-ID: <3c5f8917-41f8-b312-4f30-6a9c137ed83b@redhat.com> On 2/15/20 1:35 PM, Roman Kennke wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8239081 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.00/ >> >> Only some stylistic nits: >> >> *) I believe the convention is to name these boolean arguments "is_native"? >> >> *) C1ShenandoahLoadReferenceBarrierCodeGenClosure::_native should probably be const? > > Right, good points! Both fixed here: > > http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.01/ I think variables and fields should be "is_native" too. Here: 216 bool native = ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type); 217 tmp = load_reference_barrier(gen, tmp, access.resolved_addr(), native); ...and here: 255 class C1ShenandoahLoadReferenceBarrierCodeGenClosure : public StubAssemblerCodeGenClosure { 256 private: 257 const bool _native; ...and here: 89 class ShenandoahLoadReferenceBarrierStub: public CodeStub { ... 97 bool _native; ...and probably somewhere else too? -- Thanks, -Aleksey From rkennke at redhat.com Mon Feb 17 11:49:48 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 17 Feb 2020 12:49:48 +0100 Subject: RFR: JDK-8239081: Shenandoah: Consolidate C1 LRB and native barriers In-Reply-To: <3c5f8917-41f8-b312-4f30-6a9c137ed83b@redhat.com> References: <83a0a264-f958-6921-0ed7-7859bfe9505f@redhat.com> <3b4e78f3-a82c-2801-9d35-292ac18e6907@redhat.com> <3c5f8917-41f8-b312-4f30-6a9c137ed83b@redhat.com> Message-ID: <50043d72-86ff-df50-18e0-48b9f0a0bf0e@redhat.com> Hi Aleksey, >>>> https://bugs.openjdk.java.net/browse/JDK-8239081 >>>> Webrev: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.00/ >>> >>> Only some stylistic nits: >>> >>> *) I believe the convention is to name these boolean arguments "is_native"? >>> >>> *) C1ShenandoahLoadReferenceBarrierCodeGenClosure::_native should probably be const? >> >> Right, good points! Both fixed here: >> >> http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.01/ > > I think variables and fields should be "is_native" too. > > Here: > > 216 bool native = ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type); > 217 tmp = load_reference_barrier(gen, tmp, access.resolved_addr(), native); > > ...and here: > > 255 class C1ShenandoahLoadReferenceBarrierCodeGenClosure : public StubAssemblerCodeGenClosure { > 256 private: > 257 const bool _native; > > ...and here: > > 89 class ShenandoahLoadReferenceBarrierStub: public CodeStub { > ... > 97 bool _native; > > ...and probably somewhere else too? Riiiiight.: http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.02/ (Note: where am I coming from? Java conventions for boolean properties where field is $property, getter is is$Property(), setter is set$Property().) Better now? Roman From shade at redhat.com Mon Feb 17 11:53:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 12:53:21 +0100 Subject: RFR: JDK-8239081: Shenandoah: Consolidate C1 LRB and native barriers In-Reply-To: <50043d72-86ff-df50-18e0-48b9f0a0bf0e@redhat.com> References: <83a0a264-f958-6921-0ed7-7859bfe9505f@redhat.com> <3b4e78f3-a82c-2801-9d35-292ac18e6907@redhat.com> <3c5f8917-41f8-b312-4f30-6a9c137ed83b@redhat.com> <50043d72-86ff-df50-18e0-48b9f0a0bf0e@redhat.com> Message-ID: On 2/17/20 12:49 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8239081/webrev.02/ Looks good. -- Thanks, -Aleksey From rkennke at redhat.com Mon Feb 17 12:13:03 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 17 Feb 2020 13:13:03 +0100 Subject: RFR: JDK-8237780: Shenandoah: More reliable nmethod verification In-Reply-To: <958d35c7-1dfd-39aa-6139-80c794af5791@redhat.com> References: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> <958d35c7-1dfd-39aa-6139-80c794af5791@redhat.com> Message-ID: Hi Aleksey, >> I've also left in some debug-output but under #ifdef ASSERT_DISABLED. I >> found that very useful and wouldn't want to throw it away. > > I think the proper way to do this is: > > #if 0 // Helpful for debugging > > ...but then I wonder, why not turn it into the actual fastdebug diagnostics? Our verifier/asserts > very helpfully include a lot of debugging info into hs_err when asserts fail. Surely if we are > chasing a very rare bug, it would be more convenient for hs_err to include that right away, not > require us recompile the VM. Right, let's leave it there for diagnostics. >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.00/ > > *) Looks like you can just initialize "int count = _oop_count" and skip increments in the first loop. Right. > *) Capitalization in "Must", to match the style of other asserts: > > 305 assert(nm == data->nm(), "must be same nmethod"); Ok. > *) assert(false, ...) is probably just fatal(...) Ok. http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.01/ Good now? Thanks, Roman From shade at redhat.com Mon Feb 17 12:18:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 13:18:05 +0100 Subject: RFR: JDK-8237780: Shenandoah: More reliable nmethod verification In-Reply-To: References: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> <958d35c7-1dfd-39aa-6139-80c794af5791@redhat.com> Message-ID: On 2/17/20 1:13 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.01/ This is fine. Although I would probably be open for storing that diagnostics into stringStream (see how ShenandoahAsserts::print_failure does it), and putting it into the fatal message itself. Pros: customers would hand over hs_errs to us with the relevant diagnostics. Cons: we can overflow the stringStream and truncate parts of the data. Your call. -- Thanks, -Aleksey From rkennke at redhat.com Mon Feb 17 12:34:20 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 17 Feb 2020 13:34:20 +0100 Subject: RFR: JDK-8237780: Shenandoah: More reliable nmethod verification In-Reply-To: References: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> <958d35c7-1dfd-39aa-6139-80c794af5791@redhat.com> Message-ID: >> http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.01/ > > This is fine. > > Although I would probably be open for storing that diagnostics into stringStream (see how > ShenandoahAsserts::print_failure does it), and putting it into the fatal message itself. Pros: > customers would hand over hs_errs to us with the relevant diagnostics. Cons: we can overflow the > stringStream and truncate parts of the data. Your call. Ok, let's do that then: http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.02/ Good? Roman From zgu at redhat.com Mon Feb 17 14:03:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 17 Feb 2020 09:03:28 -0500 Subject: RFR: JDK-8237780: Shenandoah: More reliable nmethod verification In-Reply-To: References: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> <958d35c7-1dfd-39aa-6139-80c794af5791@redhat.com> Message-ID: <7850613d-3a9f-cece-9a1a-46b4e6823c7f@redhat.com> On 2/17/20 7:34 AM, Roman Kennke wrote: >>> http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.01/ >> >> This is fine. >> >> Although I would probably be open for storing that diagnostics into stringStream (see how >> ShenandoahAsserts::print_failure does it), and putting it into the fatal message itself. Pros: >> customers would hand over hs_errs to us with the relevant diagnostics. Cons: we can overflow the >> stringStream and truncate parts of the data. Your call. > > > Ok, let's do that then: > > http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.02/ > > Good? assert_same_oops() itself is assert only (has NOT_DEBUG_RETURN in definition), does not need nested ifdef ASSERT ... -Zhengyu > > Roman > From rkennke at redhat.com Mon Feb 17 15:27:05 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 17 Feb 2020 16:27:05 +0100 Subject: RFR: JDK-8237780: Shenandoah: More reliable nmethod verification In-Reply-To: <7850613d-3a9f-cece-9a1a-46b4e6823c7f@redhat.com> References: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> <958d35c7-1dfd-39aa-6139-80c794af5791@redhat.com> <7850613d-3a9f-cece-9a1a-46b4e6823c7f@redhat.com> Message-ID: <5f4bc613-bb6c-7262-934f-5ddac38d3b24@redhat.com> >>>> http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.01/ >>> >>> This is fine. >>> >>> Although I would probably be open for storing that diagnostics into >>> stringStream (see how >>> ShenandoahAsserts::print_failure does it), and putting it into the >>> fatal message itself. Pros: >>> customers would hand over hs_errs to us with the relevant >>> diagnostics. Cons: we can overflow the >>> stringStream and truncate parts of the data. Your call. >> >> >> Ok, let's do that then: >> >> http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.02/ >> >> Good? > > assert_same_oops() itself is assert only (has NOT_DEBUG_RETURN in > definition), does not need nested ifdef ASSERT ... Right! Very good catch! http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.03/ Good now? Thanks for reviewing! Roman From kirill at korins.ky Mon Feb 17 14:59:41 2020 From: kirill at korins.ky (Kirill A. Korinsky) Date: Mon, 17 Feb 2020 15:59:41 +0100 Subject: Probably a bug Message-ID: Good day, I'd like to ask for advice because it looks like I've discovered something that might be related to Shenandoah bug. I haven't got any proof that it is inside Shenandoah, nor a simple test case to reproduce it. It appears inside Akka and you can read my hunting with Akka team here: https://github.com/akka/akka/issues/28601 As summary: - it appears as infinite loop inside Akka queue that is lock-free linked-queue that's implemented via getObjectVolatile(), getAndSet() and few more atomic/unsafe calls. - if I've enabled any debugging such as XX:+ShenandoahVerify the bug is disappear => I can't provide any hs_err_log :( - it exists on OpenJDK-8 from fedora 31 and at shipilev/openjdk-shenandoah:8-fastdebug - it is very difficult to achieve and it is very fragile. In real life, it appears only at one and bigger cluster, at my synthetic test case it requires to bootstrap an application and uses the unreachable Akka system - to achieve this bug I should have a lot of garbage inside heap that produced by bootstrapping an application when it builds its index. The index has size 0,5gb..1gb (and the heap is 2gb) and the size depends on DB that is continuously updating, and the bug is achievable at any possibly size of the index. - if I switch to G1 for example it disappears. Right now I have two possible sources of this bug: - very strange race condition inside Akka. - a bug inside Shenandoah that is related to the missed barrier or deeper. To eliminate or confirm Shenandoah related possibility I need some advice on how to do it because I can't prepare easy to reproduce code :( -- wbr, Kirill From gnu.andrew at redhat.com Mon Feb 17 19:41:41 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 17 Feb 2020 19:41:41 +0000 Subject: [RFR] [8u] 8u252-b02 Upstream Sync Message-ID: <2b0627a8-f40f-2c80-b190-3d546eb13c97@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b02: - S7143743: Potential memory leak with zip provider - S8033215: clang: node.cpp:284 IDX_INIT macro use uninitialized field _out - S8143849: Integrate Marlin renderer per JEP 265 - S8146792: Predicate moved after partial peel may lead to broken graph - S8193255: Root Certificates should be stored in text format and assembled at build time - S8232154: Update Mesa 3-D Headers to version 19.2.1 - S8233995: java.vm.vendor (and potentially other properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8 - S8235142: JDK-8193255 backport broke bootstrap with JDK 10 Main issue of note: None, clean merge diffstat for root b/.hgtags | 1 b/THIRD_PARTY_README | 122 +++++++++++++++++++++++++++++-- b/common/autoconf/generated-configure.sh | 4 - b/common/autoconf/jdk-options.m4 | 2 4 files changed, 117 insertions(+), 12 deletions(-) diffstat for corba b/.hgtags | 1 b/THIRD_PARTY_README | 122 ++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 116 insertions(+), 7 deletions(-) diffstat for jaxp b/.hgtags | 1 b/THIRD_PARTY_README | 122 ++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 116 insertions(+), 7 deletions(-) diffstat for jaxws b/.hgtags | 1 b/THIRD_PARTY_README | 122 ++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 116 insertions(+), 7 deletions(-) diffstat for langtools b/.hgtags | 1 b/THIRD_PARTY_README | 122 ++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 116 insertions(+), 7 deletions(-) diffstat for nashorn b/.hgtags | 1 b/THIRD_PARTY_README | 122 ++++++++++++++++++++++++++++++++++++++++++++++++--- 2 files changed, 116 insertions(+), 7 deletions(-) diffstat for jdk b/.hgtags | 1 b/make/CopyFiles.gmk | 8 b/make/GenerateData.gmk | 16 b/make/Tools.gmk | 5 b/make/data/cacerts/README | 10 b/make/data/cacerts/actalisauthenticationrootca | 40 b/make/data/cacerts/addtrustclass1ca | 31 b/make/data/cacerts/addtrustexternalca | 32 b/make/data/cacerts/addtrustqualifiedca | 32 b/make/data/cacerts/affirmtrustcommercialca | 27 b/make/data/cacerts/affirmtrustnetworkingca | 27 b/make/data/cacerts/affirmtrustpremiumca | 38 b/make/data/cacerts/affirmtrustpremiumeccca | 20 b/make/data/cacerts/baltimorecybertrustca | 28 b/make/data/cacerts/buypassclass2ca | 38 b/make/data/cacerts/buypassclass3ca | 38 b/make/data/cacerts/camerfirmachambersca | 49 b/make/data/cacerts/camerfirmachamberscommerceca | 35 b/make/data/cacerts/camerfirmachambersignca | 48 b/make/data/cacerts/certumca | 26 b/make/data/cacerts/certumtrustednetworkca | 29 b/make/data/cacerts/chunghwaepkirootca | 40 b/make/data/cacerts/comodoaaaca | 32 b/make/data/cacerts/comodoeccca | 23 b/make/data/cacerts/comodorsaca | 41 b/make/data/cacerts/digicertassuredidg2 | 29 b/make/data/cacerts/digicertassuredidg3 | 22 b/make/data/cacerts/digicertassuredidrootca | 29 b/make/data/cacerts/digicertglobalrootca | 29 b/make/data/cacerts/digicertglobalrootg2 | 29 b/make/data/cacerts/digicertglobalrootg3 | 22 b/make/data/cacerts/digicerthighassuranceevrootca | 30 b/make/data/cacerts/digicerttrustedrootg4 | 39 b/make/data/cacerts/dtrustclass3ca2 | 32 b/make/data/cacerts/dtrustclass3ca2ev | 32 b/make/data/cacerts/entrust2048ca | 32 b/make/data/cacerts/entrustevca | 34 b/make/data/cacerts/entrustrootcaec1 | 25 b/make/data/cacerts/entrustrootcag2 | 32 b/make/data/cacerts/geotrustglobalca | 27 b/make/data/cacerts/geotrustprimaryca | 28 b/make/data/cacerts/geotrustprimarycag2 | 24 b/make/data/cacerts/geotrustprimarycag3 | 31 b/make/data/cacerts/geotrustuniversalca | 38 b/make/data/cacerts/globalsignca | 28 b/make/data/cacerts/globalsigneccrootcar4 | 20 b/make/data/cacerts/globalsigneccrootcar5 | 21 b/make/data/cacerts/globalsignr2ca | 29 b/make/data/cacerts/globalsignr3ca | 28 b/make/data/cacerts/globalsignrootcar6 | 39 b/make/data/cacerts/godaddyclass2ca | 31 b/make/data/cacerts/godaddyrootg2ca | 30 b/make/data/cacerts/identrustcommercial | 38 b/make/data/cacerts/identrustdstx3 | 27 b/make/data/cacerts/identrustpublicca | 38 b/make/data/cacerts/keynectisrootca | 30 b/make/data/cacerts/letsencryptisrgx1 | 38 b/make/data/cacerts/luxtrustglobalrootca | 28 b/make/data/cacerts/quovadisrootca | 41 b/make/data/cacerts/quovadisrootca1g3 | 38 b/make/data/cacerts/quovadisrootca2 | 40 b/make/data/cacerts/quovadisrootca2g3 | 38 b/make/data/cacerts/quovadisrootca3 | 45 b/make/data/cacerts/quovadisrootca3g3 | 38 b/make/data/cacerts/secomscrootca1 | 27 b/make/data/cacerts/secomscrootca2 | 28 b/make/data/cacerts/securetrustca | 29 b/make/data/cacerts/soneraclass2ca | 26 b/make/data/cacerts/starfieldclass2ca | 31 b/make/data/cacerts/starfieldrootg2ca | 30 b/make/data/cacerts/starfieldservicesrootg2ca | 31 b/make/data/cacerts/swisssigngoldg2ca | 40 b/make/data/cacerts/swisssignplatinumg2ca | 40 b/make/data/cacerts/swisssignsilverg2ca | 40 b/make/data/cacerts/teliasonerarootcav1 | 37 b/make/data/cacerts/thawtepremiumserverca | 27 b/make/data/cacerts/thawteprimaryrootca | 32 b/make/data/cacerts/thawteprimaryrootcag2 | 23 b/make/data/cacerts/thawteprimaryrootcag3 | 32 b/make/data/cacerts/ttelesecglobalrootclass2ca | 30 b/make/data/cacerts/ttelesecglobalrootclass3ca | 30 b/make/data/cacerts/usertrusteccca | 23 b/make/data/cacerts/usertrustrsaca | 41 b/make/data/cacerts/utnuserfirstobjectca | 33 b/make/data/cacerts/verisignclass2g2ca | 26 b/make/data/cacerts/verisignclass3ca | 21 b/make/data/cacerts/verisignclass3g2ca | 26 b/make/data/cacerts/verisignclass3g3ca | 31 b/make/data/cacerts/verisignclass3g4ca | 28 b/make/data/cacerts/verisignclass3g5ca | 35 b/make/data/cacerts/verisigntsaca | 24 b/make/data/cacerts/verisignuniversalrootca | 35 b/make/data/cacerts/xrampglobalca | 32 b/make/src/classes/build/tools/generatecacerts/GenerateCacerts.java | 62 b/src/share/classes/sun/java2d/marlin/ArrayCache.java | 216 + b/src/share/classes/sun/java2d/marlin/ByteArrayCache.java | 151 b/src/share/classes/sun/java2d/marlin/CollinearSimplifier.java | 155 + b/src/share/classes/sun/java2d/marlin/Curve.java | 306 + b/src/share/classes/sun/java2d/marlin/Dasher.java | 702 ++++ b/src/share/classes/sun/java2d/marlin/FloatArrayCache.java | 152 b/src/share/classes/sun/java2d/marlin/FloatMath.java | 213 + b/src/share/classes/sun/java2d/marlin/Helpers.java | 441 ++ b/src/share/classes/sun/java2d/marlin/IntArrayCache.java | 151 b/src/share/classes/sun/java2d/marlin/MarlinCache.java | 676 ++++ b/src/share/classes/sun/java2d/marlin/MarlinConst.java | 121 b/src/share/classes/sun/java2d/marlin/MarlinProperties.java | 181 + b/src/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java | 1064 ++++++ b/src/share/classes/sun/java2d/marlin/MarlinTileGenerator.java | 465 +++ b/src/share/classes/sun/java2d/marlin/MarlinUtils.java | 104 b/src/share/classes/sun/java2d/marlin/MergeSort.java | 177 + b/src/share/classes/sun/java2d/marlin/OffHeapArray.java | 166 + b/src/share/classes/sun/java2d/marlin/Renderer.java | 1546 ++++++++++ b/src/share/classes/sun/java2d/marlin/RendererContext.java | 471 +++ b/src/share/classes/sun/java2d/marlin/RendererStats.java | 319 ++ b/src/share/classes/sun/java2d/marlin/Stroker.java | 1388 ++++++++ b/src/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java | 507 +++ b/src/share/classes/sun/java2d/marlin/Version.java | 39 b/src/share/classes/sun/java2d/marlin/stats/Histogram.java | 102 b/src/share/classes/sun/java2d/marlin/stats/Monitor.java | 53 b/src/share/classes/sun/java2d/marlin/stats/StatLong.java | 97 b/src/share/classes/sun/java2d/pipe/AAShapePipe.java | 131 b/src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine | 3 b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java | 10 b/src/solaris/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine | 3 b/test/sun/java2d/marlin/CeilAndFloorTests.java | 249 + b/test/sun/java2d/marlin/CrashTest.java | 289 + 126 files changed, 13485 insertions(+), 56 deletions(-) diffstat for hotspot b/.hgtags | 1 b/THIRD_PARTY_README | 122 ++++- b/make/windows/build.make | 2 b/make/windows/makefiles/compile.make | 2 b/make/windows/makefiles/defs.make | 9 b/make/windows/makefiles/vm.make | 12 b/src/share/vm/opto/loopPredicate.cpp | 26 + b/src/share/vm/opto/node.cpp | 8 b/test/compiler/loopopts/BadPredicateAfterPartialPeel.java | 312 +++++++++++++ 9 files changed, 480 insertions(+), 14 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Mon Feb 17 19:47:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Feb 2020 20:47:57 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b02 Upstream Sync In-Reply-To: <2b0627a8-f40f-2c80-b190-3d546eb13c97@redhat.com> References: <2b0627a8-f40f-2c80-b190-3d546eb13c97@redhat.com> Message-ID: <2966ee91-bc0e-8b83-a8e7-146ac785afa3@redhat.com> On 2/17/20 8:41 PM, Andrew John Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/ > > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/jaxws/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/jdk/merge.changeset Huge Marlin integration. Seems fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b02/root/merge.changeset Looks good. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From zgu at redhat.com Tue Feb 18 12:54:32 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 18 Feb 2020 07:54:32 -0500 Subject: RFR: JDK-8237780: Shenandoah: More reliable nmethod verification In-Reply-To: <5f4bc613-bb6c-7262-934f-5ddac38d3b24@redhat.com> References: <751cd87f-38e3-cd2f-43fc-f2ef95b41a50@redhat.com> <958d35c7-1dfd-39aa-6139-80c794af5791@redhat.com> <7850613d-3a9f-cece-9a1a-46b4e6823c7f@redhat.com> <5f4bc613-bb6c-7262-934f-5ddac38d3b24@redhat.com> Message-ID: <0da39bd5-8fde-b010-0c19-8973489b6abb@redhat.com> On 2/17/20 10:27 AM, Roman Kennke wrote: >>>>> http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.01/ >>>> >>>> This is fine. >>>> >>>> Although I would probably be open for storing that diagnostics into >>>> stringStream (see how >>>> ShenandoahAsserts::print_failure does it), and putting it into the >>>> fatal message itself. Pros: >>>> customers would hand over hs_errs to us with the relevant >>>> diagnostics. Cons: we can overflow the >>>> stringStream and truncate parts of the data. Your call. >>> >>> >>> Ok, let's do that then: >>> >>> http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.02/ >>> >>> Good? >> >> assert_same_oops() itself is assert only (has NOT_DEBUG_RETURN in >> definition), does not need nested ifdef ASSERT ... > > > Right! Very good catch! > > http://cr.openjdk.java.net/~rkennke/JDK-8237780/webrev.03/ > > Good now? > Yes, good to me. Thanks, -Zhengyu > Thanks for reviewing! > > Roman > From kirill at korins.ky Tue Feb 18 16:04:58 2020 From: kirill at korins.ky (Kirill A. Korinsky) Date: Tue, 18 Feb 2020 17:04:58 +0100 Subject: Probably a bug In-Reply-To: References: Message-ID: Looks like it is Shenandoah bug Why I think so? I've covered AbstractNodeQueue by very detailed logging and has this: DEBUG AbstractNodeQueue: - (Node(2395, tid: 38, at: 322151611089285)) setNext(), newNext: Node(2994, tid: 38, at: 322151611097285) DEBUG AbstractNodeQueue: - (AbstractNodeQueue(2235, tid: 38, at: 322151611115585)) add, n: Node(2994, tid: 38, at: 322151611123985); o: Node(2395, tid: 38, at: 322151611132085) public final void add(final T value) { final Node n = new Node(value); Node o = getAndSet(n); // unsafe.getAndSetObject o.setNext(n); LOGGER.debug("(" + this + ") " + "add, n: " + n + "; value: " + value + "; o: " + o); } protected final void setNext(final Node newNext) { Unsafe.instance.putOrderedObject(this, nextOffset, newNext); } public String toString() { return "AbstractNodeQueue(" + nodeNumber + ", tid: " + Thread.currentThread().getId() + ", at: " + System.nanoTime() + ")"; } public String toString() { return "Node(" + nodeNumber + ", tid: " + Thread.currentThread().getId() + ", at: " + System.nanoTime() + ")"; } DEBUG AbstractNodeQueue: - (AbstractNodeQueue(2235, tid: 38, at: 322151751689585)) pollNode, next: null; tail: Node(2395, tid: 38, at: 322151751698185); get(): Node(2994, tid: 38, at: 322151751707485) public final Node pollNode() { final Node tail = (Node) Unsafe.instance.getObjectVolatile(this, tailOffset); Node next = tail.next(); long spins = 0; LOGGER.debug("(" + this + ") " + "pollNode, next: " + next + "; tail: " + tail + "; get(): " + get()); if (next == null && get() != tail) { // if tail != head this is not going to change until producer makes progress // we can avoid reading the head and just spin on next until it shows up do { spins++; next = tail.next(); } while (next == null); } The thread is looping inside do...while As soon as I replaced it `getObjectVolatile` and `putOrderedObject` to direct access to volatile nothing is changed. DEBUG AbstractNodeQueue: - (Node(2526, tid: 38, at: 323848958634985, next: null)) setNext(), newNext: Node(3116, tid: 38, at: 323848958641285, next: null) DEBUG AbstractNodeQueue: - (AbstractNodeQueue(2367, tid: 38, at: 323848958656285)) add, n: Node(3116, tid: 38, at: 323848958664185, next: null); o: Node(2526, tid: 38, at: 323848958672785, next: Node(3116, tid: 38, at: 323848958679985, next: null)) DEBUG AbstractNodeQueue: - (AbstractNodeQueue(2367, tid: 38, at: 323849089231985)) pollNode, next: null; tail: Node(2526, tid: 38, at: 323849089241685, next: null); get(): Node(3116, tid: 38, at: 323849089251185, next: null) (here I've added to log next to show current value) I've tried to reimplement Node class to `public static class Node extends AtomicReference> ` doesn't help. I've tried just a field and it doesn't help. -- wbr, Kirill > On 17. Feb 2020, at 15:59, Kirill A. Korinsky wrote: > > Good day, > > I'd like to ask for advice because it looks like I've discovered something that might be related to Shenandoah bug. > > I haven't got any proof that it is inside Shenandoah, nor a simple test case to reproduce it. > > It appears inside Akka and you can read my hunting with Akka team here: https://github.com/akka/akka/issues/28601 > > As summary: > - it appears as infinite loop inside Akka queue that is lock-free linked-queue that's implemented via getObjectVolatile(), getAndSet() and few more atomic/unsafe calls. > - if I've enabled any debugging such as XX:+ShenandoahVerify the bug is disappear => I can't provide any hs_err_log :( > - it exists on OpenJDK-8 from fedora 31 and at shipilev/openjdk-shenandoah:8-fastdebug > - it is very difficult to achieve and it is very fragile. In real life, it appears only at one and bigger cluster, at my synthetic test case it requires to bootstrap an application and uses the unreachable Akka system > - to achieve this bug I should have a lot of garbage inside heap that produced by bootstrapping an application when it builds its index. The index has size 0,5gb..1gb (and the heap is 2gb) and the size depends on DB that is continuously updating, and the bug is achievable at any possibly size of the index. > - if I switch to G1 for example it disappears. > > Right now I have two possible sources of this bug: > - very strange race condition inside Akka. > - a bug inside Shenandoah that is related to the missed barrier or deeper. > > To eliminate or confirm Shenandoah related possibility I need some advice on how to do it because I can't prepare easy to reproduce code :( > > -- > wbr, Kirill > From zgu at redhat.com Tue Feb 18 16:52:48 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 18 Feb 2020 11:52:48 -0500 Subject: [15] RFR 8239354: Shenandoah: minor enhancements to traversal GC Message-ID: 1) Added assertion to catch evacuation after completion of heap traversal. This should help catch the bug demonstrated in sh-jdk11 w/o JDK-8237396. 2) Retire TLAB/GCLAB after completion of heap traversal. Current code retires TLAB/GCLAB at the beginning final traversal, but STW traversal still uses GCLAB to evacuate remaining objects. 3) Added comments regarding why need to retire TLAB/GCLAB, even we don't need heap to be parsable. Bug: https://bugs.openjdk.java.net/browse/JDK-8239354 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8239354/webrev.00/index.html Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Tue Feb 18 19:25:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 18 Feb 2020 20:25:57 +0100 Subject: Probably a bug In-Reply-To: References: Message-ID: Hi Kirill, On 2/18/20 5:04 PM, Kirill A. Korinsky wrote: > Looks like it is Shenandoah bug Might be! > As soon as I replaced it `getObjectVolatile` and `putOrderedObject` to direct access to volatile nothing is changed. Mmm. As soon as you did something, nothing changed? Sorry, I don't understand what are you trying to say with this experiment. Could you please say how do you interpret this logging data and what hypothesis it supposed to confirm? Please ELI5 this, because we don't have the entire context for what you are seeing there in the debugging trenches. -- Thanks, -Aleksey From kirill at korins.ky Tue Feb 18 20:12:48 2020 From: kirill at korins.ky (Kirill A. Korinsky) Date: Tue, 18 Feb 2020 21:12:48 +0100 Subject: Probably a bug In-Reply-To: References: Message-ID: Hi Aleksey, Let me makes things as clear as I can. You can see the full code of used java class here: https://gist.github.com/catap/f753e5d12409be8ab19135b40769c3db The issue: `next` field is loosing its value at some point, and as very sad side effect it brokes akka scheduler by moving it to infinity loop that can be interrupted only by kill of jvm. The Log that is related only to object that had this issue: DEBUG AbstractNodeQueue: - [setNext] (Node(2576)) ; newNext: Node(3179); next: Node(3179); next(): Node(3179) DEBUG AbstractNodeQueue: - [pollNode] (Node(2576)); tail.next(): null; tail.next: null How you can see the object `Node(2576)` had `next` field with value `Node(3179)` that was lost at some point. -- wbr, Kirill > On 18. Feb 2020, at 20:25, Aleksey Shipilev wrote: > > Hi Kirill, > > On 2/18/20 5:04 PM, Kirill A. Korinsky wrote: >> Looks like it is Shenandoah bug > > Might be! > >> As soon as I replaced it `getObjectVolatile` and `putOrderedObject` to direct access to volatile nothing is changed. > > Mmm. As soon as you did something, nothing changed? > > Sorry, I don't understand what are you trying to say with this experiment. Could you please say how > do you interpret this logging data and what hypothesis it supposed to confirm? Please ELI5 this, > because we don't have the entire context for what you are seeing there in the debugging trenches. > > -- > Thanks, > -Aleksey > From aph at redhat.com Wed Feb 19 12:20:26 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Feb 2020 12:20:26 +0000 Subject: Probably a bug In-Reply-To: References: Message-ID: On 2/18/20 4:04 PM, Kirill A. Korinsky wrote: > > The thread is looping inside do...while > > As soon as I replaced it `getObjectVolatile` and `putOrderedObject` to direct access to volatile nothing is changed. Good idea. Given that the published algorithm at http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue specifies a releasing store when setting next, the use of putOrderedObject() here is very suspicious. -- 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 kirill at korins.ky Wed Feb 19 12:26:53 2020 From: kirill at korins.ky (Kirill A. Korinsky) Date: Wed, 19 Feb 2020 13:26:53 +0100 Subject: Probably a bug In-Reply-To: References: Message-ID: <319BB776-D19E-4BDB-9C8E-403F0F523E57@korins.ky> Honestly? I don't like this code at all. Call wait-free code that contains `do..while` at least strange. And using lazy atomic operations and direct access to unsafe object where only one thread uses it... let me call it a good example of overengineering. Anyway, this simplification do not fix an issue :( -- wbr, Kirill > On 19. Feb 2020, at 13:20, Andrew Haley wrote: > > On 2/18/20 4:04 PM, Kirill A. Korinsky wrote: >> >> The thread is looping inside do...while >> >> As soon as I replaced it `getObjectVolatile` and `putOrderedObject` to direct access to volatile nothing is changed. > > Good idea. Given that the published algorithm at > http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue > specifies a releasing store when setting next, the use of > putOrderedObject() here is very suspicious. > > -- > 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 shade at redhat.com Wed Feb 19 12:29:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 13:29:03 +0100 Subject: Probably a bug In-Reply-To: References: Message-ID: <5203b32c-267f-da57-3437-b0fd5f9a1b98@redhat.com> On 2/19/20 1:20 PM, Andrew Haley wrote: > On 2/18/20 4:04 PM, Kirill A. Korinsky wrote: >> The thread is looping inside do...while >> >> As soon as I replaced it `getObjectVolatile` and `putOrderedObject` to direct access to volatile nothing is changed. > > Good idea. Given that the published algorithm at > http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue > specifies a releasing store when setting next, the use of > putOrderedObject() here is very suspicious. Unsafe.putOrderedObject is releasing store in Unsafe newspeak. You are probably confusing it with opaque. -- Thanks, -Aleksey From aph at redhat.com Wed Feb 19 12:40:22 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Feb 2020 12:40:22 +0000 Subject: Probably a bug In-Reply-To: <5203b32c-267f-da57-3437-b0fd5f9a1b98@redhat.com> References: <5203b32c-267f-da57-3437-b0fd5f9a1b98@redhat.com> Message-ID: On 2/19/20 12:29 PM, Aleksey Shipilev wrote: > Unsafe.putOrderedObject is releasing store in Unsafe newspeak. Oh, so it is. OK. > You are probably confusing it with opaque. No, I made the mistake of reading the description, which doesn't seem to help: * Version of {@link #putObjectVolatile(Object, long, Object)} * that does not guarantee immediate visibility of the store to * other threads. This method is generally only useful if the * underlying field is a Java volatile (or if an array cell, one * that is otherwise only accessed using volatile accesses). I didn't spot this: * Corresponds to C11 atomic_store_explicit(..., memory_order_release). -- 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 shade at redhat.com Wed Feb 19 16:47:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Feb 2020 17:47:04 +0100 Subject: RFC: Pick up jdk-11.0.7+4 to sh/jdk11 Message-ID: <07839e1f-6d2b-f878-6a0e-ba31987aec09@redhat.com> Upstream published jdk-11.0.7+4, let's pick it up. The merge is trivial. I would tag the result shenandoah-jdk-11.0.7+4 right away. Changeset list: https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.7%2b4/changesets.txt Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed Feb 19 16:52:35 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 19 Feb 2020 17:52:35 +0100 Subject: RFC: Pick up jdk-11.0.7+4 to sh/jdk11 In-Reply-To: <07839e1f-6d2b-f878-6a0e-ba31987aec09@redhat.com> References: <07839e1f-6d2b-f878-6a0e-ba31987aec09@redhat.com> Message-ID: ok, let's do it! Thanks, Roman > Upstream published jdk-11.0.7+4, let's pick it up. > > The merge is trivial. I would tag the result shenandoah-jdk-11.0.7+4 right away. > > Changeset list: > https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.7%2b4/changesets.txt > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Wed Feb 19 17:11:10 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 19 Feb 2020 17:11:10 +0000 Subject: hg: shenandoah/jdk11: 24 new changesets Message-ID: <202002191711.01JHBCxt021970@aojmv0008.oracle.com> Changeset: afc98629d75a Author: dbuck Date: 2020-02-10 03:35 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/afc98629d75a 8238596: AVX enabled by default for Skylake even when unsupported Summary: Only default to UseAVX=2 when support is detected Reviewed-by: shade, vlivanov ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: 202c54058646 Author: shade Date: 2020-02-10 06:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/202c54058646 8238366: CTW runner closes standard output on exit Reviewed-by: adinn, iignatyev ! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/CompileTheWorld.java Changeset: fe057ea68157 Author: shade Date: 2020-02-10 06:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/fe057ea68157 8238247: CTW runner should sweep nmethods more aggressively Reviewed-by: adinn, simonis, iignatyev ! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java Changeset: a3ea602d37d9 Author: shade Date: 2020-02-10 06:18 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/a3ea602d37d9 8238591: CTW: Split applications/ctw/modules/jdk_localedata.java Reviewed-by: iignatyev ! test/hotspot/jtreg/TEST.groups ! test/hotspot/jtreg/applications/ctw/modules/jdk_localedata.java + test/hotspot/jtreg/applications/ctw/modules/jdk_localedata_2.java Changeset: abe6d7da388b Author: chegar Date: 2019-02-08 12:23 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/abe6d7da388b 8218662: Allow 204 responses with Content-Length:0 Reviewed-by: michaelm ! src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java ! test/jdk/java/net/httpclient/Response204.java Changeset: 20c1fb65b749 Author: naoto Date: 2019-06-05 16:10 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/20c1fb65b749 8225182: JNI exception pending in DestroyXIMCallback of awt_InputMethod.c:1327 Reviewed-by: serb ! src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c Changeset: c8a96d97ae66 Author: mhalder Date: 2019-02-06 17:28 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c8a96d97ae66 8207938: At step6,Click Add button,case failed automatically. Reviewed-by: kaddepalli, psadhukhan ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java Changeset: 928af38bccf2 Author: gadams Date: 2018-10-03 07:41 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/928af38bccf2 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false Reviewed-by: cjplummer, amenkov ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/MessageOutput.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java Changeset: c8e12b226125 Author: xuelei Date: 2019-03-22 13:47 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c8e12b226125 8218889: Improperly use of the Optional API Reviewed-by: jnimeh, wetmore ! src/java.base/share/classes/sun/security/ssl/NewSessionTicket.java ! src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/security/ssl/ServerHello.java Changeset: cbe82180a1c5 Author: mikael Date: 2019-06-05 08:43 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/cbe82180a1c5 8225305: ProblemList java/lang/invoke/VarHandles tests Reviewed-by: kvn, iignatyev, mchung, alanb + test/jdk/ProblemList-aot.txt Changeset: 901ea1e20fa9 Author: thartmann Date: 2019-06-19 12:24 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/901ea1e20fa9 8226381: ProblemList java/lang/reflect/PublicMethods/PublicMethodsTest.java Summary: Put test on AOT ProblemList. Reviewed-by: iignatyev ! test/jdk/ProblemList-aot.txt Changeset: 695c552952bc Author: mdoerr Date: 2020-01-23 13:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/695c552952bc 8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization Reviewed-by: simonis, dholmes ! src/hotspot/share/runtime/compilationPolicy.cpp Changeset: 3e8a20027adc Author: dtitov Date: 2018-09-28 12:04 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/3e8a20027adc 8163083: SocketListeningConnector does not allow invocations with port 0 Reviewed-by: sspitsyn, amenkov, gadams, jcbeyler ! src/jdk.jdi/share/classes/com/sun/jdi/connect/ListeningConnector.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/GenericListeningConnector.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SocketListeningConnector.java + test/jdk/com/sun/jdi/connect/WildcardPortSupport.java Changeset: cdb4b46db156 Author: mbaesken Date: 2019-11-27 10:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/cdb4b46db156 8234525: enable link-time section-gc for linux s390x to remove unused code Reviewed-by: erikj, mdoerr ! make/autoconf/flags-cflags.m4 ! make/autoconf/flags-ldflags.m4 Changeset: c143d32116f9 Author: rraghavan Date: 2019-06-11 14:33 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c143d32116f9 8225567: Wrong file headers with 8202414 fix changeset Summary: Corrected source file headers Reviewed-by: thartmann ! src/hotspot/share/opto/memnode.cpp ! test/hotspot/jtreg/compiler/c2/Test8202414.java Changeset: f72d6cefa57f Author: xuelei Date: 2019-02-14 14:19 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/f72d6cefa57f 4919790: Errors in alert ssl message does not reflect the actual certificate status Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/Alert.java ! src/java.base/share/classes/sun/security/ssl/CertificateMessage.java Changeset: 1300edeb3dc4 Author: valeriep Date: 2019-08-14 00:57 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/1300edeb3dc4 8228613: java.security.Provider#getServices order is no longer deterministic Summary: Changed to use SunEntries.DEF_SECURE_RANDOM_ALGO instead of relying on ordering of SecureRandom services Reviewed-by: weijun ! src/java.base/share/classes/java/security/SecureRandom.java ! src/java.base/share/classes/sun/security/provider/SunEntries.java + test/jdk/java/security/SecureRandom/DefaultAlgo.java Changeset: 7dbf15c8ef3c Author: phh Date: 2019-09-25 08:29 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/7dbf15c8ef3c 8231387: java.security.Provider.getService returns random result due to race condition with mutating methods in the same class Summary: Synchronize access to legacyMap in Provider.getService. Reviewed-by: valeriep Contributed-by: Tianmin Shi ! src/java.base/share/classes/java/security/Provider.java + test/jdk/java/security/Provider/GetServiceRace.java Changeset: f78ab077a234 Author: gadams Date: 2019-04-05 07:10 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/f78ab077a234 8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 Reviewed-by: cjplummer, jcbeyler ! test/lib/jdk/test/lib/apps/LingeredApp.java Changeset: b5cf70519c1a Author: arapte Date: 2019-10-30 16:59 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/b5cf70519c1a 8226892: ActionListeners on JRadioButtons don't get notified when selection is changed with arrow keys Reviewed-by: serb, psadhukhan ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java ! test/jdk/javax/swing/JRadioButton/8033699/bug8033699.java Changeset: d3d1f7f67de1 Author: thartmann Date: 2019-08-30 16:17 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d3d1f7f67de1 8230390: Problemlist SA tests with AOT Summary: Putting tests on the problem list. Reviewed-by: roland ! test/hotspot/jtreg/ProblemList-aot.txt Changeset: e7943a74a89c Author: clanger Date: 2020-02-19 14:21 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/e7943a74a89c Added tag jdk-11.0.7+4 for changeset d3d1f7f67de1 ! .hgtags Changeset: 02f1d728e9b5 Author: shade Date: 2020-02-19 17:20 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/02f1d728e9b5 Merge ! .hgtags ! make/autoconf/flags-cflags.m4 ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/opto/memnode.cpp ! test/hotspot/jtreg/TEST.groups Changeset: c84db0329cf9 Author: shade Date: 2020-02-19 17:20 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c84db0329cf9 Added tag shenandoah-jdk-11.0.7+4 for changeset 02f1d728e9b5 ! .hgtags From zgu at redhat.com Wed Feb 19 18:37:51 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 19 Feb 2020 13:37:51 -0500 Subject: [Shenandoah 11u] RFR: Root processing related shenandoah-11u backports Message-ID: Backport following CRs to Shenandoah 11u, also fixed an issue in early backport. 8227101: Shenandoah: Use ShenandoahSharedFlag for claimed flag in ShenandoahSerialRoot 8227866: Shenandoah: Split weak root processing and class unloading in parallel cleaning task 8236902: Shenandoah: Missing string dedup roots in all root scanner 8231999: Shenandoah: Traversal failed compiler/jsr292 /CallSiteDepContextTest.java [partial] Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/sh_11u_root_proc_backports/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) Thanks, -Zhengyu From rkennke at redhat.com Wed Feb 19 23:14:37 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 20 Feb 2020 00:14:37 +0100 Subject: [Shenandoah 11u backport] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms In-Reply-To: References: Message-ID: <6449d3fa-f144-e913-12fe-9cf1f41274cf@redhat.com> Looks good to me. Roman PS: I wonder if we should take these parts to upstream 11u eventually, that would bring down our shared-code exposure considerably. OTOH, only Shenandoah uses these code paths. Hmm. Or could we take the whole code path to ShenandoahBarrierSetAssembler, call it right before: unpack_array_argument(..) like we do elsewhere? E.g.: #ifdef INCLUDE_SHENANDOAHGC if (UseShenandoahGC) { ShenandoahBarrierSetAssembler::bsasm()->gen_object_pinning(); } #endif unpack_array_argument(..); and move all the rest of the code into ShBSA? That should be a follow-up though because it would also do the same code movements for x86_64 and aarch64. Roman > I would like backport JDK-8229919 to Shenandoah 11u. > > http://cr.openjdk.java.net/~zgu/JDK-8229919/11u/webrev.00/ > > Test: > ? hotspot_gc_shenandoah x86_32 on Linux > > Thanks, > > -Zhengyu > From rkennke at redhat.com Wed Feb 19 23:15:21 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 20 Feb 2020 00:15:21 +0100 Subject: [Shenandoah 8u] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms In-Reply-To: References: Message-ID: <6d82a300-f0a0-eb8b-103b-8be195a483bb@redhat.com> Looks good, but same considerations overall as with the 11u change. :-) Thanks, Roman > I would like backport JDK-8229919 to Shenandoah 8u. > The major difference between original patch and the backport is in tests. > > > http://cr.openjdk.java.net/~zgu/JDK-8229919/8u/webrev.00/ > > Test: > ? hotspot_gc_shenandoah x86_32 on Linux > > Thanks, > > -Zhengyu > From zgu at redhat.com Thu Feb 20 01:44:08 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 19 Feb 2020 20:44:08 -0500 Subject: [Shenandoah 11u backport] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms In-Reply-To: <6449d3fa-f144-e913-12fe-9cf1f41274cf@redhat.com> References: <6449d3fa-f144-e913-12fe-9cf1f41274cf@redhat.com> Message-ID: On 2/19/20 6:14 PM, Roman Kennke wrote: > Looks good to me. > > Roman > > PS: I wonder if we should take these parts to upstream 11u eventually, > that would bring down our shared-code exposure considerably. OTOH, only > Shenandoah uses these code paths. Hmm. > > Or could we take the whole code path to ShenandoahBarrierSetAssembler, > call it right before: > > unpack_array_argument(..) > > like we do elsewhere? E.g.: > > #ifdef INCLUDE_SHENANDOAHGC > if (UseShenandoahGC) { > ShenandoahBarrierSetAssembler::bsasm()->gen_object_pinning(); > } > #endif > unpack_array_argument(..); > > and move all the rest of the code into ShBSA? Well, bringing down these parts of code to 11u, likely results a clean backport, probably less risky than refactoring. Thanks, -Zhengyu > > That should be a follow-up though because it would also do the same code > movements for x86_64 and aarch64. > > Roman > >> I would like backport JDK-8229919 to Shenandoah 11u. >> >> http://cr.openjdk.java.net/~zgu/JDK-8229919/11u/webrev.00/ >> >> Test: >> ? hotspot_gc_shenandoah x86_32 on Linux >> >> Thanks, >> >> -Zhengyu >> > From zgu at redhat.com Thu Feb 20 13:19:16 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 20 Feb 2020 13:19:16 +0000 Subject: hg: shenandoah/jdk11: [backport] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms Message-ID: <202002201319.01KDJHKh024364@aojmv0008.oracle.com> Changeset: 161b081be608 Author: zgu Date: 2019-10-15 22:22 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/161b081be608 [backport] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms Reviewed-by: rkennke, adinn ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! test/hotspot/jtreg/gc/shenandoah/jni/CriticalNativeArgs.java ! test/hotspot/jtreg/gc/shenandoah/jni/CriticalNativeStress.java From rkennke at redhat.com Thu Feb 20 18:43:58 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 20 Feb 2020 19:43:58 +0100 Subject: RFR (sh/jdk8): Backport: JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy Message-ID: <61e40a23-6399-c3f9-38ac-4af4aa6ec3f4@redhat.com> This is the backport for the strong invariant for arraycopy to shenandoah/jdk8. It includes the following changesets: - JDK-8221848: Shenandoah: ArrayCopy post-barrier improvements - JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy - JDK-8231410: Shenandoah: clone barrier should use base pointer - JDK-8231447: Shenandoah: Compilation-time regression after JDK-8231086 - JDK-8231499: Shenandoah: compiler/arraycopy/TestDefaultMethodArrayCloneDeoptC2 fails - JDK-8232778: Shenandoah: SBSA::arraycopy_prologue checks wrong register Much of it amounts to a rewrite in jdk8 land because missing/totally different barrier story. JDK-8221848 is only a small fragment of the original change (gc-state flag changes in shenandoahHeap.cpp), most of it would have been removed by JDK-8231086 and was not easy to do because lacking arraycopy barriers. http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.01/ Testing: hotspot_gc_shenandoah x86_64, x86_32, aarch64, specjvm running on interpreter, C1 and C2. Zhengyu confirmed on Windows. Can you please carefully review it? This is a somewhat risky change for a backport because it's so different. Roman From shade at redhat.com Thu Feb 20 18:58:47 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 19:58:47 +0100 Subject: RFR (sh/jdk8): Backport: JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy In-Reply-To: <61e40a23-6399-c3f9-38ac-4af4aa6ec3f4@redhat.com> References: <61e40a23-6399-c3f9-38ac-4af4aa6ec3f4@redhat.com> Message-ID: <67efd8ee-4848-95b4-593a-5c9400c5a424@redhat.com> On 2/20/20 7:43 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.01/ Okay, brief look: *) src/cpu/aarch64/vm/stubGenerator_aarch64.cpp src/cpu/x86/vm/stubGenerator_x86_32.cpp Should new switch cases be protected by #if INCLUDE_ALL_GCS too? *) ShenandoahBarrierSet::arraycopy_pre_work implementation: indenting is off, is this from original changeset? *) I believe test is misplaced. Did that test even run? test/hotspot/jtreg/gc/shenandoah/compiler/TestClone.java should be test/gc/shenandoah/compiler/TestClone.java -- Thanks, -Aleksey From zgu at redhat.com Thu Feb 20 19:08:46 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 20 Feb 2020 14:08:46 -0500 Subject: [Sh-11u] Fix minimal build after JDK-8229919 backport Message-ID: <1f6a0915-8aab-1bb9-6d3e-6420bd746aae@redhat.com> Added missing header file. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/fix_minimal_after_JDK-8229919/webrev.00/ Test: 32-bits minimal fastdebug build Thanks, -Zhengyu From shade at redhat.com Thu Feb 20 19:10:47 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Feb 2020 20:10:47 +0100 Subject: [Sh-11u] Fix minimal build after JDK-8229919 backport In-Reply-To: <1f6a0915-8aab-1bb9-6d3e-6420bd746aae@redhat.com> References: <1f6a0915-8aab-1bb9-6d3e-6420bd746aae@redhat.com> Message-ID: On 2/20/20 8:08 PM, Zhengyu Gu wrote: > Webrev: > http://cr.openjdk.java.net/~zgu/shenandoah/fix_minimal_after_JDK-8229919/webrev.00/ Looks good, thanks. -- -Aleksey From zgu at redhat.com Thu Feb 20 19:20:00 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 20 Feb 2020 19:20:00 +0000 Subject: hg: shenandoah/jdk11: Fix minimal build after JDK-8229919 backport Message-ID: <202002201920.01KJK0gY021463@aojmv0008.oracle.com> Changeset: eda7dd950f48 Author: zgu Date: 2020-02-20 14:19 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/eda7dd950f48 Fix minimal build after JDK-8229919 backport Reviewed-by: shade ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp From rkennke at redhat.com Thu Feb 20 20:41:57 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 20 Feb 2020 21:41:57 +0100 Subject: RFR (sh/jdk8): Backport: JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy In-Reply-To: <67efd8ee-4848-95b4-593a-5c9400c5a424@redhat.com> References: <61e40a23-6399-c3f9-38ac-4af4aa6ec3f4@redhat.com> <67efd8ee-4848-95b4-593a-5c9400c5a424@redhat.com> Message-ID: Hi Aleksey, >> http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.01/ > > Okay, brief look: > > *) src/cpu/aarch64/vm/stubGenerator_aarch64.cpp > src/cpu/x86/vm/stubGenerator_x86_32.cpp > > Should new switch cases be protected by #if INCLUDE_ALL_GCS too? Good question. It wasn't before, and it isn't for the other GCs. Also, the enum that defines this doesn't have INCLUDE_ALL_GCS either. I think we might risk compiler complains about missing cases? > *) ShenandoahBarrierSet::arraycopy_pre_work implementation: indenting is off, is this from original > changeset? No. Fixed. > *) I believe test is misplaced. Did that test even run? > test/hotspot/jtreg/gc/shenandoah/compiler/TestClone.java > should be > test/gc/shenandoah/compiler/TestClone.java Oopsie. Right. http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.02/ Better? Thanks, Roman From shade at redhat.com Fri Feb 21 08:47:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 21 Feb 2020 09:47:01 +0100 Subject: RFR (sh/jdk8): Backport: JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy In-Reply-To: References: <61e40a23-6399-c3f9-38ac-4af4aa6ec3f4@redhat.com> <67efd8ee-4848-95b4-593a-5c9400c5a424@redhat.com> Message-ID: On 2/20/20 9:41 PM, Roman Kennke wrote: >>> http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.01/ >> >> Okay, brief look: >> >> *) src/cpu/aarch64/vm/stubGenerator_aarch64.cpp >> src/cpu/x86/vm/stubGenerator_x86_32.cpp >> >> Should new switch cases be protected by #if INCLUDE_ALL_GCS too? > > Good question. It wasn't before, and it isn't for the other GCs. Also, > the enum that defines this doesn't have INCLUDE_ALL_GCS either. I think > we might risk compiler complains about missing cases? ...also src/cpu/x86/vm/stubGenerator_x86_64.cpp. I think it works for other GCs, because they are calling the implementation from shared BarrierSet. Without Shenandoah, shenandoahBarrierSetAssembler_*.hpp would not get included, so I would expect call to ShenandoahBarrierSetAssembler::bsasm()->arraycopy_prologue(...) to break compilation. >> *) I believe test is misplaced. Did that test even run? >> test/hotspot/jtreg/gc/shenandoah/compiler/TestClone.java >> should be >> test/gc/shenandoah/compiler/TestClone.java > > Oopsie. Right. Test is still in the wrong place in webrev.02. > http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.02/ Yes. Additional things after second read: *) Should be "#if INCLUDE_ALL_GCS", not "#ifdef INCLUDE_ALL_GCS". You probably need to #include "utilities/macros.hpp" to gain access to it. *) Would you mind adding the comment to ShenandoahRuntime::shenandoah_clone_barrier, something like (if that is correct): // In JDK 8u, caller does the arraycopy itself, and then calls the clone_barrier. // It is changed in later JDKs to do the copy right here, see JDK-???????? Otherwise seems fine. -- Thanks, -Aleksey From shade at redhat.com Fri Feb 21 09:22:59 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 21 Feb 2020 10:22:59 +0100 Subject: RFR (sh/jdk8): Backport: JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy In-Reply-To: References: <61e40a23-6399-c3f9-38ac-4af4aa6ec3f4@redhat.com> <67efd8ee-4848-95b4-593a-5c9400c5a424@redhat.com> Message-ID: On 2/21/20 9:47 AM, Aleksey Shipilev wrote: >>> *) I believe test is misplaced. Did that test even run? >>> test/hotspot/jtreg/gc/shenandoah/compiler/TestClone.java >>> should be >>> test/gc/shenandoah/compiler/TestClone.java >> >> Oopsie. Right. > > Test is still in the wrong place in webrev.02. After I move it to proper place and fix @requires (dropping everything except 64-bit check), it passes on x86_64 and x86_32. -- Thanks, -Aleksey From rkennke at redhat.com Fri Feb 21 12:13:41 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 21 Feb 2020 13:13:41 +0100 Subject: RFR (sh/jdk8): Backport: JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy In-Reply-To: References: <61e40a23-6399-c3f9-38ac-4af4aa6ec3f4@redhat.com> <67efd8ee-4848-95b4-593a-5c9400c5a424@redhat.com> Message-ID: Hi Aleksey, >>> Should new switch cases be protected by #if INCLUDE_ALL_GCS too? >> >> Good question. It wasn't before, and it isn't for the other GCs. Also, >> the enum that defines this doesn't have INCLUDE_ALL_GCS either. I think >> we might risk compiler complains about missing cases? > > ...also src/cpu/x86/vm/stubGenerator_x86_64.cpp. > > I think it works for other GCs, because they are calling the implementation from shared BarrierSet. > Without Shenandoah, shenandoahBarrierSetAssembler_*.hpp would not get included, so I would expect > call to ShenandoahBarrierSetAssembler::bsasm()->arraycopy_prologue(...) to break compilation. Right. I've added the #if INCLUDE_ALL_GCS and verified with minimal build that it compiles. >>> *) I believe test is misplaced. Did that test even run? >>> test/hotspot/jtreg/gc/shenandoah/compiler/TestClone.java >>> should be >>> test/gc/shenandoah/compiler/TestClone.java >> >> Oopsie. Right. > > Test is still in the wrong place in webrev.02. > >> http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.02/ Damn. Should be fixed now. > Yes. Additional things after second read: > > *) Should be "#if INCLUDE_ALL_GCS", not "#ifdef INCLUDE_ALL_GCS". You probably need to #include > "utilities/macros.hpp" to gain access to it. Right. I fixed that all over the place and added the includes too. > *) Would you mind adding the comment to ShenandoahRuntime::shenandoah_clone_barrier, something like > (if that is correct): > // In JDK 8u, caller does the arraycopy itself, and then calls the clone_barrier. > // It is changed in later JDKs to do the copy right here, see JDK-???????? It is actually changed back to do the copy in C2 compiled code, and that reversion is JDK-8231499... which is part of this backport. http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.03/ Re-ran tests on x86_64. Still looking good. Roman From shade at redhat.com Fri Feb 21 12:17:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 21 Feb 2020 13:17:41 +0100 Subject: RFR (sh/jdk8): Backport: JDK-8231086: Shenandoah: Stronger invariant for object-arraycopy In-Reply-To: References: <61e40a23-6399-c3f9-38ac-4af4aa6ec3f4@redhat.com> <67efd8ee-4848-95b4-593a-5c9400c5a424@redhat.com> Message-ID: On 2/21/20 1:13 PM, Roman Kennke wrote: >> *) Would you mind adding the comment to ShenandoahRuntime::shenandoah_clone_barrier, something like >> (if that is correct): >> // In JDK 8u, caller does the arraycopy itself, and then calls the clone_barrier. >> // It is changed in later JDKs to do the copy right here, see JDK-???????? > > It is actually changed back to do the copy in C2 compiled code, and that > reversion is JDK-8231499... which is part of this backport. Ah, I see. > http://cr.openjdk.java.net/~rkennke/JDK-8231086-jdk8/webrev.03/ Looks good. -- Thanks, -Aleksey From rkennke at redhat.com Fri Feb 21 12:42:47 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 21 Feb 2020 13:42:47 +0100 Subject: [Shenandoah 11u] RFR: Root processing related shenandoah-11u backports In-Reply-To: References: Message-ID: <5be1f59f-42b7-9645-44a1-ca927bced895@redhat.com> Hi Zhengyu, Looks ok to me. Thank you! Roman > Backport following CRs to Shenandoah 11u, also fixed an issue in early > backport. > > 8227101: Shenandoah: Use ShenandoahSharedFlag for claimed flag in > ???????? ShenandoahSerialRoot > > 8227866: Shenandoah: Split weak root processing and class unloading in > ???????? parallel cleaning task > > 8236902: Shenandoah: Missing string dedup roots in all root scanner > > 8231999: Shenandoah: Traversal failed compiler/jsr292 > ??????? /CallSiteDepContextTest.java > ? [partial] > > > > Webrev: > http://cr.openjdk.java.net/~zgu/shenandoah/sh_11u_root_proc_backports/webrev.00/ > > > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) > > Thanks, > > -Zhengyu > From rkennke at redhat.com Fri Feb 21 12:46:02 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 21 Feb 2020 13:46:02 +0100 Subject: [11] RFR: Fix ShenandoahBarrierSetC2::enqueue_useful_gc_barrier (part of JDK-8212611) In-Reply-To: <4183be94-cf89-478e-c83f-26a54f633a1e@redhat.com> References: <6f7660a4-286b-610d-3f7b-a93067e8171a@redhat.com> <4183be94-cf89-478e-c83f-26a54f633a1e@redhat.com> Message-ID: <071b7a40-f2fc-e990-95de-33bcdf77f324@redhat.com> >> There is a discrepancy between jdk/jdk and sh/jdk11 definition of BSC2::enqueue_useful_gc_barrier, >> where one thing adds the node to the IGVN worklist [1], and another adds all users to it [2]. It was >> introduced by JDK-8212611 [3], and we should consider backporting it to 11u. >> >> Meanwhile, sh/jdk11 x86_32 CTW fails without that patch: >> >> $ CONF=linux-x86-normal-server-fastdebug make run-test TEST_VM_OPTS="-XX:-TieredCompilation >> -XX:+UseShenandoahGC" TEST=applications/ctw/modules/jdk_scripting_nashorn.java >> >> # >> # Internal Error (/home/shade/trunks/shenandoah-jdk11/src/hotspot/share/opto/compile.cpp:2851), >> pid=23210, tid=23220 >> # assert(!ShenandoahBarrierSetC2::has_only_shenandoah_wb_pre_uses(addp)) failed: useless address >> computation? >> # > > Seeing exactly the same failure in sh/jdk11. > >> I believe the best course of action would be to pick up safer parts of JDK-8212611 to sh/jdk11: >> https://cr.openjdk.java.net/~shade/shenandoah/11u-fix-bsc2-eugcb/webrev.01/ > > Eh. This got somehow reverted from sh/jdk11 during this merge: > > changeset: 53541:bc2d5a439bc2 > parent: 53359:743587c28e0f > parent: 53540:ae7ed8c70ecc > user: shade > date: Wed Oct 30 12:24:36 2019 +0100 > summary: Merge > > The same webrev applies cleanly to sh/jdk11. > >> Testing: {x86_64, x86_32} CTW tests, {x86_64, x86_32} hotspot_gc_shenandoah (running) > > ...and passes the same testing. > > I am thinking to re-push this to sh/jdk11. The downside: it increases our upstream exposure until > JDK-8212611 and dependent issues are in 11u. Thoughts? Yes, I think we should do that, and also start working on backporting JDK-8212611. Roman From shade at redhat.com Fri Feb 21 13:18:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 21 Feb 2020 14:18:04 +0100 Subject: [11] RFR: Fix ShenandoahBarrierSetC2::enqueue_useful_gc_barrier (part of JDK-8212611) In-Reply-To: <071b7a40-f2fc-e990-95de-33bcdf77f324@redhat.com> References: <6f7660a4-286b-610d-3f7b-a93067e8171a@redhat.com> <4183be94-cf89-478e-c83f-26a54f633a1e@redhat.com> <071b7a40-f2fc-e990-95de-33bcdf77f324@redhat.com> Message-ID: <90d383d9-6968-59a6-9d60-1d1d060d9ccb@redhat.com> On 2/21/20 1:46 PM, Roman Kennke wrote: >> I am thinking to re-push this to sh/jdk11. The downside: it increases our upstream exposure until >> JDK-8212611 and dependent issues are in 11u. Thoughts? > > Yes, I think we should do that, and also start working on backporting > JDK-8212611. Re-pushed to sh/jdk11. -- Thanks, -Aleksey From rkennke at redhat.com Fri Feb 21 13:26:13 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 21 Feb 2020 14:26:13 +0100 Subject: Reporting of gc+stats In-Reply-To: <16fc8faf832.f9f854ae483598.4097291411583541475@giedres.lt> References: <16fc8faf832.f9f854ae483598.4097291411583541475@giedres.lt> Message-ID: <09c4121e-3ecb-f9b5-8e97-9836bf1cbc8a@redhat.com> Hello Justinas, I apologize for the late reply. > hope this is the right place to ask a few more questions. Sorry if answers were simply overlooked. Sure, here is perfect. We usually don't take so long to reply. :-) > 1. I can't find an option for periodic printing of pacer statistics. (gc+stats prints just on exit?) > Pacers activity looks like the first indication of gc pressure. Don't you think it would be useful to get this information from gc log asap? > Maybe you can introduce ShenandoahPacerStatsPeriod flag for periodic printing of _delays histogram? That sounds like a good idea. We may actually want more more general periodic statistics, not only about pacing. I filed the following bug about it: https://bugs.openjdk.java.net/browse/JDK-8239786 > 1. How to interpret breakdown of roots scanning? > e.g.: "Scan Roots" took 327s, but I can't figure out what part exactly from breakdown. What I am missing? the individual parts 'S: *' are averages over all workers. That means if one tasks (here: CLDG Roots) is not very well parallelized, it will report a low average. Consider what will happen if it's perfectly serial, and we have 4 workers, 1 worker needs 320ms, but the others are basically idle or get almost no work. It will average to 80ms, but the total (reported in "Scan Roots") will add-up to 320+ms. We realize this is confusing and we should improve this. Does that answer your question? Thank you, Roman > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Pause Init Mark (N) = 338.46 s (a = 51057 us) (n = 6629) (lvls, us = 4023, 45508, 50781, 56641, 88198) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Accumulate Stats = 1.42 s (a = 214 us) (n = 6629) (lvls, us = 33, 182, 209, 236, 3329) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Make Parsable = 6.10 s (a = 920 us) (n = 6629) (lvls, us = 55, 732, 891, 1074, 6075) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Clear Liveness = 1.29 s (a = 195 us) (n = 6629) (lvls, us = 91, 168, 189, 211, 3251) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Scan Roots = 327.02 s (a = 49332 us) (n = 6629) (lvls, us = 3613, 43945, 49023, 54688, 86252) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: Thread Roots = 6.68 s (a = 1008 us) (n = 6629) (lvls, us = 137, 869, 994, 1113, 9622) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: Universe Roots = 0.08 s (a = 12 us) (n = 6629) (lvls, us = 2, 8, 9, 13, 4443) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: JNI Roots = 0.37 s (a = 55 us) (n = 6629) (lvls, us = 4, 37, 46, 59, 8601) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: Synchronizer Roots = 0.00 s (a = 1 us) (n = 6629) (lvls, us = 0, 0, 0, 1, 22) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: Management Roots = 0.06 s (a = 8 us) (n = 6629) (lvls, us = 1, 3, 8, 11, 102) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: System Dict Roots = 0.54 s (a = 81 us) (n = 6629) (lvls, us = 16, 61, 74, 89, 4439) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: CLDG Roots = 80.66 s (a = 12167 us) (n = 6629) (lvls, us = 811, 9004, 11133, 14453, 27327) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: JVMTI Roots = 0.50 s (a = 75 us) (n = 6629) (lvls, us = 7, 48, 62, 79, 12281) > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Resize TLABs = 0.95 s (a = 143 us) (n = 6629) (lvls, us = 7, 104, 133, 172, 1513) > From gnu.andrew at redhat.com Fri Feb 21 18:28:36 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Feb 2020 18:28:36 +0000 Subject: [RFR] [8u] 8u252-b03 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b03: - S8005819: Support cross-realm MSSFU - S8046724: XML Signature ECKeyValue elements cannot be marshalled or unmarshalled - S8079140: IgnoreAllErrorHandler should use doPrivileged when it reads system properties - S8134579: [TESTBUG] Some bmi tests fail if can_access_local_variables is on. - S8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension - S8145055: Marlin renderer causes unaligned write accesses - S8145849: ALPN: getHandshakeApplicationProtocol() always return null - S8146293: Add support for RSASSA-PSS Signature algorithm - S8158978: ALPN not working when values are set directly on a SSLServerSocket - S8162723: Array index overflow in Base64 utility class - S8170282: Enable ALPN parameters to be supplied during the TLS handshake - S8171443: (spec) An ALPN callback function may also ignore ALPN - S8175029: StackOverflowError in X509CRL and X509Certificate.verify(PublicKey, Provider) - S8200400: Restrict Sasl mechanisms - S8205445: Add RSASSA-PSS Signature support to SunMSCAPI - S8205720: KeyFactory#getKeySpec and translateKey throws NullPointerException with Invalid key - S8206171: Signature#getParameters for RSASSA-PSS throws ProviderException when not initialized - S8213009: Refactoring existing SunMSCAPI classes - S8213010: Supporting keys created with certmgr.exe - S8214096: sun.security.util.SignatureUtil passes null parameter, so JCE validation fails - S8215694: keytool cannot generate RSASSA-PSS certificates - S8216039: TLS with BC and RSASSA-PSS breaks ECDHServerKeyExchange - S8221407: Windows 32bit build error in libsunmscapi/security.cpp - S8223003: SunMSCAPI keys are not cleaned up - S8223063: Support CNG RSA keys - S8223158: Docked MacBook cannot start any Java Swing applications - S8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows - S8225392: Comparison builds are failing due to cacerts file - S8225745: NoSuchAlgorithmException exception for SHA256withECDSA with RSASSA-PSS support - S8229767: Typo in java.security: Sasl.createClient and Sasl.createServer - S8230977: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension (Java SE 8) - S8230978: Add support for RSASSA-PSS Signature algorithm (Java SE 8) - S8232019: Add LuxTrust certificate updates to the existing root program - S8233223: Add Amazon Root CA certificates - S8234245: sun/security/lib/cacerts/VerifyCACerts.java fails due to wrong checksum - S8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash algorithm as AlgorithmId - S8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION Main issue of note: None, clean merge (nearly all changes are in the JDK repo) 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/make/data/cacerts/amazonrootca1 | 27 b/make/data/cacerts/amazonrootca2 | 38 b/make/data/cacerts/amazonrootca3 | 19 b/make/data/cacerts/amazonrootca4 | 20 b/make/data/cacerts/luxtrustglobalroot2ca | 40 b/make/lib/SecurityLibraries.gmk | 4 b/make/src/classes/build/tools/generatecacerts/GenerateCacerts.java | 113 b/src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m | 14 b/src/share/classes/com/sun/crypto/provider/OAEPParameters.java | 6 b/src/share/classes/com/sun/crypto/provider/RSACipher.java | 14 b/src/share/classes/com/sun/crypto/provider/SunJCE.java | 6 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java | 10 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/IgnoreAllErrorHandler.java | 23 b/src/share/classes/java/security/Signature.java | 270 +- b/src/share/classes/java/security/SignatureSpi.java | 104 b/src/share/classes/java/security/cert/X509CRL.java | 35 b/src/share/classes/java/security/cert/X509Certificate.java | 27 b/src/share/classes/java/security/interfaces/RSAKey.java | 23 b/src/share/classes/java/security/interfaces/RSAMultiPrimePrivateCrtKey.java | 6 b/src/share/classes/java/security/interfaces/RSAPrivateCrtKey.java | 5 b/src/share/classes/java/security/interfaces/package-info.java | 4 b/src/share/classes/java/security/spec/MGF1ParameterSpec.java | 54 b/src/share/classes/java/security/spec/PSSParameterSpec.java | 144 - b/src/share/classes/java/security/spec/RSAKeyGenParameterSpec.java | 33 b/src/share/classes/java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java | 152 - b/src/share/classes/java/security/spec/RSAOtherPrimeInfo.java | 13 b/src/share/classes/java/security/spec/RSAPrivateCrtKeySpec.java | 46 b/src/share/classes/java/security/spec/RSAPrivateKeySpec.java | 32 b/src/share/classes/java/security/spec/RSAPublicKeySpec.java | 34 b/src/share/classes/java/security/spec/package-info.java | 4 b/src/share/classes/javax/crypto/Cipher.java | 8 b/src/share/classes/javax/crypto/spec/OAEPParameterSpec.java | 37 b/src/share/classes/javax/crypto/spec/PSource.java | 14 b/src/share/classes/javax/crypto/spec/package.html | 3 b/src/share/classes/javax/net/ssl/SSLEngine.java | 142 + b/src/share/classes/javax/net/ssl/SSLParameters.java | 85 b/src/share/classes/javax/net/ssl/SSLSocket.java | 142 + b/src/share/classes/javax/security/sasl/Sasl.java | 51 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java | 222 + b/src/share/classes/sun/java2d/marlin/MarlinCache.java | 25 b/src/share/classes/sun/java2d/marlin/MarlinConst.java | 2 b/src/share/classes/sun/misc/JavaSecuritySignatureAccess.java | 43 b/src/share/classes/sun/misc/SharedSecrets.java | 15 b/src/share/classes/sun/security/ec/CurveDB.java | 21 b/src/share/classes/sun/security/ec/ECDSASignature.java | 125 - b/src/share/classes/sun/security/krb5/KrbTgsRep.java | 9 b/src/share/classes/sun/security/krb5/internal/CredentialsUtil.java | 215 + b/src/share/classes/sun/security/krb5/internal/Krb5.java | 1 b/src/share/classes/sun/security/krb5/internal/PAForUserEnc.java | 4 b/src/share/classes/sun/security/krb5/internal/PaPacOptions.java | 185 + b/src/share/classes/sun/security/pkcs/SignerInfo.java | 33 b/src/share/classes/sun/security/pkcs10/PKCS10.java | 30 b/src/share/classes/sun/security/pkcs11/P11Key.java | 15 b/src/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java | 7 b/src/share/classes/sun/security/pkcs11/P11Signature.java | 29 b/src/share/classes/sun/security/provider/DSA.java | 18 b/src/share/classes/sun/security/provider/SHA5.java | 38 b/src/share/classes/sun/security/provider/SunEntries.java | 11 b/src/share/classes/sun/security/rsa/MGF1.java | 94 b/src/share/classes/sun/security/rsa/PSSParameters.java | 274 ++ b/src/share/classes/sun/security/rsa/RSAKeyFactory.java | 200 + b/src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java | 56 b/src/share/classes/sun/security/rsa/RSAPSSSignature.java | 619 +++++ b/src/share/classes/sun/security/rsa/RSAPadding.java | 73 b/src/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java | 97 b/src/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java | 45 b/src/share/classes/sun/security/rsa/RSAPublicKeyImpl.java | 90 b/src/share/classes/sun/security/rsa/RSASignature.java | 58 b/src/share/classes/sun/security/rsa/RSAUtil.java | 162 + b/src/share/classes/sun/security/rsa/SunRsaSignEntries.java | 40 b/src/share/classes/sun/security/ssl/ALPNExtension.java | 168 + b/src/share/classes/sun/security/ssl/Alerts.java | 8 b/src/share/classes/sun/security/ssl/CipherSuite.java | 893 ++++--- b/src/share/classes/sun/security/ssl/ClientHandshaker.java | 51 b/src/share/classes/sun/security/ssl/ExtensionType.java | 10 b/src/share/classes/sun/security/ssl/HandshakeMessage.java | 7 b/src/share/classes/sun/security/ssl/Handshaker.java | 47 b/src/share/classes/sun/security/ssl/HelloExtensions.java | 9 b/src/share/classes/sun/security/ssl/RSASignature.java | 15 b/src/share/classes/sun/security/ssl/SSLEngineImpl.java | 53 b/src/share/classes/sun/security/ssl/SSLServerSocketImpl.java | 10 b/src/share/classes/sun/security/ssl/SSLSocketImpl.java | 57 b/src/share/classes/sun/security/ssl/ServerHandshaker.java | 74 b/src/share/classes/sun/security/ssl/SunJSSE.java | 6 b/src/share/classes/sun/security/tools/keytool/CertAndKeyGen.java | 17 b/src/share/classes/sun/security/tools/keytool/Main.java | 39 b/src/share/classes/sun/security/util/ECUtil.java | 77 b/src/share/classes/sun/security/util/SecurityProviderConstants.java | 7 b/src/share/classes/sun/security/util/SignatureUtil.java | 171 + b/src/share/classes/sun/security/x509/AlgorithmId.java | 169 + b/src/share/classes/sun/security/x509/X509CRLImpl.java | 56 b/src/share/classes/sun/security/x509/X509CertImpl.java | 117 - b/src/share/lib/security/java.security-aix | 18 b/src/share/lib/security/java.security-linux | 18 b/src/share/lib/security/java.security-macosx | 18 b/src/share/lib/security/java.security-solaris | 18 b/src/share/lib/security/java.security-windows | 18 b/src/windows/classes/sun/security/mscapi/CKey.java | 158 - b/src/windows/classes/sun/security/mscapi/CKeyPair.java | 23 b/src/windows/classes/sun/security/mscapi/CKeyPairGenerator.java | 139 - b/src/windows/classes/sun/security/mscapi/CKeyStore.java | 203 - b/src/windows/classes/sun/security/mscapi/CPrivateKey.java | 67 b/src/windows/classes/sun/security/mscapi/CPublicKey.java | 292 +- b/src/windows/classes/sun/security/mscapi/CRSACipher.java | 30 b/src/windows/classes/sun/security/mscapi/CSignature.java | 782 +++++- b/src/windows/classes/sun/security/mscapi/SunMSCAPI.java | 83 b/src/windows/native/sun/security/mscapi/security.cpp | 1144 ++++++---- b/test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java | 50 b/test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java | 16 b/test/com/sun/crypto/provider/Cipher/RSA/TestOAEPParameterSpec.java | 6 b/test/com/sun/crypto/provider/Cipher/RSA/TestOAEPWithParams.java | 8 b/test/java/security/KeyPairGenerator/FinalizeHalf.java | 4 b/test/java/security/Signature/Offsets.java | 25 b/test/java/security/Signature/SignatureGetInstance.java | 238 ++ b/test/java/security/SignedObject/Chain.java | 73 b/test/java/security/cert/X509CRL/VerifyDefault.java | 133 + b/test/java/security/cert/X509Certificate/VerifyDefault.java | 139 + b/test/java/security/testlibrary/CertUtils.java | 103 b/test/javax/security/sasl/Sasl/DisabledMechanisms.java | 85 b/test/javax/xml/crypto/dsig/ErrorHandlerPermissions.java | 121 + b/test/javax/xml/crypto/dsig/ErrorHandlerPermissions.policy | 5 b/test/javax/xml/crypto/dsig/GenerationTests.java | 75 b/test/javax/xml/crypto/dsig/KeySelectors.java | 7 b/test/javax/xml/crypto/dsig/ValidationTests.java | 5 b/test/javax/xml/crypto/dsig/data/signature-enveloping-p256-sha1.xml | 3 b/test/javax/xml/crypto/dsig/data/signature-external-rsa.xml | 3 b/test/lib/jdk/test/lib/SigTestUtil.java | 150 + b/test/lib/testlibrary/jdk/testlibrary/security/DerUtils.java | 117 + b/test/sun/security/ec/SignedObjectChain.java | 5 b/test/sun/security/krb5/auto/KDC.java | 3 b/test/sun/security/krb5/auto/ReferralsTest.java | 129 - b/test/sun/security/lib/cacerts/VerifyCACerts.java | 22 b/test/sun/security/mscapi/InteropWithSunRsaSign.java | 171 + b/test/sun/security/mscapi/KeyAlgorithms.java | 79 b/test/sun/security/mscapi/NullKey.java | 55 b/test/sun/security/mscapi/SignedObjectChain.java | 5 b/test/sun/security/mscapi/VeryLongAlias.java | 134 + b/test/sun/security/provider/MessageDigest/SHA512.java | 70 b/test/sun/security/rsa/SigGen15_186-3.txt | 341 ++ b/test/sun/security/rsa/SigGen15_186-3_TruncatedSHAs.txt | 233 ++ b/test/sun/security/rsa/SigRecord.java | 198 + b/test/sun/security/rsa/SignatureOffsets.java | 8 b/test/sun/security/rsa/SignatureTest.java | 95 b/test/sun/security/rsa/SignedObjectChain.java | 10 b/test/sun/security/rsa/TestKeyPairGenerator.java | 45 b/test/sun/security/rsa/TestSigGen15.java | 125 + b/test/sun/security/rsa/TestSignatures.java | 56 b/test/sun/security/rsa/pss/InitAgain.java | 69 b/test/sun/security/rsa/pss/PSSParametersTest.java | 123 + b/test/sun/security/rsa/pss/SigGenPSS_186-3.txt | 420 +++ b/test/sun/security/rsa/pss/SigGenPSS_186-3_TruncatedSHAs.txt | 257 ++ b/test/sun/security/rsa/pss/SigRecord.java | 210 + b/test/sun/security/rsa/pss/SignatureTest2.java | 200 + b/test/sun/security/rsa/pss/SignatureTestPSS.java | 193 + b/test/sun/security/rsa/pss/TestPSSKeySupport.java | 152 + b/test/sun/security/rsa/pss/TestSigGenPSS.java | 155 + b/test/sun/security/ssl/javax/net/ssl/ALPN/MyX509ExtendedKeyManager.java | 138 + b/test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java | 583 +++++ b/test/sun/security/ssl/javax/net/ssl/ALPN/SSLServerSocketAlpnTest.java | 567 ++++ b/test/sun/security/ssl/javax/net/ssl/ALPN/SSLSocketAlpnTest.java | 563 ++++ b/test/sun/security/ssl/rsa/SignedObjectChain.java | 7 b/test/sun/security/ssl/templates/SSLEngineTemplate.java | 20 b/test/sun/security/ssl/templates/SSLSocketSSLEngineTemplate.java | 18 b/test/sun/security/ssl/templates/SSLSocketTemplate.java | 8 b/test/sun/security/tools/keytool/ListOrder.java | 64 b/test/sun/security/tools/keytool/PSS.java | 104 b/test/sun/security/util/misc/SetNullSigParams.java | 77 b/test/sun/security/x509/X509CertImpl/ECSigParamsVerifyWithCert.java | 91 169 files changed, 14372 insertions(+), 2528 deletions(-) diffstat for hotspot b/.hgtags | 1 b/test/compiler/intrinsics/bmi/TestAndnI.java | 36 +++++++++++--- b/test/compiler/intrinsics/bmi/TestAndnL.java | 36 +++++++++++--- b/test/compiler/intrinsics/bmi/verifycode/AndnTestI.java | 14 ++--- b/test/compiler/intrinsics/bmi/verifycode/AndnTestL.java | 14 ++--- b/test/compiler/intrinsics/bmi/verifycode/LZcntTestI.java | 2 b/test/compiler/intrinsics/bmi/verifycode/LZcntTestL.java | 2 b/test/compiler/intrinsics/bmi/verifycode/TZcntTestI.java | 2 b/test/compiler/intrinsics/bmi/verifycode/TZcntTestL.java | 2 9 files changed, 83 insertions(+), 26 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 rkennke at redhat.com Fri Feb 21 20:44:02 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 21 Feb 2020 21:44:02 +0100 Subject: RFR (sh/8): Backport: JDK-8222766: Shenandoah: streamline post-LRB CAS barrier (x86) Message-ID: <10e86fb9-6810-7541-2c23-0741a2b6e863@redhat.com> This is the backport for "JDK-8222766: Shenandoah: streamline post-LRB CAS barrier (x86)" It is mostly straightforward in the assembler parts. It does some extra changes in C1 parts, because the way jdk8-C1 generates cas-obj is a bit funny: the assembler parts generate the CAS instruction, and then in the C1 IR this is followed by a cmove to move the correct boolean bits into the result register. There is an implicit dependency between the asm and the IR via the condition flags. Unfortunately, our new cas-obj assembly doesn't always exit with condition flags intact. But we *do* have code to fill the result register. So we should use that. The C1 adjustments pass the result register to the CAS instruction and use that directly and skip emitting the trailing cmove in IR. Testing: hotspot_gc_shenandoah passes Might be useful if Aleksey or somebody else could run this on 32bit. My own 32bit setup seems broken ATM. http://cr.openjdk.java.net/~rkennke/JDK-8222766-jdk8/webrev.00/ Please review carefully. Thanks, Roman From kirill at korins.ky Sun Feb 23 15:01:54 2020 From: kirill at korins.ky (Kirill A. Korinsky) Date: Sun, 23 Feb 2020 16:01:54 +0100 Subject: Probably a bug In-Reply-To: References: Message-ID: I see that a new build is available at shipilev/openjdk-shenandoah. I've tried the last: Step 1/19 : FROM shipilev/openjdk-shenandoah:8-fastdebug 8-fastdebug: Pulling from shipilev/openjdk-shenandoah 6f2295d35e78: Pull complete f9939b5dfdd6: Pull complete 89e73a891426: Pull complete Digest: sha256:530547249752996bb7a88ec4970b97d58d0c3c525c8ae52a3f1e24dffc6d547d Status: Downloaded newer image for shipilev/openjdk-shenandoah:8-fastdebug ---> 09d8eb00cc65 and would like to confirm that the bug still exists. -- wbr, Kirill > On 17. Feb 2020, at 15:59, Kirill A. Korinsky wrote: > > Good day, > > I'd like to ask for advice because it looks like I've discovered something that might be related to Shenandoah bug. > > I haven't got any proof that it is inside Shenandoah, nor a simple test case to reproduce it. > > It appears inside Akka and you can read my hunting with Akka team here: https://github.com/akka/akka/issues/28601 > > As summary: > - it appears as infinite loop inside Akka queue that is lock-free linked-queue that's implemented via getObjectVolatile(), getAndSet() and few more atomic/unsafe calls. > - if I've enabled any debugging such as XX:+ShenandoahVerify the bug is disappear => I can't provide any hs_err_log :( > - it exists on OpenJDK-8 from fedora 31 and at shipilev/openjdk-shenandoah:8-fastdebug > - it is very difficult to achieve and it is very fragile. In real life, it appears only at one and bigger cluster, at my synthetic test case it requires to bootstrap an application and uses the unreachable Akka system > - to achieve this bug I should have a lot of garbage inside heap that produced by bootstrapping an application when it builds its index. The index has size 0,5gb..1gb (and the heap is 2gb) and the size depends on DB that is continuously updating, and the bug is achievable at any possibly size of the index. > - if I switch to G1 for example it disappears. > > Right now I have two possible sources of this bug: > - very strange race condition inside Akka. > - a bug inside Shenandoah that is related to the missed barrier or deeper. > > To eliminate or confirm Shenandoah related possibility I need some advice on how to do it because I can't prepare easy to reproduce code :( > > -- > wbr, Kirill > From shade at redhat.com Sun Feb 23 22:23:55 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Sun, 23 Feb 2020 23:23:55 +0100 Subject: [RFR] [8u] 8u252-b03 Upstream Sync In-Reply-To: References: Message-ID: <2ebb22a8-842b-ee0e-720d-8e6d5b25e693@redhat.com> On 2/21/20 7:28 PM, Andrew Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/ > > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/jaxws/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/jdk/merge.changeset Lots of changes. I skimmed only briefly through them. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b03/root/merge.changeset Looks trivially good. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From kirill at korins.ky Mon Feb 24 00:48:00 2020 From: kirill at korins.ky (Kirill A. Korinsky) Date: Mon, 24 Feb 2020 01:48:00 +0100 Subject: Probably a bug In-Reply-To: References: Message-ID: I've played with -XX:ShenandoahVerifyLevel and I can't reproduce a bug with level 0, 1 and 2 but as soon as I increased it to 3 it appears. Without any hs_err. -- wbr, Kirill > On 23. Feb 2020, at 16:01, Kirill A. Korinsky wrote: > > I see that a new build is available at shipilev/openjdk-shenandoah. > > I've tried the last: > > Step 1/19 : FROM shipilev/openjdk-shenandoah:8-fastdebug > 8-fastdebug: Pulling from shipilev/openjdk-shenandoah > 6f2295d35e78: Pull complete > f9939b5dfdd6: Pull complete > 89e73a891426: Pull complete > Digest: sha256:530547249752996bb7a88ec4970b97d58d0c3c525c8ae52a3f1e24dffc6d547d > Status: Downloaded newer image for shipilev/openjdk-shenandoah:8-fastdebug > ---> 09d8eb00cc65 > > and would like to confirm that the bug still exists. > > -- > wbr, Kirill > >> On 17. Feb 2020, at 15:59, Kirill A. Korinsky > wrote: >> >> Good day, >> >> I'd like to ask for advice because it looks like I've discovered something that might be related to Shenandoah bug. >> >> I haven't got any proof that it is inside Shenandoah, nor a simple test case to reproduce it. >> >> It appears inside Akka and you can read my hunting with Akka team here: https://github.com/akka/akka/issues/28601 >> >> As summary: >> - it appears as infinite loop inside Akka queue that is lock-free linked-queue that's implemented via getObjectVolatile(), getAndSet() and few more atomic/unsafe calls. >> - if I've enabled any debugging such as XX:+ShenandoahVerify the bug is disappear => I can't provide any hs_err_log :( >> - it exists on OpenJDK-8 from fedora 31 and at shipilev/openjdk-shenandoah:8-fastdebug >> - it is very difficult to achieve and it is very fragile. In real life, it appears only at one and bigger cluster, at my synthetic test case it requires to bootstrap an application and uses the unreachable Akka system >> - to achieve this bug I should have a lot of garbage inside heap that produced by bootstrapping an application when it builds its index. The index has size 0,5gb..1gb (and the heap is 2gb) and the size depends on DB that is continuously updating, and the bug is achievable at any possibly size of the index. >> - if I switch to G1 for example it disappears. >> >> Right now I have two possible sources of this bug: >> - very strange race condition inside Akka. >> - a bug inside Shenandoah that is related to the missed barrier or deeper. >> >> To eliminate or confirm Shenandoah related possibility I need some advice on how to do it because I can't prepare easy to reproduce code :( >> >> -- >> wbr, Kirill >> > From shade at redhat.com Mon Feb 24 10:17:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 24 Feb 2020 11:17:06 +0100 Subject: RFR (sh/8): Backport: JDK-8222766: Shenandoah: streamline post-LRB CAS barrier (x86) In-Reply-To: <10e86fb9-6810-7541-2c23-0741a2b6e863@redhat.com> References: <10e86fb9-6810-7541-2c23-0741a2b6e863@redhat.com> Message-ID: On 2/21/20 9:44 PM, Roman Kennke wrote: > Unfortunately, our new cas-obj assembly doesn't always exit with > condition flags intact. But we *do* have code to fill the result > register. So we should use that. The C1 adjustments pass the result > register to the CAS instruction and use that directly and skip emitting > the trailing cmove in IR. Ha. So this was the testing culprit? 797 __ cas_obj(addr, cmp.result(), val.result(), new_register(T_OBJECT), new_register(T_OBJECT), result); 798 return; <--- ouch Suggestion: __ cas_obj(addr, cmp.result(), val.result(), new_register(T_OBJECT), new_register(T_OBJECT), result); // Shenandoah C1 barrier would do all result management itself, shortcut here. return; > Testing: hotspot_gc_shenandoah passes > Might be useful if Aleksey or somebody else could run this on 32bit. My > own 32bit setup seems broken ATM. My cross-compilation setup is also a bit broken, so two native tests cannot compile and run: FAILED: gc/shenandoah/jni/TestCriticalNativeArgs.sh FAILED: gc/shenandoah/jni/TestCriticalNativeStress.sh This is not caused by the patch, and I don't believe those tests would be affected anyway. > http://cr.openjdk.java.net/~rkennke/JDK-8222766-jdk8/webrev.00/ The shenandoahBarrierSetAssembler_x86.cpp change was transplated as is, right? I did not spot substantial differences against jdk/jdk, except minor changes around gc_state access and mark word constants. Looks good. -- Thanks, -Aleksey From rkennke at redhat.com Mon Feb 24 10:35:45 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 24 Feb 2020 11:35:45 +0100 Subject: RFR (sh/8): Backport: JDK-8222766: Shenandoah: streamline post-LRB CAS barrier (x86) In-Reply-To: References: <10e86fb9-6810-7541-2c23-0741a2b6e863@redhat.com> Message-ID: <6d6e49c4-8e01-5a9c-99bd-ddee669b49a0@redhat.com> >> Unfortunately, our new cas-obj assembly doesn't always exit with >> condition flags intact. But we *do* have code to fill the result >> register. So we should use that. The C1 adjustments pass the result >> register to the CAS instruction and use that directly and skip emitting >> the trailing cmove in IR. > > Ha. So this was the testing culprit? > > 797 __ cas_obj(addr, cmp.result(), val.result(), new_register(T_OBJECT), > new_register(T_OBJECT), result); > 798 return; <--- ouch No. Or, well, kinda. The testing culprit was that my original attempt was lacking the ShenandoahCASBarrier check: + if (UseShenandoahGC && ShenandoahCASBarrier) { <- here + LIR_Opr result = rlock_result(x); + __ cas_obj(addr, cmp.result(), val.result(), new_register(T_OBJECT), new_register(T_OBJECT), result); + return; } else And thus, when running with passive mode, it would generate the CAS IR normally and return (omitting the trailing cmove). Then in LIRAssembler, it would skip generating the Shenandoah CAS and emit the normal CAS -- without the trailing cmove. It's all quite a mess and I'm very happy we have gotten rid of it in 11+. > Suggestion: > > __ cas_obj(addr, cmp.result(), val.result(), new_register(T_OBJECT), new_register(T_OBJECT), result); > // Shenandoah C1 barrier would do all result management itself, shortcut here. > return; I'll add the comment. >> Testing: hotspot_gc_shenandoah passes >> Might be useful if Aleksey or somebody else could run this on 32bit. My >> own 32bit setup seems broken ATM. > > My cross-compilation setup is also a bit broken, so two native tests cannot compile and run: > FAILED: gc/shenandoah/jni/TestCriticalNativeArgs.sh > FAILED: gc/shenandoah/jni/TestCriticalNativeStress.sh > > This is not caused by the patch, and I don't believe those tests would be affected anyway. > >> http://cr.openjdk.java.net/~rkennke/JDK-8222766-jdk8/webrev.00/ > > The shenandoahBarrierSetAssembler_x86.cpp change was transplated as is, right? I did not spot > substantial differences against jdk/jdk, except minor changes around gc_state access and mark word > constants. Yes, other than those it's pretty much copy+paste from 11u. Notice that in 8, we don't actually need the exchange path(s) - they don't exist/are never used. I left them in for the sake of keeping the code equivalent with 11. Roman From shade at redhat.com Mon Feb 24 10:38:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 24 Feb 2020 11:38:00 +0100 Subject: RFR (sh/8): Backport: JDK-8222766: Shenandoah: streamline post-LRB CAS barrier (x86) In-Reply-To: <6d6e49c4-8e01-5a9c-99bd-ddee669b49a0@redhat.com> References: <10e86fb9-6810-7541-2c23-0741a2b6e863@redhat.com> <6d6e49c4-8e01-5a9c-99bd-ddee669b49a0@redhat.com> Message-ID: <9961ac08-91ad-6024-801a-64b354490f09@redhat.com> On 2/24/20 11:35 AM, Roman Kennke wrote: > And thus, when running with passive mode, it would generate the CAS IR > normally and return (omitting the trailing cmove). Then in LIRAssembler, > it would skip generating the Shenandoah CAS and emit the normal CAS -- > without the trailing cmove. It's all quite a mess and I'm very happy we > have gotten rid of it in 11+. Ugh. > Notice that in 8, we don't actually need the exchange path(s) - they > don't exist/are never used. I left them in for the sake of keeping the > code equivalent with 11. Yes, that makes sense. -- Thanks, -Aleksey From j at giedres.lt Mon Feb 24 11:43:55 2020 From: j at giedres.lt (Justinas Dabravolskas) Date: Mon, 24 Feb 2020 13:43:55 +0200 Subject: Reporting of gc+stats In-Reply-To: <09c4121e-3ecb-f9b5-8e97-9836bf1cbc8a@redhat.com> References: <16fc8faf832.f9f854ae483598.4097291411583541475@giedres.lt> <09c4121e-3ecb-f9b5-8e97-9836bf1cbc8a@redhat.com> Message-ID: <1707702c5a9.119954d9d461145.3762772288126085738@giedres.lt> Hello Roman, ---- On Fri, 21 Feb 2020 15:24:24 +0200 Roman Kennke wrote ---- > Hello Justinas, > > I apologize for the late reply. > > > hope this is the right place to ask a few more questions. Sorry if answers were simply overlooked. > > Sure, here is perfect. We usually don't take so long to reply. :-) > > > 1. I can't find an option for periodic printing of pacer statistics. (gc+stats prints just on exit?) > > Pacers activity looks like the first indication of gc pressure. Don't you think it would be useful to get this information from gc log asap? > > Maybe you can introduce ShenandoahPacerStatsPeriod flag for periodic printing of _delays histogram? > > That sounds like a good idea. We may actually want more more general > periodic statistics, not only about pacing. I filed the following bug > about it: > > https://bugs.openjdk.java.net/browse/JDK-8239786 Thank you, additional statistics sounds great and it will help identify gc related issues. > > > 1. How to interpret breakdown of roots scanning? > > e.g.: "Scan Roots" took 327s, but I can't figure out what part exactly from breakdown. What I am missing? > > the individual parts 'S: *' are averages over all workers. That means if > one tasks (here: CLDG Roots) is not very well parallelized, it will > report a low average. Consider what will happen if it's perfectly > serial, and we have 4 workers, 1 worker needs 320ms, but the others are > basically idle or get almost no work. It will average to 80ms, but the > total (reported in "Scan Roots") will add-up to 320+ms. We realize this > is confusing and we should improve this. > > Does that answer your question? It does. Though it is not obvious how to estimate actual impact of sub-phases to pause time from current log format. Regards, Justinas > > Thank you, > Roman > > > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Pause Init Mark (N) = 338.46 s (a = 51057 us) (n = 6629) (lvls, us = 4023, 45508, 50781, 56641, 88198) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Accumulate Stats = 1.42 s (a = 214 us) (n = 6629) (lvls, us = 33, 182, 209, 236, 3329) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Make Parsable = 6.10 s (a = 920 us) (n = 6629) (lvls, us = 55, 732, 891, 1074, 6075) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Clear Liveness = 1.29 s (a = 195 us) (n = 6629) (lvls, us = 91, 168, 189, 211, 3251) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Scan Roots = 327.02 s (a = 49332 us) (n = 6629) (lvls, us = 3613, 43945, 49023, 54688, 86252) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: Thread Roots = 6.68 s (a = 1008 us) (n = 6629) (lvls, us = 137, 869, 994, 1113, 9622) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: Universe Roots = 0.08 s (a = 12 us) (n = 6629) (lvls, us = 2, 8, 9, 13, 4443) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: JNI Roots = 0.37 s (a = 55 us) (n = 6629) (lvls, us = 4, 37, 46, 59, 8601) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: Synchronizer Roots = 0.00 s (a = 1 us) (n = 6629) (lvls, us = 0, 0, 0, 1, 22) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: Management Roots = 0.06 s (a = 8 us) (n = 6629) (lvls, us = 1, 3, 8, 11, 102) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: System Dict Roots = 0.54 s (a = 81 us) (n = 6629) (lvls, us = 16, 61, 74, 89, 4439) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: CLDG Roots = 80.66 s (a = 12167 us) (n = 6629) (lvls, us = 811, 9004, 11133, 14453, 27327) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] S: JVMTI Roots = 0.50 s (a = 75 us) (n = 6629) (lvls, us = 7, 48, 62, 79, 12281) > > [2020-01-21T07:33:24.757-0500][info ][gc,stats ] Resize TLABs = 0.95 s (a = 143 us) (n = 6629) (lvls, us = 7, 104, 133, 172, 1513) > > > > From shade at redhat.com Mon Feb 24 16:12:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 24 Feb 2020 17:12:00 +0100 Subject: RFR (XS) 8239868: Shenandoah: ditch C2 node limit adjustments Message-ID: <8eeac17f-a6ed-18c1-ef90-667e692e309a@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8239868 We have the block added to Shenandoah arguments code that adjusts MaxNodeLimit and friends (predates inclusion of Shenandoah into mainline): https://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-August/006983.html At the time, it was prompted by observing that lots of barriers everywhere really needed to have this limit bumped. Today, with simplified LRB scheme, more simple LRB due to SFX, etc, we do not need this. The change above used ShenandoahCompileCheck, which made it into upstream code under generic AbortVMOnCompilationFailure. With that, I was able to verify that dropping the block does not yield compilation failures due to exceeded node budget on hotspot_gc_shenandoah, specjvm2008, specjbb2015. Performance numbers are also not affected (as expected). Therefore, the adjustment can be removed: diff -r 5c5dcd036a76 src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Mon Feb 24 11:01:51 2020 +0100 +++ b/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Mon Feb 24 17:09:58 2020 +0100 @@ -193,13 +193,4 @@ } - // Shenandoah needs more C2 nodes to compile some methods with lots of barriers. - // NodeLimitFudgeFactor needs to stay the same relative to MaxNodeLimit. -#ifdef COMPILER2 - if (FLAG_IS_DEFAULT(MaxNodeLimit)) { - FLAG_SET_DEFAULT(MaxNodeLimit, MaxNodeLimit * 3); - FLAG_SET_DEFAULT(NodeLimitFudgeFactor, NodeLimitFudgeFactor * 3); - } -#endif - // Make sure safepoint deadlocks are failing predictably. This sets up VM to report // fatal error after 10 seconds of wait for safepoint syncronization (not the VM Testing: hotspot_gc_shenandoah; benchmarks, +AbortVMOnCompilationFailure testing -- Thanks, -Aleksey From rkennke at redhat.com Mon Feb 24 16:22:50 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 24 Feb 2020 17:22:50 +0100 Subject: RFR (XS) 8239868: Shenandoah: ditch C2 node limit adjustments In-Reply-To: <8eeac17f-a6ed-18c1-ef90-667e692e309a@redhat.com> References: <8eeac17f-a6ed-18c1-ef90-667e692e309a@redhat.com> Message-ID: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8239868 > > We have the block added to Shenandoah arguments code that adjusts MaxNodeLimit and friends (predates > inclusion of Shenandoah into mainline): > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-August/006983.html > > At the time, it was prompted by observing that lots of barriers everywhere really needed to have > this limit bumped. Today, with simplified LRB scheme, more simple LRB due to SFX, etc, we do not > need this. > > The change above used ShenandoahCompileCheck, which made it into upstream code under generic > AbortVMOnCompilationFailure. With that, I was able to verify that dropping the block does not yield > compilation failures due to exceeded node budget on hotspot_gc_shenandoah, specjvm2008, specjbb2015. > Performance numbers are also not affected (as expected). > > Therefore, the adjustment can be removed: > > diff -r 5c5dcd036a76 src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Mon Feb 24 11:01:51 2020 +0100 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Mon Feb 24 17:09:58 2020 +0100 > @@ -193,13 +193,4 @@ > } > > - // Shenandoah needs more C2 nodes to compile some methods with lots of barriers. > - // NodeLimitFudgeFactor needs to stay the same relative to MaxNodeLimit. > -#ifdef COMPILER2 > - if (FLAG_IS_DEFAULT(MaxNodeLimit)) { > - FLAG_SET_DEFAULT(MaxNodeLimit, MaxNodeLimit * 3); > - FLAG_SET_DEFAULT(NodeLimitFudgeFactor, NodeLimitFudgeFactor * 3); > - } > -#endif > - > // Make sure safepoint deadlocks are failing predictably. This sets up VM to report > // fatal error after 10 seconds of wait for safepoint syncronization (not the VM > > Testing: hotspot_gc_shenandoah; benchmarks, +AbortVMOnCompilationFailure testing Ok. Thank you! Roman From kirill at korins.ky Mon Feb 24 22:22:41 2020 From: kirill at korins.ky (Kirill A. Korinsky) Date: Mon, 24 Feb 2020 23:22:41 +0100 Subject: Probably a bug In-Reply-To: References: Message-ID: <1F09634F-0642-4DE5-AAB6-C9035238ABF8@korins.ky> After playing really a while I've created a very trivial test case: https://github.com/catap/shenandoah-akka-bug It will exit from JVM with code 66 as soon as it got this bug. -- wbr, Kirill > On 24. Feb 2020, at 01:48, Kirill A. Korinsky wrote: > > I've played with -XX:ShenandoahVerifyLevel and I can't reproduce a bug with level 0, 1 and 2 but as soon as I increased it to 3 it appears. > > Without any hs_err. > > > -- > wbr, Kirill > >> On 23. Feb 2020, at 16:01, Kirill A. Korinsky > wrote: >> >> I see that a new build is available at shipilev/openjdk-shenandoah. >> >> I've tried the last: >> >> Step 1/19 : FROM shipilev/openjdk-shenandoah:8-fastdebug >> 8-fastdebug: Pulling from shipilev/openjdk-shenandoah >> 6f2295d35e78: Pull complete >> f9939b5dfdd6: Pull complete >> 89e73a891426: Pull complete >> Digest: sha256:530547249752996bb7a88ec4970b97d58d0c3c525c8ae52a3f1e24dffc6d547d >> Status: Downloaded newer image for shipilev/openjdk-shenandoah:8-fastdebug >> ---> 09d8eb00cc65 >> >> and would like to confirm that the bug still exists. >> >> -- >> wbr, Kirill >> >>> On 17. Feb 2020, at 15:59, Kirill A. Korinsky > wrote: >>> >>> Good day, >>> >>> I'd like to ask for advice because it looks like I've discovered something that might be related to Shenandoah bug. >>> >>> I haven't got any proof that it is inside Shenandoah, nor a simple test case to reproduce it. >>> >>> It appears inside Akka and you can read my hunting with Akka team here: https://github.com/akka/akka/issues/28601 >>> >>> As summary: >>> - it appears as infinite loop inside Akka queue that is lock-free linked-queue that's implemented via getObjectVolatile(), getAndSet() and few more atomic/unsafe calls. >>> - if I've enabled any debugging such as XX:+ShenandoahVerify the bug is disappear => I can't provide any hs_err_log :( >>> - it exists on OpenJDK-8 from fedora 31 and at shipilev/openjdk-shenandoah:8-fastdebug >>> - it is very difficult to achieve and it is very fragile. In real life, it appears only at one and bigger cluster, at my synthetic test case it requires to bootstrap an application and uses the unreachable Akka system >>> - to achieve this bug I should have a lot of garbage inside heap that produced by bootstrapping an application when it builds its index. The index has size 0,5gb..1gb (and the heap is 2gb) and the size depends on DB that is continuously updating, and the bug is achievable at any possibly size of the index. >>> - if I switch to G1 for example it disappears. >>> >>> Right now I have two possible sources of this bug: >>> - very strange race condition inside Akka. >>> - a bug inside Shenandoah that is related to the missed barrier or deeper. >>> >>> To eliminate or confirm Shenandoah related possibility I need some advice on how to do it because I can't prepare easy to reproduce code :( >>> >>> -- >>> wbr, Kirill >>> >> > From shade at redhat.com Tue Feb 25 08:05:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Feb 2020 09:05:03 +0100 Subject: RFR (S) 8239904: Shenandoah: accumulated penalties should not be over 100% of capacity Message-ID: <2b73bc42-1d5b-1277-a6b2-382acf660ea2@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8239904 See details in the bug. Fix: https://cr.openjdk.java.net/~shade/8239904/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Tue Feb 25 09:37:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Feb 2020 10:37:21 +0100 Subject: Probably a bug In-Reply-To: <1F09634F-0642-4DE5-AAB6-C9035238ABF8@korins.ky> References: <1F09634F-0642-4DE5-AAB6-C9035238ABF8@korins.ky> Message-ID: <2237c245-dcaf-b635-79a7-c1e70e515c54@redhat.com> On 2/24/20 11:22 PM, Kirill A. Korinsky wrote: > After playing really a while I've created a very trivial test case: https://github.com/catap/shenandoah-akka-bug Thank you. It can be run without docker-compose with just a naked JDK binary. This reliably fails with Future timeout for me: $ mvn package $ cd target/shenandoah-akka-bug-1.0.0-dist/shenandoah-akka-bug-1.0.0 $ EXTERNAL_ADDR=127.0.0.1 ~/trunks/shenandoah-jdk8/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java -Xmx1g -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=aggressive -XX:TieredStopAtLevel=1 -jar bin/shenandoah-akka-bug-1.0.0.jar What it seems to tell me: a) It fails only with -XX:TieredStopAtLevel=1. It does not seem to fail with -Xint or -XX:-TieredCompilation, which suggests this is C1 problem; b) It does not seem to fail with -XX:ShenandoahGCMode=passive, which suggests this trouble is somewhere in Shenandoah C1 barriers or around it; c) It does not fail with -XX:ShenandoahGCMode=passive and all barriers enabled back, which suggests it is somewhere in the mid/slowpath of Shenandoah C1 barrier. -- Thanks, -Aleksey From rkennke at redhat.com Tue Feb 25 11:29:41 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 25 Feb 2020 12:29:41 +0100 Subject: RFR (S) 8239904: Shenandoah: accumulated penalties should not be over 100% of capacity In-Reply-To: <2b73bc42-1d5b-1277-a6b2-382acf660ea2@redhat.com> References: <2b73bc42-1d5b-1277-a6b2-382acf660ea2@redhat.com> Message-ID: Yes, looks good! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8239904 > > See details in the bug. > > Fix: > https://cr.openjdk.java.net/~shade/8239904/webrev.01/ > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Tue Feb 25 11:55:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Feb 2020 12:55:19 +0100 Subject: [8, 11] RFC: [backport] 8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411 Message-ID: <32b17cff-c678-29d4-24cb-b5f66438123b@redhat.com> This had slipped under our backporting radar, because it had no relevant affected versions: https://bugs.openjdk.java.net/browse/JDK-8235636? It looks like triggered by JDK-8226411, but the actual issue is generic. Applying that patch over 8u seems to resolve some of the Cassandra crashes I have been chasing recently. OK to backport to 8u/11u? 11u applies cleanly. 8u applies with reshuffling Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Tue Feb 25 11:59:04 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 25 Feb 2020 12:59:04 +0100 Subject: [8, 11] RFC: [backport] 8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411 In-Reply-To: <32b17cff-c678-29d4-24cb-b5f66438123b@redhat.com> References: <32b17cff-c678-29d4-24cb-b5f66438123b@redhat.com> Message-ID: <5836a66e-162f-8784-a52c-a3ad950ddddc@redhat.com> Good by me! Roman > This had slipped under our backporting radar, because it had no relevant affected versions: > https://bugs.openjdk.java.net/browse/JDK-8235636? > > It looks like triggered by JDK-8226411, but the actual issue is generic. Applying that patch over 8u > seems to resolve some of the Cassandra crashes I have been chasing recently. > > OK to backport to 8u/11u? 11u applies cleanly. 8u applies with reshuffling > > Testing: hotspot_gc_shenandoah > From zgu at redhat.com Tue Feb 25 17:13:03 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 25 Feb 2020 12:13:03 -0500 Subject: [15] RFR 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata Message-ID: <75c20855-5234-ba00-f07b-f9da0f7b8047@redhat.com> Shenandoah encounters a few test failures with tools/javac. Verifier catches unmarked oops in nmethod's metadata during root evacuation in final mark phase. The problem is that, Shenandoah marks on stack nmethods in init mark pause, but it does not mark nmethod's metadata during concurrent mark phase, when new nmethod is about to be executed. The solution: 1) Use nmethod_entry_barrier to keep nmethod's metadata alive when the nmethod is about to be executed, when nmethod entry barrier is supported. 2) Remark on stack nmethod's metadata at final mark pause. Bug: https://bugs.openjdk.java.net/browse/JDK-8239926 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8239926/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) tools/javac with ShenandoahCodeRootsStyle = 1 and 2 (fastdebug and release) Thanks, -Zhengyu From shade at redhat.com Tue Feb 25 17:22:41 2020 From: shade at redhat.com (shade at redhat.com) Date: Tue, 25 Feb 2020 17:22:41 +0000 Subject: hg: shenandoah/jdk8/hotspot: [backport] 8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411 Message-ID: <202002251722.01PHMfma007554@aojmv0008.oracle.com> Changeset: 9c948e9fa41e Author: roland Date: 2019-12-06 16:21 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9c948e9fa41e [backport] 8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp From shade at redhat.com Tue Feb 25 18:56:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Feb 2020 19:56:06 +0100 Subject: Shenandoah JDK 8 backport crashes when running Cassandra In-Reply-To: <60cb3e90-59a9-73be-db99-336deb4d37ef@redhat.com> References: <60cb3e90-59a9-73be-db99-336deb4d37ef@redhat.com> Message-ID: <91983bfb-b53e-41e8-4dc0-71c47dbb6986@redhat.com> On 2/5/20 3:43 PM, Aleksey Shipilev wrote: > How reproducible is this? Are there specific steps to reproduce? Follow-up: Amir had graciously provided us the minimized example that crashes after about a minute of run. While working on this, we discovered a few interesting minor, but unrelated upstream bugs, which were requested for upstream 8u backports, sh/jdk8 would pick them up eventually. While digging through the generated code, we discovered weird interaction with Unsafe methods. To level out the field, we did a few missing backports in related areas ahead of other work. That did not help directly, but helped our sanity. In the end, we have minimized it to C2 compilation problem: the issue was reproducible with -XX:ShenandoahGCMode=passive -XX:+ShenandoahLoadRefBarrier -XX:-TieredCompilation, and it failed either in C2- or C1-generated code. The root cause seems to be C2 optimizer compiling some code incorrectly. We have discovered the issue there recently, fixed it in 14, but it was mistakenly omitted from the backporting roll. Once we did backport it to 8u and 11u: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011511.html ...the crash reproducer stopped crashing. At least 200+ runs passed without problems, whereas it failed at about 5-th run before this fix. If you are running sh/jdk8 nigthlies, then b574 onwards has it: $ curl https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-x86_64-release.tar.xz | tar xJf - $ j2sdk-image/bin/java -version openjdk version "1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8" OpenJDK Runtime Environment (build 1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8-b574-20200225) OpenJDK 64-Bit Server VM (build 25.71-b574-20200225, mixed mode) $ grep 8235636 j2sdk-image/bom-changesets-hotspot.log summary: [backport] 8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411 -- Thanks, -Aleksey From shade at redhat.com Tue Feb 25 19:57:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Feb 2020 20:57:37 +0100 Subject: [8] RFR: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject Message-ID: <4c727062-66e2-de6a-891a-2312941bb431@redhat.com> This seems to be the cause of the problem that Kirill minimized [1]. In short, the LRB in CAS barrier slowpath was plugged in incorrectly. This caused the bug in the rare circumstances: evacuating the object that is in the middle of getAndSet'ing would still reference the "old" object on some paths. Most of the time it "works", because the object is left untouched. Fix: diff -r 9c948e9fa41e src/cpu/x86/vm/c1_LIRGenerator_x86.cpp --- a/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Fri Dec 06 16:21:26 2019 -0500 +++ b/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Tue Feb 25 20:53:24 2020 +0100 @@ -1501,14 +1501,12 @@ } __ xchg(LIR_OprFact::address(addr), dst, dst, LIR_OprFact::illegalOpr); #if INCLUDE_ALL_GCS if (UseShenandoahGC && is_obj) { - dst = ShenandoahBarrierSet::barrier_set()->bsc1()->load_reference_barrier(this, dst, NULL, true); - LIR_Opr tmp = new_register(type); - __ move(dst, tmp); - dst = tmp; + LIR_Opr tmp = ShenandoahBarrierSet::barrier_set()->bsc1()->load_reference_barrier(this, dst, NULL, true); + __ move(tmp, dst); } #endif if (is_obj) { // Seems to be a precise address Testing: hotspot_gc_shenandoah, Kirill's reproducer -- Thanks, -Aleksey [1] https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011509.html From rkennke at redhat.com Tue Feb 25 20:02:14 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 25 Feb 2020 21:02:14 +0100 Subject: [8] RFR: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject In-Reply-To: <4c727062-66e2-de6a-891a-2312941bb431@redhat.com> References: <4c727062-66e2-de6a-891a-2312941bb431@redhat.com> Message-ID: > This seems to be the cause of the problem that Kirill minimized [1]. > > In short, the LRB in CAS barrier slowpath was plugged in incorrectly. This caused the bug in the > rare circumstances: evacuating the object that is in the middle of getAndSet'ing would still > reference the "old" object on some paths. Most of the time it "works", because the object is left > untouched. > > Fix: > > diff -r 9c948e9fa41e src/cpu/x86/vm/c1_LIRGenerator_x86.cpp > --- a/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Fri Dec 06 16:21:26 2019 -0500 > +++ b/src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Tue Feb 25 20:53:24 2020 +0100 > @@ -1501,14 +1501,12 @@ > } > __ xchg(LIR_OprFact::address(addr), dst, dst, LIR_OprFact::illegalOpr); > > #if INCLUDE_ALL_GCS > if (UseShenandoahGC && is_obj) { > - dst = ShenandoahBarrierSet::barrier_set()->bsc1()->load_reference_barrier(this, dst, NULL, true); > - LIR_Opr tmp = new_register(type); > - __ move(dst, tmp); > - dst = tmp; > + LIR_Opr tmp = ShenandoahBarrierSet::barrier_set()->bsc1()->load_reference_barrier(this, dst, > NULL, true); > + __ move(tmp, dst); > } > #endif > > if (is_obj) { > // Seems to be a precise address > > > Testing: hotspot_gc_shenandoah, Kirill's reproducer Looks good! Thank you! Roman From shade at redhat.com Tue Feb 25 20:10:48 2020 From: shade at redhat.com (shade at redhat.com) Date: Tue, 25 Feb 2020 20:10:48 +0000 Subject: hg: shenandoah/jdk8/hotspot: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject Message-ID: <202002252010.01PKAmas019024@aojmv0008.oracle.com> Changeset: cf0f69f962d9 Author: shade Date: 2020-02-25 21:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/cf0f69f962d9 Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject Reviewed-by: rkennke ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp From shade at redhat.com Tue Feb 25 21:10:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 25 Feb 2020 22:10:41 +0100 Subject: Probably a bug In-Reply-To: <2237c245-dcaf-b635-79a7-c1e70e515c54@redhat.com> References: <1F09634F-0642-4DE5-AAB6-C9035238ABF8@korins.ky> <2237c245-dcaf-b635-79a7-c1e70e515c54@redhat.com> Message-ID: On 2/25/20 10:37 AM, Aleksey Shipilev wrote: > On 2/24/20 11:22 PM, Kirill A. Korinsky wrote: >> After playing really a while I've created a very trivial test case: https://github.com/catap/shenandoah-akka-bug > > Thank you. > > It can be run without docker-compose with just a naked JDK binary. > > This reliably fails with Future timeout for me: > > $ mvn package > $ cd target/shenandoah-akka-bug-1.0.0-dist/shenandoah-akka-bug-1.0.0 > $ EXTERNAL_ADDR=127.0.0.1 > ~/trunks/shenandoah-jdk8/build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java > -Xmx1g -XX:+UseShenandoahGC -XX:+UnlockDiagnosticVMOptions -XX:ShenandoahGCHeuristics=aggressive > -XX:TieredStopAtLevel=1 -jar bin/shenandoah-akka-bug-1.0.0.jar > > What it seems to tell me: > a) It fails only with -XX:TieredStopAtLevel=1. It does not seem to fail with -Xint or > -XX:-TieredCompilation, which suggests this is C1 problem; > b) It does not seem to fail with -XX:ShenandoahGCMode=passive, which suggests this trouble is > somewhere in Shenandoah C1 barriers or around it; > c) It does not fail with -XX:ShenandoahGCMode=passive and all barriers enabled back, which suggests > it is somewhere in the mid/slowpath of Shenandoah C1 barrier. And here is the fix, in line with those observations: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-February/011516.html It passes the reproducer for me. If you are running sh/jdk8 nightlies, then b575 onwards has it: $ curl https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-x86_64-release.tar.xz | tar xJf - $ j2sdk-image/bin/java -version openjdk version "1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8" OpenJDK Runtime Environment (build 1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8-b575-20200225) OpenJDK 64-Bit Server VM (build 25.71-b575-20200225, mixed mode) $ grep "do_UnsafeGetAndSetObject" j2sdk-image/bom-changesets-hotspot.log summary: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject $ docker run --rm -it shipilev/openjdk-shenandoah:8 java -XX:+UseShenandoahGC -version openjdk version "1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8" OpenJDK Runtime Environment (build 1.8.0-builds.shipilev.net-openjdk-shenandoah-jdk8-b575-20200225) OpenJDK 64-Bit Server VM (build 25.71-b575-20200225, mixed mode) -- Thanks, -Aleksey From shade at redhat.com Wed Feb 26 09:19:26 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Feb 2020 10:19:26 +0100 Subject: RFR (XS) 8240069: Shenandoah: turn more flags diagnostic Message-ID: <80e3c299-575d-1603-0341-6176738b1280@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8240069 Webrev: http://cr.openjdk.java.net/~shade/8240069/webrev.01/ Regular sweep of flags that are experimental, but have been used as diagnostic. Diagnostic flags are usually for features that are enabled by default, and are not expected to be disabled, unless someone is chasing the bug. Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Wed Feb 26 09:38:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Feb 2020 10:38:21 +0100 Subject: RFR (S) 8240070: Shenandoah: remove obsolete ShenandoahCommonGCStateLoads Message-ID: <1705d27b-bdf7-ef28-edb7-84e804786798@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8240070 This is the leftover of the older experiment that optimized the frequently emitted barriers. With the switch to LRB and questionable performance improvements (sometimes hijacked by elevated register pressure), it makes less sense to keep the option exposed and C2 code more complicated. Removal webrev: https://cr.openjdk.java.net/~shade/8240070/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed Feb 26 10:00:18 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Feb 2020 11:00:18 +0100 Subject: RFR (XS) 8240069: Shenandoah: turn more flags diagnostic In-Reply-To: <80e3c299-575d-1603-0341-6176738b1280@redhat.com> References: <80e3c299-575d-1603-0341-6176738b1280@redhat.com> Message-ID: <6009896c-853d-16fb-6769-fcf1b97387ac@redhat.com> Yes, that makes sense! Thank you! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8240069 > > Webrev: > http://cr.openjdk.java.net/~shade/8240069/webrev.01/ > > Regular sweep of flags that are experimental, but have been used as diagnostic. Diagnostic flags are > usually for features that are enabled by default, and are not expected to be disabled, unless > someone is chasing the bug. > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Wed Feb 26 10:03:47 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Feb 2020 11:03:47 +0100 Subject: RFR (S) 8240070: Shenandoah: remove obsolete ShenandoahCommonGCStateLoads In-Reply-To: <1705d27b-bdf7-ef28-edb7-84e804786798@redhat.com> References: <1705d27b-bdf7-ef28-edb7-84e804786798@redhat.com> Message-ID: <58632b60-f466-d443-d520-78da2702b096@redhat.com> As far as I understand, this optimization pass would not work with LRB anyway. So yeah, please remove it. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8240070 > > This is the leftover of the older experiment that optimized the frequently emitted barriers. With > the switch to LRB and questionable performance improvements (sometimes hijacked by elevated register > pressure), it makes less sense to keep the option exposed and C2 code more complicated. > > Removal webrev: > https://cr.openjdk.java.net/~shade/8240070/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Wed Feb 26 11:52:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Feb 2020 12:52:39 +0100 Subject: RFR (S) 8240076: Shenandoah: pacer should cover reset and preclean phases Message-ID: <30ee2c94-22dd-536e-7d59-c3d61ae87780@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8240076 See bug above for discussion. Webrev: https://cr.openjdk.java.net/~shade/8240076/webrev.01/ Testing: hotspot_gc_shenandoah, eyeballing logs -- Thanks, -Aleksey From zgu at redhat.com Wed Feb 26 13:32:34 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 26 Feb 2020 08:32:34 -0500 Subject: RFR (S) 8240076: Shenandoah: pacer should cover reset and preclean phases In-Reply-To: <30ee2c94-22dd-536e-7d59-c3d61ae87780@redhat.com> References: <30ee2c94-22dd-536e-7d59-c3d61ae87780@redhat.com> Message-ID: Looks good to me. -Zhengyu On 2/26/20 6:52 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8240076 > > See bug above for discussion. > > Webrev: > https://cr.openjdk.java.net/~shade/8240076/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing logs > From shade at redhat.com Wed Feb 26 14:14:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Feb 2020 15:14:39 +0100 Subject: RFC: Pick up 11.0.7+5 to sh/jdk11 Message-ID: <8a297ea4-d4ce-c4a3-df10-8428b2d26170@redhat.com> Upstream published jdk-11.0.7+5, let's pick it up. The merge is trivial. I would tag the result shenandoah-jdk-11.0.7+5 right away. Changeset list: https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.7%2b5/changesets.txt Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed Feb 26 21:47:50 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Feb 2020 22:47:50 +0100 Subject: RFC: Pick up 11.0.7+5 to sh/jdk11 In-Reply-To: <8a297ea4-d4ce-c4a3-df10-8428b2d26170@redhat.com> References: <8a297ea4-d4ce-c4a3-df10-8428b2d26170@redhat.com> Message-ID: <7ca616bf-7322-23e3-56f9-9a53607cc3fa@redhat.com> Yes, please go ahead! Thanks, Roman > Upstream published jdk-11.0.7+5, let's pick it up. > > The merge is trivial. I would tag the result shenandoah-jdk-11.0.7+5 right away. > > Changeset list: > https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.7%2b5/changesets.txt > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Thu Feb 27 08:58:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Feb 2020 09:58:44 +0100 Subject: [11] 2020-02-27, Bulk backports to sh/jdk11 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200227/webrev.01/ This backports another batch of simple changes: [backport] 8238385: CTW: C2 (Shenandoah) compilation fails with "Range check dependent CastII node was not removed" [backport] 8240076: Shenandoah: pacer should cover reset and preclean phases [backport] 8240069: Shenandoah: turn more flags diagnostic [backport] 8239904: Shenandoah: accumulated penalties should not be over 100% of capacity [backport] 8239868: Shenandoah: ditch C2 node limit adjustments [backport] 8240070: Shenandoah: remove obsolete ShenandoahCommonGCStateLoads Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Thu Feb 27 10:18:09 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Feb 2020 11:18:09 +0100 Subject: [11] 2020-02-27, Bulk backports to sh/jdk11 In-Reply-To: References: Message-ID: <9a438dc2-9628-42e1-8da2-4b1c414e270c@redhat.com> Hi Aleksey, This looks good. Thank you! Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200227/webrev.01/ > > This backports another batch of simple changes: > > [backport] 8238385: CTW: C2 (Shenandoah) compilation fails with "Range check dependent CastII node > was not removed" > [backport] 8240076: Shenandoah: pacer should cover reset and preclean phases > [backport] 8240069: Shenandoah: turn more flags diagnostic > [backport] 8239904: Shenandoah: accumulated penalties should not be over 100% of capacity > [backport] 8239868: Shenandoah: ditch C2 node limit adjustments > [backport] 8240070: Shenandoah: remove obsolete ShenandoahCommonGCStateLoads > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Thu Feb 27 12:27:32 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Feb 2020 13:27:32 +0100 Subject: RFR (sh/jdk8): Bulk backports sh/jdk11 -> sh/jdk8 Message-ID: This backports the following changes from sh/jdk11 to sh/jdk8: JDK-8221751: Shenandoah: Improve SATB enqueueing JDK-8223184: Shenandoah: Missing roots in SRP::process_all_roots_slow JDK-8223951: Shenandoah: Only need to update thread roots during final update refs JDK-8224179: Shenandoah: CTW test failures with traversal GC JDK-8224495: Shenandoah: Do not rescan code roots in final mark pause if it is not degenerated GC+ JDK-8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle JDK-8225341: Shenandoah: CM::update_thread_roots() needs to handle derived pointers I am working through the outstanding backports list from oldest to newest. This is the first batch of a few that are coming up next. I am thinking it's better to chop it in smaller pieces and have this tested by CI while I work on the next batch. Some backports are only fragments (e.g. JDK-8221751) because most of it landed via other backports (e.g. arraycopy stuff) already. Changesets: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27/changesets.txt Webrev: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27/webrev.00/ Testing: hotspot_gc_shenandoah Roman From shade at redhat.com Thu Feb 27 12:53:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Feb 2020 13:53:14 +0100 Subject: RFR (sh/jdk8): Bulk backports sh/jdk11 -> sh/jdk8 In-Reply-To: References: Message-ID: On 2/27/20 1:27 PM, Roman Kennke wrote: > JDK-8223184: Shenandoah: Missing roots in SRP::process_all_roots_slow I suspect this one is not applicable to 8u. JNIHandles::weak_oops_do walks JvmtiExport::weak_oops_do, is it not? Similar thing caused us headache before: https://bugs.openjdk.java.net/browse/JDK-8223258 > Changesets: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27/changesets.txt > Webrev: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27/webrev.00/ Otherwise looks good. -- Thanks, -Aleksey From rkennke at redhat.com Thu Feb 27 13:08:19 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Feb 2020 14:08:19 +0100 Subject: RFR (sh/jdk8): Bulk backports sh/jdk11 -> sh/jdk8 In-Reply-To: References: Message-ID: >> JDK-8223184: Shenandoah: Missing roots in SRP::process_all_roots_slow > > I suspect this one is not applicable to 8u. JNIHandles::weak_oops_do walks > JvmtiExport::weak_oops_do, is it not? > > Similar thing caused us headache before: > https://bugs.openjdk.java.net/browse/JDK-8223258 Right! Good spot! I actually had JDK-8223258 on my backports list but then cut it out. Gaa, jdk8 roots stuff is such a mess. Well, I guess we can cut both out and be happy. >> Changesets: >> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27/changesets.txt >> Webrev: >> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27/webrev.00/ > > Otherwise looks good. Will push without the weakroots change. Thank you, Roman From zgu at redhat.com Thu Feb 27 13:21:24 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 27 Feb 2020 08:21:24 -0500 Subject: [15] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" In-Reply-To: References: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> Message-ID: <2d619863-e6e2-2dde-29ed-ef95b13b7413@redhat.com> Hi, Based on Erik's suggestion from JDK-8238633 review [1], we can filter out oops marked by JVMTI and JFR leak profiler via resolve_forwarded() barrier, by inserting an null check on forwarding pointer. To reduce performance impact, we split up compiler and runtime resolve forwarded barrier, only performs extra null check in runtime barrier, as JVMTI and leak profiler heap walk are performed at safepoints, where mutators are stopped. Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.01/ Test: hotspot_gc_shenandoah vmTestbase_nsk_jvmti vmTestbase_nsk_jdi Thanks, -Zhengyu [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-February/040974.html On 2/4/20 2:23 PM, Aleksey Shipilev wrote: > On 2/3/20 9:59 PM, Zhengyu Gu wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8237632 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.00/ > > Uh. It seems to me the cure is worse than the disease: > 1) It rewires sensitive parts of barrier paths, root handling, etc, which requires more thorough > testing, and we are too deep in RDP2 for this; > 2) It effectively disables asserts for anything not in collection set. Which means it disables > most of asserts. The fact that Verifier still works is a small consolation. > > I propose to accept this failure in 14, and rework the JVMTI heap walk to stop messing around with > mark words in 15. Since this relates to concurrent root handling, 11-shenandoah is already safe. > From shade at redhat.com Thu Feb 27 13:24:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Feb 2020 14:24:35 +0100 Subject: [15] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" In-Reply-To: <2d619863-e6e2-2dde-29ed-ef95b13b7413@redhat.com> References: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> <2d619863-e6e2-2dde-29ed-ef95b13b7413@redhat.com> Message-ID: On 2/27/20 2:21 PM, Zhengyu Gu wrote: > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.01/ This looks good to me. Let Roman look through it as well. -- Thanks, -Aleksey From shade at redhat.com Thu Feb 27 13:26:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Feb 2020 14:26:57 +0100 Subject: [15] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" In-Reply-To: References: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> <2d619863-e6e2-2dde-29ed-ef95b13b7413@redhat.com> Message-ID: <5722e9ec-05c9-611c-f2ae-b112813997a1@redhat.com> On 2/27/20 2:24 PM, Aleksey Shipilev wrote: > On 2/27/20 2:21 PM, Zhengyu Gu wrote: >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.01/ > > This looks good to me. Suggestion to change the synopsis, though: "Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR" -- Thanks, -Aleksey From zgu at redhat.com Thu Feb 27 13:29:08 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 27 Feb 2020 08:29:08 -0500 Subject: [15] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" In-Reply-To: <5722e9ec-05c9-611c-f2ae-b112813997a1@redhat.com> References: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> <2d619863-e6e2-2dde-29ed-ef95b13b7413@redhat.com> <5722e9ec-05c9-611c-f2ae-b112813997a1@redhat.com> Message-ID: <019a2d3f-9bc1-f28d-4b69-bd3461d10c6d@redhat.com> On 2/27/20 8:26 AM, Aleksey Shipilev wrote: > On 2/27/20 2:24 PM, Aleksey Shipilev wrote: >> On 2/27/20 2:21 PM, Zhengyu Gu wrote: >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.01/ >> >> This looks good to me. > > Suggestion to change the synopsis, though: > "Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR" Thanks for the review, Aleksey. I will fix the synopsis before push. -Zhengyu > From rkennke at redhat.com Thu Feb 27 14:54:04 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Feb 2020 15:54:04 +0100 Subject: [15] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address" In-Reply-To: <2d619863-e6e2-2dde-29ed-ef95b13b7413@redhat.com> References: <24a45316-25f2-8be5-004e-47ca59cd1f13@redhat.com> <2d619863-e6e2-2dde-29ed-ef95b13b7413@redhat.com> Message-ID: <893bb323-ee07-7621-e80f-41e899064a65@redhat.com> Looks good to me. Thank you! Roman > Hi, > > Based on Erik's suggestion from JDK-8238633 review [1], we can filter > out oops marked by JVMTI and JFR leak profiler via resolve_forwarded() > barrier, by inserting an null check on forwarding pointer. > > To reduce performance impact, we split up compiler and runtime resolve > forwarded barrier, only performs extra null check in runtime barrier, as > JVMTI and leak profiler heap walk are performed at safepoints, where > mutators are stopped. > > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.01/ > > Test: > ? hotspot_gc_shenandoah > ? vmTestbase_nsk_jvmti > ? vmTestbase_nsk_jdi > > Thanks, > > -Zhengyu > > [1] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-February/040974.html > > > > > On 2/4/20 2:23 PM, Aleksey Shipilev wrote: >> On 2/3/20 9:59 PM, Zhengyu Gu wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237632 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.00/ >> >> Uh. It seems to me the cure is worse than the disease: >> ?? 1) It rewires sensitive parts of barrier paths, root handling, etc, >> which requires more thorough >> testing, and we are too deep in RDP2 for this; >> ?? 2) It effectively disables asserts for anything not in collection >> set. Which means it disables >> most of asserts. The fact that Verifier still works is a small >> consolation. >> >> I propose to accept this failure in 14, and rework the JVMTI heap walk >> to stop messing around with >> mark words in 15. Since this relates to concurrent root handling, >> 11-shenandoah is already safe. >> > From rkennke at redhat.com Thu Feb 27 14:54:16 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Feb 2020 15:54:16 +0100 Subject: [15] RFR 8239354: Shenandoah: minor enhancements to traversal GC In-Reply-To: References: Message-ID: <60257cc5-6e76-cc71-79d8-42c96de669b6@redhat.com> Hi Zhengyu, This looks good to me, thank you! Roman > 1) Added assertion to catch evacuation after completion of heap > traversal. This should help catch the bug demonstrated in sh-jdk11 w/o > JDK-8237396. > > 2) Retire TLAB/GCLAB after completion of heap traversal. Current code > retires TLAB/GCLAB at the beginning final traversal, but STW traversal > still uses GCLAB to evacuate remaining objects. > > 3) Added comments regarding why need to retire TLAB/GCLAB, even we don't > need heap to be parsable. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8239354 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8239354/webrev.00/index.html > > Test: > ? hotspot_gc_shenandoah > > Thanks, > > -Zhengyu > From rkennke at redhat.com Thu Feb 27 20:25:46 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Feb 2020 21:25:46 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-27, batch 2 Message-ID: <3d46e889-352a-06e1-b422-3ac663ac8447@redhat.com> This is the second batch of backports already (~1 one more expected soon). It backports the following issues from sh/jdk11: JDK-8224525: Shenandoah: Eliminate shenandoah verifier's side-effects JDK-8225171: Remove leftovers in shenandoahBarrierSetC1.cpp JDK-8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC JDK-8227676: Shenandoah: More consistent naming of LRB runtime entry points JDK-8228364: Shenandoah: Remove unused code from ShenandoahBarrierSetC1 JDK-8228369: Shenandoah: Refactor LRB C1 stubs JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure JDK-8229709: x86_32 build and test failures after JDK-8228369 (Shenandoah: Refactor LRB C1 stubs) JDK-8229865: Use explicit #include debug.hpp for STATIC_ASSERT in gc/shenandoah/shenandoahUtils.cpp The significant change (and diverging from sh/jdk11) is JDK-8228369, it requires some addition to c1_Runtime_$ARCH.cpp that is difficult/impossible to put into shenandoahBarrierSetAssembler_$ARCH.cpp because of missing GC interfaces. But it's overall contained, so should be ok. "JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure" is interesting because it's wholly different from jdk11 because of the recent (2 days ago) getAndSetObject() fix: instead of overriding/reverting that I keep the recent fix and sneak in the aarch64 version of it (which we've forgotten about 2 days ago) :-) I hope that's ok. It's in the spirit of the original fix I suppose. Changesets: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/changesets.txt Webrev: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.00/ Testing: hotspot_gc_shenandoah (x86_64, aarch64): somebody should probably check x86_32 bit because I currently can't. Aarch64 shows some failures but no regressions: I'll check those once I'm through with all backports. They've been pre-existing before I started with the backports queue. Good? Thank you, Roman From zgu at redhat.com Thu Feb 27 20:32:14 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 27 Feb 2020 15:32:14 -0500 Subject: RFR (sh/jdk8): Backport 2020-02-27, batch 2 In-Reply-To: <3d46e889-352a-06e1-b422-3ac663ac8447@redhat.com> References: <3d46e889-352a-06e1-b422-3ac663ac8447@redhat.com> Message-ID: Hi Roman, x86_32 bit does not build. /home/zgu/ws/sh-jdk8u/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp: In static member function ?static OopMapSet* Runtime1::generate_code_for(Runtime1::StubID, StubAssembler*)?: /home/zgu/ws/sh-jdk8u/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp:1788:28: error: ?c_rarg0? was not declared in this scope 1788 | f.load_argument(0, c_rarg0); | ^~~~~~~ -Zhengyu On 2/27/20 3:25 PM, Roman Kennke wrote: > This is the second batch of backports already (~1 one more expected > soon). It backports the following issues from sh/jdk11: > > JDK-8224525: Shenandoah: Eliminate shenandoah verifier's side-effects > JDK-8225171: Remove leftovers in shenandoahBarrierSetC1.cpp > JDK-8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC > JDK-8227676: Shenandoah: More consistent naming of LRB runtime entry points > JDK-8228364: Shenandoah: Remove unused code from ShenandoahBarrierSetC1 > JDK-8228369: Shenandoah: Refactor LRB C1 stubs > JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure > JDK-8229709: x86_32 build and test failures after JDK-8228369 > (Shenandoah: Refactor LRB C1 stubs) > JDK-8229865: Use explicit #include debug.hpp for STATIC_ASSERT in > gc/shenandoah/shenandoahUtils.cpp > > The significant change (and diverging from sh/jdk11) is JDK-8228369, it > requires some addition to c1_Runtime_$ARCH.cpp that is > difficult/impossible to put into shenandoahBarrierSetAssembler_$ARCH.cpp > because of missing GC interfaces. But it's overall contained, so should > be ok. > > "JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure" is > interesting because it's wholly different from jdk11 because of the > recent (2 days ago) getAndSetObject() fix: instead of > overriding/reverting that I keep the recent fix and sneak in the aarch64 > version of it (which we've forgotten about 2 days ago) :-) I hope that's > ok. It's in the spirit of the original fix I suppose. > > Changesets: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/changesets.txt > Webrev: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.00/ > > Testing: hotspot_gc_shenandoah (x86_64, aarch64): somebody should > probably check x86_32 bit because I currently can't. Aarch64 shows some > failures but no regressions: I'll check those once I'm through with all > backports. They've been pre-existing before I started with the backports > queue. > > Good? > > Thank you, > Roman > From rkennke at redhat.com Thu Feb 27 20:43:20 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Feb 2020 21:43:20 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-27, batch 2 In-Reply-To: References: <3d46e889-352a-06e1-b422-3ac663ac8447@redhat.com> Message-ID: <3e5b51d7-20cd-e813-c842-ae087293ace4@redhat.com> Thank you! Can you try this one: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.01/ Thanks, Roman > Hi Roman, > > x86_32 bit does not build. > > /home/zgu/ws/sh-jdk8u/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp: In > static member function ?static OopMapSet* > Runtime1::generate_code_for(Runtime1::StubID, StubAssembler*)?: > /home/zgu/ws/sh-jdk8u/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp:1788:28: error: > ?c_rarg0? was not declared in this scope > ?1788 |???????? f.load_argument(0, c_rarg0); > ????? |??????????????????????????? ^~~~~~~ > > > -Zhengyu > > On 2/27/20 3:25 PM, Roman Kennke wrote: >> This is the second batch of backports already (~1 one more expected >> soon). It backports the following issues from sh/jdk11: >> >> JDK-8224525: Shenandoah: Eliminate shenandoah verifier's side-effects >> JDK-8225171: Remove leftovers in shenandoahBarrierSetC1.cpp >> JDK-8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC >> JDK-8227676: Shenandoah: More consistent naming of LRB runtime entry >> points >> JDK-8228364: Shenandoah: Remove unused code from ShenandoahBarrierSetC1 >> JDK-8228369: Shenandoah: Refactor LRB C1 stubs >> JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure >> JDK-8229709: x86_32 build and test failures after JDK-8228369 >> (Shenandoah: Refactor LRB C1 stubs) >> JDK-8229865: Use explicit #include debug.hpp for STATIC_ASSERT in >> gc/shenandoah/shenandoahUtils.cpp >> >> The significant change (and diverging from sh/jdk11) is JDK-8228369, it >> requires some addition to c1_Runtime_$ARCH.cpp that is >> difficult/impossible to put into shenandoahBarrierSetAssembler_$ARCH.cpp >> because of missing GC interfaces. But it's overall contained, so should >> be ok. >> >> "JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure" is >> interesting because it's wholly different from jdk11 because of the >> recent (2 days ago) getAndSetObject() fix: instead of >> overriding/reverting that I keep the recent fix and sneak in the aarch64 >> version of it (which we've forgotten about 2 days ago) :-) I hope that's >> ok. It's in the spirit of the original fix I suppose. >> >> Changesets: >> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/changesets.txt >> >> Webrev: >> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.00/ >> >> >> Testing: hotspot_gc_shenandoah (x86_64, aarch64): somebody should >> probably check x86_32 bit because I currently can't. Aarch64 shows some >> failures but no regressions: I'll check those once I'm through with all >> backports. They've been pre-existing before I started with the backports >> queue. >> >> Good? >> >> Thank you, >> Roman >> > From zgu at redhat.com Thu Feb 27 21:50:09 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 27 Feb 2020 16:50:09 -0500 Subject: RFR (sh/jdk8): Backport 2020-02-27, batch 2 In-Reply-To: <3e5b51d7-20cd-e813-c842-ae087293ace4@redhat.com> References: <3d46e889-352a-06e1-b422-3ac663ac8447@redhat.com> <3e5b51d7-20cd-e813-c842-ae087293ace4@redhat.com> Message-ID: <2614459e-70d4-0f90-9297-eabc9923e9a6@redhat.com> hotspot_gc_shenandoah, fastdebug and release are good. -Zhengyu On 2/27/20 3:43 PM, Roman Kennke wrote: > Thank you! Can you try this one: > > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.01/ > > Thanks, > Roman > >> Hi Roman, >> >> x86_32 bit does not build. >> >> /home/zgu/ws/sh-jdk8u/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp: In >> static member function ?static OopMapSet* >> Runtime1::generate_code_for(Runtime1::StubID, StubAssembler*)?: >> /home/zgu/ws/sh-jdk8u/hotspot/src/cpu/x86/vm/c1_Runtime1_x86.cpp:1788:28: error: >> ?c_rarg0? was not declared in this scope >> ?1788 |???????? f.load_argument(0, c_rarg0); >> ????? |??????????????????????????? ^~~~~~~ >> >> >> -Zhengyu >> >> On 2/27/20 3:25 PM, Roman Kennke wrote: >>> This is the second batch of backports already (~1 one more expected >>> soon). It backports the following issues from sh/jdk11: >>> >>> JDK-8224525: Shenandoah: Eliminate shenandoah verifier's side-effects >>> JDK-8225171: Remove leftovers in shenandoahBarrierSetC1.cpp >>> JDK-8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC >>> JDK-8227676: Shenandoah: More consistent naming of LRB runtime entry >>> points >>> JDK-8228364: Shenandoah: Remove unused code from ShenandoahBarrierSetC1 >>> JDK-8228369: Shenandoah: Refactor LRB C1 stubs >>> JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure >>> JDK-8229709: x86_32 build and test failures after JDK-8228369 >>> (Shenandoah: Refactor LRB C1 stubs) >>> JDK-8229865: Use explicit #include debug.hpp for STATIC_ASSERT in >>> gc/shenandoah/shenandoahUtils.cpp >>> >>> The significant change (and diverging from sh/jdk11) is JDK-8228369, it >>> requires some addition to c1_Runtime_$ARCH.cpp that is >>> difficult/impossible to put into shenandoahBarrierSetAssembler_$ARCH.cpp >>> because of missing GC interfaces. But it's overall contained, so should >>> be ok. >>> >>> "JDK-8229470: Shenandoah: Fix C1 getAndSetObject() failure" is >>> interesting because it's wholly different from jdk11 because of the >>> recent (2 days ago) getAndSetObject() fix: instead of >>> overriding/reverting that I keep the recent fix and sneak in the aarch64 >>> version of it (which we've forgotten about 2 days ago) :-) I hope that's >>> ok. It's in the spirit of the original fix I suppose. >>> >>> Changesets: >>> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/changesets.txt >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.00/ >>> >>> >>> Testing: hotspot_gc_shenandoah (x86_64, aarch64): somebody should >>> probably check x86_32 bit because I currently can't. Aarch64 shows some >>> failures but no regressions: I'll check those once I'm through with all >>> backports. They've been pre-existing before I started with the backports >>> queue. >>> >>> Good? >>> >>> Thank you, >>> Roman >>> >> > From gnu.andrew at redhat.com Fri Feb 28 04:54:45 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Feb 2020 04:54:45 +0000 Subject: [RFR] [8u] 8u252-b04 Upstream Sync Message-ID: <08f2d707-f3a3-4b4f-555f-f8e591bf76c7@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b04: - S8038631: Create wrapper for awt.Robot with additional functionality - S8047212: runtime/ParallelClassLoading/bootstrap/random/inner-complex assert(ObjectSynchronizer::verify_objmon_isinpool(inf)) failed: monitor is invalid - S8135318: CMS wrong max_eden_size for check_gc_overhead_limit - S8144445: Maximum size checking in Marlin ArrayCache utility methods is not optimal - S8144446: Automate the Marlin crash test - S8144630: Use PrivilegedAction to create Thread in Marlin RendererStats - S8215756: Memory leaks in the AWT on macOS - S8219244: NMT: Change ThreadSafepointState's allocation type from mtInternal to mtThread - S8225128: Add exception for expiring DocuSign root to VerifyCACerts test - S8229345: Memory leak due to vtable stubs not being shared on SPARC - S8229872: (fs) Increase buffer size used with getmntent - S8236179: C1 register allocation error with T_ADDRESS - S8237368: Problem with NullPointerException in RMI TCPEndpoint.read Main issue of note: None, clean merge 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/make/mapfiles/libnio/mapfile-linux | 4 b/src/macosx/native/sun/awt/AWTView.m | 7 b/src/macosx/native/sun/awt/AWTWindow.m | 2 b/src/macosx/native/sun/awt/CGraphicsEnv.m | 2 b/src/share/classes/sun/java2d/marlin/ArrayCache.java | 38 - b/src/share/classes/sun/java2d/marlin/Renderer.java | 7 b/src/share/classes/sun/java2d/marlin/RendererStats.java | 42 - b/src/share/classes/sun/java2d/marlin/Stroker.java | 5 b/src/share/classes/sun/rmi/transport/tcp/TCPEndpoint.java | 2 b/src/solaris/classes/sun/nio/fs/LinuxFileSystem.java | 20 b/src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java | 19 b/src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java | 7 b/src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c | 45 + b/src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c | 16 b/test/java/rmi/server/RMISocketFactory/useSocketFactory/unicast/TCPEndpointReadBug.java | 113 +++ b/test/lib/testlibrary/ExtendedRobot.java | 372 ++++++++++ b/test/sun/java2d/marlin/ArrayCacheSizeTest.java | 131 +++ b/test/sun/java2d/marlin/CrashTest.java | 59 - b/test/sun/security/lib/cacerts/VerifyCACerts.java | 4 20 files changed, 823 insertions(+), 73 deletions(-) diffstat for hotspot b/.hgtags | 1 b/src/cpu/ppc/vm/globals_ppc.hpp | 4 b/src/cpu/sparc/vm/c1_FrameMap_sparc.cpp | 2 b/src/cpu/sparc/vm/globals_sparc.hpp | 3 b/src/cpu/x86/vm/c1_FrameMap_x86.cpp | 2 b/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp | 4 b/src/cpu/x86/vm/globals_x86.hpp | 3 b/src/cpu/zero/vm/globals_zero.hpp | 3 b/src/share/vm/c1/c1_FrameMap.hpp | 4 b/src/share/vm/code/vtableStubs.cpp | 4 b/src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp | 4 b/src/share/vm/runtime/globals.hpp | 5 b/src/share/vm/runtime/safepoint.hpp | 2 b/src/share/vm/runtime/synchronizer.cpp | 92 +++++----- b/src/share/vm/runtime/synchronizer.hpp | 2 b/src/share/vm/runtime/vmStructs.cpp | 19 +- 16 files changed, 88 insertions(+), 66 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 Fri Feb 28 09:40:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Feb 2020 10:40:22 +0100 Subject: RFR (S) 8240215: Shenandoah: remove ShenandoahAllocationTrace Message-ID: RFR: https://bugs.openjdk.java.net/browse/JDK-8240215 This was the experimental option to look in the performance of allocation path. It is not needed anymore, and attempt to turn it on in production would probably introduce performance bottlenecks. It is safer to remove it, and partially locally revert later if needed. Webrev: https://cr.openjdk.java.net/~shade/8240215/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Fri Feb 28 09:53:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Feb 2020 10:53:14 +0100 Subject: RFR (XS) 8240216: Shenandoah: remove ShenandoahTerminationTrace Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8240216 This was the diagnostic option for working on improving the termination protocol. Now that VM had moved globally to OWST as termination protocol, this seems to only increase the maintenance burden. The option is turned off by default already. Zhengyu, do you agree? Webrev: https://cr.openjdk.java.net/~shade/8240216/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Fri Feb 28 10:06:15 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Feb 2020 11:06:15 +0100 Subject: RFR (S) 8240217: Shenandoah: remove ShenandoahEvacAssist Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8240217 ShenandoahEvacAssist is an experimental option that strived to make calling into WB/LRB slowpath less frequent. It implicitly relied on WB/LRB midpath to check for forwardee and shortcut from there. With the introduction of self-fixing barriers, this was intentionally removed. Therefore, Shenandoah would call into slow-path anyway, even when evac-assist path had evacuated some objects. Also, with Traversal, the assist path breaks out of Traversal's intent to evacuate the objects in traversal order. There, it becomes actively harmful. We should consider removing it. Webrev: https://cr.openjdk.java.net/~shade/8240217/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Fri Feb 28 10:50:00 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 28 Feb 2020 11:50:00 +0100 Subject: RFR (S) 8240215: Shenandoah: remove ShenandoahAllocationTrace In-Reply-To: References: Message-ID: Ok by me. Thanks, Roman On 2/28/20 10:40 AM, Aleksey Shipilev wrote: > RFR: > https://bugs.openjdk.java.net/browse/JDK-8240215 > > This was the experimental option to look in the performance of allocation path. It is not needed > anymore, and attempt to turn it on in production would probably introduce performance bottlenecks. > It is safer to remove it, and partially locally revert later if needed. > > Webrev: > https://cr.openjdk.java.net/~shade/8240215/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Fri Feb 28 10:52:01 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 28 Feb 2020 11:52:01 +0100 Subject: RFR (S) 8240217: Shenandoah: remove ShenandoahEvacAssist In-Reply-To: References: Message-ID: Have you done any performance experiments? A (not so long) while back, I ran SPECjbb2015 with and without the option, and couldn't measure a difference. If anything, latency slightly improved with evac-assist turned off. Other than that, good. Less code, less maintenance. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8240217 > > ShenandoahEvacAssist is an experimental option that strived to make calling into WB/LRB slowpath > less frequent. > > It implicitly relied on WB/LRB midpath to check for forwardee and shortcut from there. With the > introduction of self-fixing barriers, this was intentionally removed. Therefore, Shenandoah would > call into slow-path anyway, even when evac-assist path had evacuated some objects. > > Also, with Traversal, the assist path breaks out of Traversal's intent to evacuate the objects in > traversal order. There, it becomes actively harmful. We should consider removing it. > > Webrev: > https://cr.openjdk.java.net/~shade/8240217/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Fri Feb 28 11:05:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Feb 2020 12:05:16 +0100 Subject: [RFR] [8u] 8u252-b04 Upstream Sync In-Reply-To: <08f2d707-f3a3-4b4f-555f-f8e591bf76c7@redhat.com> References: <08f2d707-f3a3-4b4f-555f-f8e591bf76c7@redhat.com> Message-ID: <01b9606e-91a8-0322-a4bd-a655cbaafa8f@redhat.com> On 2/28/20 5:54 AM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/hotspot/merge.changeset Look good. I am a bit uneasy about synchronizer.cpp changes, but they seem to look safe. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/root/merge.changeset Look trivially good. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From shade at redhat.com Fri Feb 28 11:33:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Feb 2020 12:33:41 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-27, batch 2 In-Reply-To: <3e5b51d7-20cd-e813-c842-ae087293ace4@redhat.com> References: <3d46e889-352a-06e1-b422-3ac663ac8447@redhat.com> <3e5b51d7-20cd-e813-c842-ae087293ace4@redhat.com> Message-ID: On 2/27/20 9:43 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.01/ Frankly, I suspect C1 rewiring (which also diverged from upstream) runs into the risk of destabilizing sh/jdk8 before April CPU release. Can we delay it until July CPU opens? I believe we should push the src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp change as the aarch64 addendum to this one: http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/cf0f69f962d9 -- ahead of this backport batch. Other things: *) src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp: Do you really need SBSC1 here? 252 ShenandoahBarrierSetC1* bs = ShenandoahBarrierSetC1::bsc1(); -- Thanks, -Aleksey From rkennke at redhat.com Fri Feb 28 11:59:30 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 28 Feb 2020 12:59:30 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-27, batch 2 In-Reply-To: References: <3d46e889-352a-06e1-b422-3ac663ac8447@redhat.com> <3e5b51d7-20cd-e813-c842-ae087293ace4@redhat.com> Message-ID: <97226d8c-e484-c334-f5f5-2fb75537e226@redhat.com> Hi Aleksey, >> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.01/ > > Frankly, I suspect C1 rewiring (which also diverged from upstream) runs into the risk of > destabilizing sh/jdk8 before April CPU release. Can we delay it until July CPU opens? Ok, I'm cutting it out. It makes sense, the next batch will have more C1 rewirings esp the SFX stuff, which has a bit of a bug trail (I believe we had one recent bug with C1 register types that stems from the SFX work), so let's prepare them and then push them together once July CPU opens. > I believe we should push the src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp change as the aarch64 > addendum to this one: http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/cf0f69f962d9 -- ahead > of this backport batch. Ok. > Other things: > > *) src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp: > Do you really need SBSC1 here? > > 252 ShenandoahBarrierSetC1* bs = ShenandoahBarrierSetC1::bsc1(); Apparently not. It comes from 11+ though, and is part of the C1 rewirings that is gone now: Changesets: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/changesets-2.txt Webrev: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.02/ ok? Roman From shade at redhat.com Fri Feb 28 12:15:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Feb 2020 13:15:34 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-27, batch 2 In-Reply-To: <97226d8c-e484-c334-f5f5-2fb75537e226@redhat.com> References: <3d46e889-352a-06e1-b422-3ac663ac8447@redhat.com> <3e5b51d7-20cd-e813-c842-ae087293ace4@redhat.com> <97226d8c-e484-c334-f5f5-2fb75537e226@redhat.com> Message-ID: On 2/28/20 12:59 PM, Roman Kennke wrote: > Changesets: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/changesets-2.txt > Webrev: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-27-2/webrev.02/ Yes, that looks good. -- Thanks, -Aleksey From rkennke at redhat.com Fri Feb 28 12:21:19 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 28 Feb 2020 13:21:19 +0100 Subject: RFR: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject (Aarch64 attendum) Message-ID: <534d1263-336e-fe01-4c62-0460431d3990@redhat.com> This fixes the same C1 getAndSetObject() problem that Aleksey recently fixed in x86, but for aarch64: http://cr.openjdk.java.net/~rkennke/shjdk8-aarch64-xchg/webrev.00/ Testing: hotspot_gc_shenandoah (aarch64) Ok? Roman From shade at redhat.com Fri Feb 28 12:25:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Feb 2020 13:25:22 +0100 Subject: RFR: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject (Aarch64 attendum) In-Reply-To: <534d1263-336e-fe01-4c62-0460431d3990@redhat.com> References: <534d1263-336e-fe01-4c62-0460431d3990@redhat.com> Message-ID: <71e42ce5-6bf1-9482-c9b8-38f2faa1a063@redhat.com> On 2/28/20 1:21 PM, Roman Kennke wrote: > This fixes the same C1 getAndSetObject() problem that Aleksey recently > fixed in x86, but for aarch64: > > http://cr.openjdk.java.net/~rkennke/shjdk8-aarch64-xchg/webrev.00/ You sure the destination is on the right? This is the same C1 LIR, so it should match x86? If so, looks good. It is "addendum". Better yet: AArch64: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject -- Thanks, -Aleksey From rkennke at redhat.com Fri Feb 28 12:48:49 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 28 Feb 2020 13:48:49 +0100 Subject: RFR: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject (Aarch64 attendum) In-Reply-To: <71e42ce5-6bf1-9482-c9b8-38f2faa1a063@redhat.com> References: <534d1263-336e-fe01-4c62-0460431d3990@redhat.com> <71e42ce5-6bf1-9482-c9b8-38f2faa1a063@redhat.com> Message-ID: <18403f6c-1b55-4320-51e5-86fa49be5cfa@redhat.com> >> This fixes the same C1 getAndSetObject() problem that Aleksey recently >> fixed in x86, but for aarch64: >> >> http://cr.openjdk.java.net/~rkennke/shjdk8-aarch64-xchg/webrev.00/ > > You sure the destination is on the right? This is the same C1 LIR, so it should match x86? If so, > looks good. Yes, see here: http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/file/851f16923028/src/share/vm/c1/c1_LIR.hpp#l2115 It is one of the weird quirks of C1 that it works the other direction compared to OpenJDK's asm. See also the x86 change: http://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/cf0f69f962d9 > It is "addendum". Better yet: > AArch64: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject Ok, will push under this synopsis. Thank you, Roman From rkennke at redhat.com Fri Feb 28 12:52:56 2020 From: rkennke at redhat.com (rkennke at redhat.com) Date: Fri, 28 Feb 2020 12:52:56 +0000 Subject: hg: shenandoah/jdk8/hotspot: 6 new changesets Message-ID: <202002281252.01SCqvHo011128@aojmv0008.oracle.com> Changeset: ee8a07d2deee Author: zgu Date: 2019-05-22 09:10 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ee8a07d2deee [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: 18b68a8c4d53 Author: rkennke Date: 2019-06-03 21:28 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/18b68a8c4d53 [backport] 8225171: Remove leftovers in shenandoahBarrierSetC1.cpp Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp Changeset: 12702a9ae59a Author: rkennke Date: 2020-02-27 15:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/12702a9ae59a [backport] 8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: bc199727351f Author: rkennke Date: 2019-07-15 15:27 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bc199727351f [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: 78b31b30720a Author: rkennke Date: 2019-07-18 13:16 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/78b31b30720a [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: 1af099ab04f1 Author: shade Date: 2019-08-19 19:58 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1af099ab04f1 [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 From zgu at redhat.com Fri Feb 28 13:26:12 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 28 Feb 2020 08:26:12 -0500 Subject: RFR (XS) 8240216: Shenandoah: remove ShenandoahTerminationTrace In-Reply-To: References: Message-ID: <96a74fad-6463-8793-8ffb-60d62254cd0e@redhat.com> On 2/28/20 4:53 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8240216 > > This was the diagnostic option for working on improving the termination protocol. Now that VM had > moved globally to OWST as termination protocol, this seems to only increase the maintenance burden. > The option is turned off by default already. > > Zhengyu, do you agree? Okay. -Zhengyu > > Webrev: > https://cr.openjdk.java.net/~shade/8240216/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Fri Feb 28 14:24:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Feb 2020 15:24:06 +0100 Subject: RFR (S) 8240217: Shenandoah: remove ShenandoahEvacAssist In-Reply-To: References: Message-ID: <633fc9e0-5b2c-9be4-8c74-0a29149cb0ef@redhat.com> On 2/28/20 11:52 AM, Roman Kennke wrote: > Have you done any performance experiments? Just finished: no improvement/regressions, unless it hides in the noise. -- Thanks, -Aleksey From roman at kennke.org Fri Feb 28 14:32:12 2020 From: roman at kennke.org (Roman Kennke) Date: Fri, 28 Feb 2020 15:32:12 +0100 Subject: RFR (S) 8240217: Shenandoah: remove ShenandoahEvacAssist In-Reply-To: <633fc9e0-5b2c-9be4-8c74-0a29149cb0ef@redhat.com> References: <633fc9e0-5b2c-9be4-8c74-0a29149cb0ef@redhat.com> Message-ID: <444be34b-6f49-5717-f29f-39b535658c21@kennke.org> >> Have you done any performance experiments? > > Just finished: no improvement/regressions, unless it hides in the noise. Ok. Please push it! Roman From gnu.andrew at redhat.com Fri Feb 28 16:17:09 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Feb 2020 16:17:09 +0000 Subject: [RFR] [8u] 8u252-b04 Upstream Sync In-Reply-To: <01b9606e-91a8-0322-a4bd-a655cbaafa8f@redhat.com> References: <08f2d707-f3a3-4b4f-555f-f8e591bf76c7@redhat.com> <01b9606e-91a8-0322-a4bd-a655cbaafa8f@redhat.com> Message-ID: <166ee420-02e9-b4c4-2c9d-b37ee3747aeb@redhat.com> On 28/02/2020 11:05, Aleksey Shipilev wrote: > On 2/28/20 5:54 AM, Andrew Hughes wrote: >> Merge changesets: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jaxws/merge.changeset > > Look trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/jdk/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/hotspot/merge.changeset > > Look good. I am a bit uneasy about synchronizer.cpp changes, but they seem to look safe. Right, but that's an upstream issue, not one with the merge. This is a backport of JDK-8047212 [0] from Felix Yang at Huawei. It's been in OpenJDK since 9 (so 11 had it from GA). I reviewed the backport [1] and it's mostly clean, other than the ObjectMonitor not being inside a PaddedEnd in 8u. It was originally posted in August of last year, so there's been more than sufficient time for someone else to look it over. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b04/root/merge.changeset > > Look trivially good. > >> Ok to push? > > Yes, I think so. > Thanks, pushed. [0] https://bugs.openjdk.java.net/browse/JDK-8047212 [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011197.html -- 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 rkennke at redhat.com Fri Feb 28 21:32:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 28 Feb 2020 22:32:31 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-28 Message-ID: <0e0bb355-ffbd-a93d-f734-309f66fc2310@redhat.com> This is the last batch of sh/jdk8 backports for now. It backports the following fixes: JDK-8231293: Shenandoah: Traversal should not revive dead weak roots JDK-8232205: Shenandoah: missing "Update References" -> "Update Roots" tracing JDK-8232908: Shenandoah: compact heuristics has incorrect trigger "Free is lower than allocated recently" JDK-8234232: [TESTBUG] gc/shenandoah/jvmti/TestHeapDump.java fails with -Xcomp JDK-8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 JDK-8236732: Shenandoah: Stricter placement for oom-evac scopes JDK-8236181: C2: Remove useless step_over_gc_barrier() in int->bool conversion For JDK-8236732, I needed to re-work the PLL special handling (jdk8-specific) a little bit, so that it doesn't call pending_list_lock() (which does the LRB itself) and then blindly following this by another LRB. That is because it would attempt to re-enter the evac-oom-scope. Instead it now carefully loads the PLL (without its own LRB), and then does almost the same as the LRB, but doesn't check evac-in-progress (because we know we must be) and also doesn't enter evac-oom-scope (because we already have it). JDK-8233500 is peculiar because it kinda implies that G1 might be affected by the same problem, even in later jdks. However, I couldn't find what problem caused this fix, so I cannot say for sure. JDK-8234232 we don't have Reference.reachabilityFence(), I emulated this by basically copying the implementation from later JDKs into the test. Yes, it's an empty method call. Changesets: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-28/changesets.txt Webrev: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-28/webrev.00/ Testing: hotspot_gc_shenandoah Can I please get a review? Thanks, Roman From zgu at redhat.com Fri Feb 28 21:37:24 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 28 Feb 2020 16:37:24 -0500 Subject: [sh/jdk11u]: JVMTI related backports Message-ID: I would like to backport these two JVMTI heap walk related backports: 8237396: JvmtiTagMap::weak_oops_do() should not trigger barriers 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR The backports clear JVMTI related test failures. Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/jvmti_sh_jdk11u/webrev.00/ Test: hotspot_gc_shenandoah vmTestbase_nsk_jvmti vmTestbase_nsk_jdi Thanks, -Zhengyu From shade at redhat.com Sat Feb 29 05:45:07 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 29 Feb 2020 06:45:07 +0100 Subject: [sh/jdk11u]: JVMTI related backports In-Reply-To: References: Message-ID: On 2/28/20 10:37 PM, Zhengyu Gu wrote: > I would like to backport these two JVMTI heap walk related backports: > > 8237396: JvmtiTagMap::weak_oops_do() should not trigger barriers > 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR > > The backports clear JVMTI related test failures. > > Webrev: > http://cr.openjdk.java.net/~zgu/shenandoah/jvmti_sh_jdk11u/webrev.00/ If we want to cherry-pick 8237396 ahead of 11u, we have to protect it with UseShenandoahGC. I think like this: inline oop object_raw() { if (UseShenandoahGC) { return RawAccess<>::oop_load(object_addr()); } return object_peek(); } ...also the synopsis should reflect what is going on: Cherry-pick: 8237396: JvmtiTagMap::weak_oops_do() should not trigger barriers Otherwise looks fine -- Thanks, -Aleksey From shade at redhat.com Sat Feb 29 05:54:40 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 29 Feb 2020 06:54:40 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-28 In-Reply-To: <0e0bb355-ffbd-a93d-f734-309f66fc2310@redhat.com> References: <0e0bb355-ffbd-a93d-f734-309f66fc2310@redhat.com> Message-ID: On 2/28/20 10:32 PM, Roman Kennke wrote: > For JDK-8236732, I needed to re-work the PLL special handling > (jdk8-specific) a little bit, so that it doesn't call > pending_list_lock() (which does the LRB itself) and then blindly > following this by another LRB. That is because it would attempt to > re-enter the evac-oom-scope. Instead it now carefully loads the PLL > (without its own LRB), and then does almost the same as the LRB, but > doesn't check evac-in-progress (because we know we must be) and also > doesn't enter evac-oom-scope (because we already have it). Ugh. Ugly PLL again. You still better to assert evac-in-progress and evac-oom-scope then? > Webrev: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-28/webrev.00/ Otherwise looks good. -- Thanks, -Aleksey From rkennke at redhat.com Sat Feb 29 10:35:45 2020 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 29 Feb 2020 11:35:45 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-28 In-Reply-To: References: <0e0bb355-ffbd-a93d-f734-309f66fc2310@redhat.com> Message-ID: >> For JDK-8236732, I needed to re-work the PLL special handling >> (jdk8-specific) a little bit, so that it doesn't call >> pending_list_lock() (which does the LRB itself) and then blindly >> following this by another LRB. That is because it would attempt to >> re-enter the evac-oom-scope. Instead it now carefully loads the PLL >> (without its own LRB), and then does almost the same as the LRB, but >> doesn't check evac-in-progress (because we know we must be) and also >> doesn't enter evac-oom-scope (because we already have it). > > Ugh. Ugly PLL again. You still better to assert evac-in-progress and evac-oom-scope then? Right. I added assert for evac-in-progress. The assert for evac-oom-scope is in evacuate_object() already, and is not as straightforward as you may think, because it can only be asserted if not already gone through the protocol. IOW, we need the whole prologue of ::evacuate_object() anyway. http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-28/webrev.01/ Good now? Roman From shade at redhat.com Sat Feb 29 15:58:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 29 Feb 2020 16:58:14 +0100 Subject: RFR (sh/jdk8): Backport 2020-02-28 In-Reply-To: References: <0e0bb355-ffbd-a93d-f734-309f66fc2310@redhat.com> Message-ID: <9941810d-6ed4-8f63-ee1f-85a5c85a9f70@redhat.com> On 2/29/20 11:35 AM, Roman Kennke wrote: >>> For JDK-8236732, I needed to re-work the PLL special handling >>> (jdk8-specific) a little bit, so that it doesn't call >>> pending_list_lock() (which does the LRB itself) and then blindly >>> following this by another LRB. That is because it would attempt to >>> re-enter the evac-oom-scope. Instead it now carefully loads the PLL >>> (without its own LRB), and then does almost the same as the LRB, but >>> doesn't check evac-in-progress (because we know we must be) and also >>> doesn't enter evac-oom-scope (because we already have it). >> >> Ugh. Ugly PLL again. You still better to assert evac-in-progress and evac-oom-scope then? > > Right. I added assert for evac-in-progress. The assert for > evac-oom-scope is in evacuate_object() already, and is not as > straightforward as you may think, because it can only be asserted if not > already gone through the protocol. IOW, we need the whole prologue of > ::evacuate_object() anyway. > > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-02-28/webrev.01/ > > Good now? OK. -- Thanks, -Aleksey