From gnu.andrew at redhat.com Wed Apr 1 01:22:17 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 1 Apr 2020 02:22:17 +0100 Subject: [RFR] [8u] 8u252-b08 Upstream Sync Message-ID: <68d1f2ac-c6e6-0a4a-3fd1-620a84e9f7aa@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b08: - S8241296: Segfault in JNIHandleBlock::oops_do() - S8241307: Marlin renderer should not be the default in 8u252 Main issues of note: One HotSpot change applied cleanly, no merge work. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/src/share/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine | 7 + b/src/solaris/classes/sun/java2d/pisces/META-INF/services/sun.java2d.pipe.RenderingEngine | 9 +- b/test/sun/java2d/marlin/DefaultRenderingEngine.java | 42 ++++++++++ 4 files changed, 54 insertions(+), 5 deletions(-) diffstat for hotspot b/.hgtags | 1 + b/src/share/vm/runtime/thread.cpp | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Apr 1 10:19:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Apr 2020 12:19:16 +0200 Subject: RFR (XS) 8241926: Shenandoah: only print heap changes for operations that directly affect it Message-ID: <1803d191-e265-c398-ceaa-4a621ece613d@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8241926 Our current log prints the heap changes for every operation, including those that do not change the heap directly. It clutters the GC log unnecessarily. We might consider only printing heap changes for the ops that do affect either used() or capacity(). Example log is in the issue itself. Webrev: https://cr.openjdk.java.net/~shade/8241926/webrev.01/ Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 1 10:31:12 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 1 Apr 2020 12:31:12 +0200 Subject: RFR (XS) 8241926: Shenandoah: only print heap changes for operations that directly affect it In-Reply-To: <1803d191-e265-c398-ceaa-4a621ece613d@redhat.com> References: <1803d191-e265-c398-ceaa-4a621ece613d@redhat.com> Message-ID: <55f47e2c-7f6a-cde7-7274-7a85d476f5e6@redhat.com> Hi Aleksey, That makes sense, and the patch looks good. Thank you! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8241926 > > Our current log prints the heap changes for every operation, including those that do not change the > heap directly. It clutters the GC log unnecessarily. We might consider only printing heap changes > for the ops that do affect either used() or capacity(). > > Example log is in the issue itself. > > Webrev: > https://cr.openjdk.java.net/~shade/8241926/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From shade at redhat.com Wed Apr 1 11:55:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Apr 2020 13:55:03 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b08 Upstream Sync In-Reply-To: <68d1f2ac-c6e6-0a4a-3fd1-620a84e9f7aa@redhat.com> References: <68d1f2ac-c6e6-0a4a-3fd1-620a84e9f7aa@redhat.com> Message-ID: <82a66f85-76d4-c5b1-a11f-136a0a949095@redhat.com> On 4/1/20 3:22 AM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/jaxws/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/jdk/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b08/root/merge.changeset All look good. > Ok to push? Yes, please. -- Thanks, -Aleksey From shade at redhat.com Wed Apr 1 12:16:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Apr 2020 14:16:21 +0200 Subject: RFR (XS) 8241983: Shenandoah: simplify FreeSet logging Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8241983 Webrev: https://cr.openjdk.java.net/~shade/8241983/webrev.01/ See the log examples in the issue itself. Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Wed Apr 1 12:17:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Apr 2020 14:17:35 +0200 Subject: RFR (XS) 8241985: Shenandoah: simplify collectable garbage logging Message-ID: <3344a946-4bec-5ba8-25c2-50cb65aab1fe@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8241985 Webrev: https://cr.openjdk.java.net/~shade/8241985/webrev.01/ See the log examples in the issue itself. Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 1 12:21:10 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 1 Apr 2020 14:21:10 +0200 Subject: RFR (XS) 8241983: Shenandoah: simplify FreeSet logging In-Reply-To: References: Message-ID: Patch looks good. No GC-ID anymore? Or is it useless in this context? Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8241983 > > Webrev: > https://cr.openjdk.java.net/~shade/8241983/webrev.01/ > > See the log examples in the issue itself. > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From shade at redhat.com Wed Apr 1 12:22:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Apr 2020 14:22:10 +0200 Subject: RFR (XS) 8241983: Shenandoah: simplify FreeSet logging In-Reply-To: References: Message-ID: <02beccb6-92fa-d35c-1fd4-584b8a2ddaee@redhat.com> On 4/1/20 2:21 PM, Roman Kennke wrote: > Patch looks good. No GC-ID anymore? Or is it useless in this context? GCId is there. One of the examples was taken for the logging message outside of cycle. -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 1 12:23:34 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 1 Apr 2020 14:23:34 +0200 Subject: RFR (XS) 8241985: Shenandoah: simplify collectable garbage logging In-Reply-To: <3344a946-4bec-5ba8-25c2-50cb65aab1fe@redhat.com> References: <3344a946-4bec-5ba8-25c2-50cb65aab1fe@redhat.com> Message-ID: Looks good! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8241985 > > Webrev: > https://cr.openjdk.java.net/~shade/8241985/webrev.01/ > > See the log examples in the issue itself. > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From rkennke at redhat.com Wed Apr 1 12:24:00 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 1 Apr 2020 14:24:00 +0200 Subject: RFR (XS) 8241983: Shenandoah: simplify FreeSet logging In-Reply-To: <02beccb6-92fa-d35c-1fd4-584b8a2ddaee@redhat.com> References: <02beccb6-92fa-d35c-1fd4-584b8a2ddaee@redhat.com> Message-ID: <936cc3a3-2a59-aea3-dce8-8a6618f6b97c@redhat.com> > On 4/1/20 2:21 PM, Roman Kennke wrote: >> Patch looks good. No GC-ID anymore? Or is it useless in this context? > > GCId is there. One of the examples was taken for the logging message outside of cycle. Ok then! Thanks, Roman From shade at redhat.com Wed Apr 1 12:23:53 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 1 Apr 2020 14:23:53 +0200 Subject: [14] RFR 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata In-Reply-To: References: Message-ID: <994a78b4-2968-433d-4704-1b66ea7de8d3@redhat.com> On 3/31/20 2:54 AM, Zhengyu Gu wrote: > Original bug: https://bugs.openjdk.java.net/browse/JDK-8239926 > Original webrev: http://cr.openjdk.java.net/~zgu/JDK-8239926/webrev.04/ > > 14u webrev: http://cr.openjdk.java.net/~zgu/JDK-8239926/14u/webrev.00/ 14u backport looks fine. -- Thanks, -Aleksey From shade at redhat.com Thu Apr 2 13:41:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 2 Apr 2020 15:41:02 +0200 Subject: RFR (XS) 8242040: Shenandoah: print allocation failure type Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8242040 Webrev: http://cr.openjdk.java.net/~shade/8242040/webrev.01/ Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Thu Apr 2 13:43:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 2 Apr 2020 15:43:39 +0200 Subject: RFR (S) 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target Message-ID: <2edcefce-769c-9ae7-ab23-9f2695d7b48c@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242041 See the explanation in bug report. Webrev: https://cr.openjdk.java.net/~shade/8242041/webrev.01/ Testing: hotspot_gc_shenandoah, benchmarks, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Thu Apr 2 13:45:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 2 Apr 2020 15:45:28 +0200 Subject: RFR (XS) 8242042: Shenandoah: tune down ShenandoahGarbageThreshold Message-ID: <61a41c0a-3db8-d985-d28e-54d7efc56c86@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242042 See the discussion in the bug report. No regressions found on benchmarks with mostly-dead heaps. Improvements found on benchmarks with moderately-fragmented heaps. Patch: diff -r 56444036b262 src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Thu Apr 02 15:33:07 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Thu Apr 02 15:44:17 2020 +0200 @@ -92,15 +92,16 @@ experimental(uintx, ShenandoahUnloadClassesFrequency, 1, \ "Unload the classes every Nth cycle. Normally affects concurrent "\ "GC cycles, as degenerated and full GCs would try to unload " \ "classes regardless. Set to zero to disable class unloading.") \ \ - experimental(uintx, ShenandoahGarbageThreshold, 60, \ + experimental(uintx, ShenandoahGarbageThreshold, 25, \ "How much garbage a region has to contain before it would be " \ - "taken for collection. This a guideline only , as GC heuristics " \ + "taken for collection. This a guideline only, as GC heuristics " \ "may select the region for collection even if it has little " \ - "garbage. In percents of heap region size.") \ + "garbage. This also affects how much internal fragmentation the " \ + "collector accepts. In percents of heap region size.") \ range(0,100) \ \ experimental(uintx, ShenandoahInitFreeThreshold, 70, \ "How much heap should be free before some heuristics trigger the "\ "initial (learning) cycles. Affects cycle frequency on startup " \ TEsting: hotspot_gc_shenandoah, eyeballing gc logs, benchmarks -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 2 15:04:36 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 2 Apr 2020 17:04:36 +0200 Subject: RFR (S) 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target In-Reply-To: <2edcefce-769c-9ae7-ab23-9f2695d7b48c@redhat.com> References: <2edcefce-769c-9ae7-ab23-9f2695d7b48c@redhat.com> Message-ID: <60647c10-0b96-d166-2dd6-de6c96383ef0@redhat.com> Looks good! Thank you! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242041 > > See the explanation in bug report. > > Webrev: > https://cr.openjdk.java.net/~shade/8242041/webrev.01/ > > Testing: hotspot_gc_shenandoah, benchmarks, eyeballing gc logs > From rkennke at redhat.com Thu Apr 2 15:05:06 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 2 Apr 2020 17:05:06 +0200 Subject: RFR (XS) 8242042: Shenandoah: tune down ShenandoahGarbageThreshold In-Reply-To: <61a41c0a-3db8-d985-d28e-54d7efc56c86@redhat.com> References: <61a41c0a-3db8-d985-d28e-54d7efc56c86@redhat.com> Message-ID: <0e98745e-7e57-8c8d-b5a2-19e48a9c4a5e@redhat.com> Yes. I also run some stuff and did not see a regression. Thank you, Roman Am 02.04.20 um 15:45 schrieb Aleksey Shipilev: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242042 > > See the discussion in the bug report. No regressions found on benchmarks with mostly-dead heaps. > Improvements found on benchmarks with moderately-fragmented heaps. > > Patch: > > diff -r 56444036b262 src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Thu Apr 02 15:33:07 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Thu Apr 02 15:44:17 2020 +0200 > @@ -92,15 +92,16 @@ > experimental(uintx, ShenandoahUnloadClassesFrequency, 1, \ > "Unload the classes every Nth cycle. Normally affects concurrent "\ > "GC cycles, as degenerated and full GCs would try to unload " \ > "classes regardless. Set to zero to disable class unloading.") \ > \ > - experimental(uintx, ShenandoahGarbageThreshold, 60, \ > + experimental(uintx, ShenandoahGarbageThreshold, 25, \ > "How much garbage a region has to contain before it would be " \ > - "taken for collection. This a guideline only , as GC heuristics " \ > + "taken for collection. This a guideline only, as GC heuristics " \ > "may select the region for collection even if it has little " \ > - "garbage. In percents of heap region size.") \ > + "garbage. This also affects how much internal fragmentation the " \ > + "collector accepts. In percents of heap region size.") \ > range(0,100) \ > \ > experimental(uintx, ShenandoahInitFreeThreshold, 70, \ > "How much heap should be free before some heuristics trigger the "\ > "initial (learning) cycles. Affects cycle frequency on startup " \ > > TEsting: hotspot_gc_shenandoah, eyeballing gc logs, benchmarks > From rkennke at redhat.com Thu Apr 2 15:03:01 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 2 Apr 2020 17:03:01 +0200 Subject: RFR (XS) 8242040: Shenandoah: print allocation failure type In-Reply-To: References: Message-ID: <55769242-7d80-b4e4-a871-c21e746b5cd5@redhat.com> Ok. Thank you! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242040 > > Webrev: > http://cr.openjdk.java.net/~shade/8242040/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From rkennke at redhat.com Thu Apr 2 19:23:41 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 2 Apr 2020 21:23:41 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode Message-ID: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> Some of our users like some properties of the marking/traversal behaviour of the Traversal mode, but would also like the benefits and ergonomics of the normal mode. It turns out that it is relatively easy to transplant the barrier-model of Traversal mode into the regular mode. This is essentially a variant of the well-known incremental-update model of concurrent marking. We already have all the barrier-foo that we need from the Traversal mode. The following modifications are required to make it work with regular mode: - Arraycopy-barriers must mark through src instead of dst (we're interested in the new-values not in the previous-valuses). They must also trigger when dest is uninitialized (esp in the ASM prologue calls) - Related to this, clone-barriers now also need to mark through the src-object. (SATB doesn't need this because destination is by definition uninitialized). - Both clone and arraycopy-barriers can skip marking the src obj/array if the src is allocated-after-mark-start: in this case it's guaranteed by the barrier model than any reference in them must already have gone through a barrier. - C2 code sees some adjustments to allow marking-active checks when expanding ShenandoahStoreValEnqueueBarrierNode. It previously only checked HAS_FORWARDED to account for Traversal-active. It also adds MARKING to the state-check for the clone-barrier. - I removed the flags-checks from aggressive/compact/static heuristics. This is now checked in shenandoahNormalMode.cpp (and is consistent with adaptive) - I introduced a new mode called ShenandoahIUMode, mapped to ShenandoahGCMode=iu, which sets the flags for this new mode. - I added no testing yet. The plan is to change traversal tests to iu tests if/when Traversal gets eliminated. - I did, however, test everything in shenandoah/jdk by changing the default mode to iu. Bug: https://bugs.openjdk.java.net/browse/JDK-8242054 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.00/ Testing: hotspot_gc_shenandoah clean. Deeper testing with shenandoah/jdk is looking good too. I ran specjvm and specjbb many times, and have seen no problems. Performance looks similar to normal-mode too. One early tester has confirmed that behaviour is as-expected like with traversal-mode. Can I please get a review? Thanks, Roman From shade at redhat.com Fri Apr 3 07:51:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 09:51:23 +0200 Subject: RFR (S) 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8242075 There are ShenandoahMinRegionSize and ShenandoahMaxRegionSize flags. Having Shenandoah*Heap*RegionSize that overrides them is not very clear. Let's rename it to ShenandoahRegionSize. Webrev: https://cr.openjdk.java.net/~shade/8242075/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Fri Apr 3 08:04:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 10:04:52 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> Message-ID: <25192585-457e-4769-183c-fb635d029348@redhat.com> On 4/2/20 9:23 PM, Roman Kennke wrote: > Some of our users like some properties of the marking/traversal > behaviour of the Traversal mode, but would also like the benefits and > ergonomics of the normal mode. It turns out that it is relatively easy > to transplant the barrier-model of Traversal mode into the regular mode. > This is essentially a variant of the well-known incremental-update model > of concurrent marking. > > We already have all the barrier-foo that we need from the Traversal > mode. The following modifications are required to make it work with > regular mode: > > - Arraycopy-barriers must mark through src instead of dst (we're > interested in the new-values not in the previous-valuses). They must > also trigger when dest is uninitialized (esp in the ASM prologue calls) > - Related to this, clone-barriers now also need to mark through the > src-object. (SATB doesn't need this because destination is by definition > uninitialized). > - Both clone and arraycopy-barriers can skip marking the src obj/array > if the src is allocated-after-mark-start: in this case it's guaranteed > by the barrier model than any reference in them must already have gone > through a barrier. > - C2 code sees some adjustments to allow marking-active checks when > expanding ShenandoahStoreValEnqueueBarrierNode. It previously only > checked HAS_FORWARDED to account for Traversal-active. It also adds > MARKING to the state-check for the clone-barrier. > - I removed the flags-checks from aggressive/compact/static heuristics. > This is now checked in shenandoahNormalMode.cpp (and is consistent with > adaptive) > - I introduced a new mode called ShenandoahIUMode, mapped to > ShenandoahGCMode=iu, which sets the flags for this new mode. > - I added no testing yet. The plan is to change traversal tests to iu > tests if/when Traversal gets eliminated. > - I did, however, test everything in shenandoah/jdk by changing the > default mode to iu. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8242054 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.00/ *) I would prefer for flag checks to be first. It makes it clearer to me that path is only taken in some configurations. Example, this: if (dest_uninitialized && ShenandoahSATBBarrier) ... ...becomes this: if (ShenandoahSATBBarrier && dest_uninitialized) ... *) These blocks should not be removed. At very least we want to make the check for SATB/StoreVal barrier conditional on the mode. But other barrier checks should definitely stay. 47 // Final configuration checks 48 SHENANDOAH_CHECK_FLAG_SET(ShenandoahLoadRefBarrier); 49 SHENANDOAH_CHECK_FLAG_SET(ShenandoahSATBBarrier); 50 SHENANDOAH_CHECK_FLAG_SET(ShenandoahCASBarrier); 51 SHENANDOAH_CHECK_FLAG_SET(ShenandoahCloneBarrier); *) This is some local madness: 84 int gc_state = _heap->gc_state(); 85 if ((gc_state & ShenandoahHeap::MARKING) != 0 && 86 ShenandoahStoreValEnqueueBarrier && 87 !_heap->marking_context()->allocated_after_mark_start(obj)) { 88 ShenandoahUpdateRefsForOopClosure cl; 89 obj->oop_iterate(&cl); 90 } else if ((gc_state & ShenandoahHeap::HAS_FORWARDED) != 0) { 91 if (skip_bulk_update(cast_from_oop(obj))) return; Do we really need to read the gc_state and then mask it, instead of just checking heap->is_concurrent_mark_in_progress()? Why check for has_forwarded on the else branch? asserting has_forwarded_objects is futile on that branch too. It looks to me the whole thing is: if (ShenandoahStoreValEnqueueBarrier && _heap->is_concurrent_marking_in_progress() && !_heap->marking_context()->allocated_after_mark_start(obj)) { ShenandoahUpdateRefsForOopClosure cl; obj->oop_iterate(&cl); return; } assert(_heap->has_forwarded_objects(), "only when heap is unstable"); if (skip_bulk_update(cast_from_oop(obj))) return; if (_heap->is_evacuation_in_progress()) { ... } else if (_heap->is_concurrent_traversal_in_progress()) { ... } else { ... } *) I don't think the rewrite in ShFinalMarkTask is equivalent. See, on the path here: 262 ShenandoahSATBAndRemarkCodeRootsThreadsClosure tc(&cl, 263 ShenandoahStoreValEnqueueBarrier ? &mark_cl : NULL, 264 &blobsCl); ...we used to pass NULL as blobsCL when do_nmethods is false. *) Also, why ResourceMark here? 199 if (_cl != NULL) { 200 ResourceMark rm; 201 thread->oops_do(_cl, _code_cl); -- Thanks, -Aleksey From rkennke at redhat.com Fri Apr 3 08:51:28 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 10:51:28 +0200 Subject: RFR (S) 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag In-Reply-To: References: Message-ID: <1c54046d-407b-6107-c97a-6303f3372d8f@redhat.com> > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242075 > > There are ShenandoahMinRegionSize and ShenandoahMaxRegionSize flags. Having > Shenandoah*Heap*RegionSize that overrides them is not very clear. Let's rename it to > ShenandoahRegionSize. Indeed. I have also stumbled over this a couple of times. > Webrev: > https://cr.openjdk.java.net/~shade/8242075/webrev.01/ > > Testing: hotspot_gc_shenandoah The patch looks good, thank you! Roman From rkennke at redhat.com Fri Apr 3 10:16:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 12:16:31 +0200 Subject: RFR: 8242082: Shenandoah: Purge Traversal mode Message-ID: <53511d36-1739-cac6-5fa7-378b39c73c63@redhat.com> Traversal mode has become cumbersome to maintain. Every single non-trivial feature required extra work to play with Traversal, and usually caused a trail of follow-up issues. And all that for little gain. We are transplanting the interesting properties to the upcoming I-U mode (which is much less trouble-some), and can ditch Traversal mode altogether. My original plan was to ditch it after I-U is in, but now I want to do a couple of cleanups before I-U and I'm not in the mood to special-case Traversal there. Let's get rid of it ahead of time. Issue: https://bugs.openjdk.java.net/browse/JDK-8242082 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8242082/webrev.00/ Testing: hotspot_gc_shenandoah builds and tests fine. Ok? Roman From shade at redhat.com Fri Apr 3 10:36:30 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 12:36:30 +0200 Subject: RFR: 8242082: Shenandoah: Purge Traversal mode In-Reply-To: <53511d36-1739-cac6-5fa7-378b39c73c63@redhat.com> References: <53511d36-1739-cac6-5fa7-378b39c73c63@redhat.com> Message-ID: <3f9bb525-2c31-fed8-3408-4c8fd0096f8c@redhat.com> On 4/3/20 12:16 PM, Roman Kennke wrote: > Traversal mode has become cumbersome to maintain. Every single > non-trivial feature required extra work to play with Traversal, and > usually caused a trail of follow-up issues. And all that for little > gain. We are transplanting the interesting properties to the upcoming > I-U mode (which is much less trouble-some), and can ditch Traversal mode > altogether. > > My original plan was to ditch it after I-U is in, but now I want to do a > couple of cleanups before I-U and I'm not in the mood to special-case > Traversal there. Let's get rid of it ahead of time. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8242082 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8242082/webrev.00/ Good riddance. *) Do you have any hits if your grep for "traversal" / "Traversal" on the new code? When I was playing with my own removal, that highlighted some easy things to ditch. *) The removal of ShenandoahConcurrentRoots::can_do_concurrent_roots seems premature. It mirrors other {can|should}_do_* things. I understand it would return true all the time, that seems fine. *) The addition of is_concurrent_mark_in_progress is weird here. Should be deferred to IU? 88 inline void ShenandoahBarrierSet::storeval_barrier(oop obj) { 89 if (obj != NULL && ShenandoahStoreValEnqueueBarrier && 90 _heap->is_concurrent_mark_in_progress()) { 91 enqueue(obj); 92 } 93 } *) In ShenandoahForwardedIsAliveClosure::do_object_b, can drop parentheses around the last arg and put it on new line? 45 shenandoah_assert_not_forwarded_if(NULL, obj, 46 (ShenandoahHeap::heap()->is_concurrent_mark_in_progress())) -- Thanks, -Aleksey From shade at redhat.com Fri Apr 3 10:42:26 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 12:42:26 +0200 Subject: RFR: 8242082: Shenandoah: Purge Traversal mode In-Reply-To: <3f9bb525-2c31-fed8-3408-4c8fd0096f8c@redhat.com> References: <53511d36-1739-cac6-5fa7-378b39c73c63@redhat.com> <3f9bb525-2c31-fed8-3408-4c8fd0096f8c@redhat.com> Message-ID: On 4/3/20 12:36 PM, Aleksey Shipilev wrote: > On 4/3/20 12:16 PM, Roman Kennke wrote: >> Traversal mode has become cumbersome to maintain. Every single >> non-trivial feature required extra work to play with Traversal, and >> usually caused a trail of follow-up issues. And all that for little >> gain. We are transplanting the interesting properties to the upcoming >> I-U mode (which is much less trouble-some), and can ditch Traversal mode >> altogether. >> >> My original plan was to ditch it after I-U is in, but now I want to do a >> couple of cleanups before I-U and I'm not in the mood to special-case >> Traversal there. Let's get rid of it ahead of time. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8242082 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8242082/webrev.00/ > > Good riddance. Oh, and since you are purging seqnums from SHR, you might as well purge this: 225 // Global allocation counter, increased for each allocation under Shenandoah heap lock. 226 // Padded to avoid false sharing with the read-only fields above. 227 struct PaddedAllocSeqNum { 228 shenandoah_padding(0); 229 uint64_t value; 230 shenandoah_padding(1); 231 232 PaddedAllocSeqNum() { 233 // start with 1, reserve 0 for uninitialized value 234 value = 1; 235 } 236 }; 237 238 static PaddedAllocSeqNum _alloc_seq_num; ...or leave it to me for the followup. -- Thanks, -Aleksey From shade at redhat.com Fri Apr 3 11:27:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 13:27:25 +0200 Subject: RFR (XS) 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters Message-ID: <111be665-75f4-9dfe-f060-76b27341d937@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242083 Need this to follow up on performance behaviors with lots of regions better. Webrev: https://cr.openjdk.java.net/~shade/8242083/webrev.01/ Logs before/after: https://cr.openjdk.java.net/~shade/8242083/before.txt https://cr.openjdk.java.net/~shade/8242083/after.txt Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Fri Apr 3 11:31:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 13:31:21 +0200 Subject: RFR (S) 8242089: Shenandoah: per-worker stats should be summed up, not averaged Message-ID: <6c0451f2-71a9-3dfe-7e3d-28e9bad207ce@redhat.com> RFE: https://cr.openjdk.java.net/~shade/8242089/webrev.01/ Rationale is in the RFE. Webrev: https://cr.openjdk.java.net/~shade/8242089/webrev.01/ Logs before/after: https://cr.openjdk.java.net/~shade/8242089/before.txt https://cr.openjdk.java.net/~shade/8242089/after.txt Testing: hotspot_gc_shenandoah, eyeballing logs -- Thanks, -Aleksey From rkennke at redhat.com Fri Apr 3 11:49:36 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 13:49:36 +0200 Subject: RFR (XS) 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters In-Reply-To: <111be665-75f4-9dfe-f060-76b27341d937@redhat.com> References: <111be665-75f4-9dfe-f060-76b27341d937@redhat.com> Message-ID: <28bf9948-7326-50c5-c2cd-fcfcae770759@redhat.com> Ok. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242083 > > Need this to follow up on performance behaviors with lots of regions better. > > Webrev: > https://cr.openjdk.java.net/~shade/8242083/webrev.01/ > > Logs before/after: > https://cr.openjdk.java.net/~shade/8242083/before.txt > https://cr.openjdk.java.net/~shade/8242083/after.txt > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From rkennke at redhat.com Fri Apr 3 11:51:25 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 13:51:25 +0200 Subject: RFR (S) 8242089: Shenandoah: per-worker stats should be summed up, not averaged In-Reply-To: <6c0451f2-71a9-3dfe-7e3d-28e9bad207ce@redhat.com> References: <6c0451f2-71a9-3dfe-7e3d-28e9bad207ce@redhat.com> Message-ID: Hi Aleksey, > RFE: > https://cr.openjdk.java.net/~shade/8242089/webrev.01/ > > Rationale is in the RFE. Yes. And the RFE is here: https://bugs.openjdk.java.net/browse/JDK-8242089 > Webrev: > https://cr.openjdk.java.net/~shade/8242089/webrev.01/ > > Logs before/after: > https://cr.openjdk.java.net/~shade/8242089/before.txt > https://cr.openjdk.java.net/~shade/8242089/after.txt > > Testing: hotspot_gc_shenandoah, eyeballing logs > Looks good. Thank you! Roman From shade at redhat.com Fri Apr 3 12:20:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 14:20:57 +0200 Subject: RFR (S) 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses Message-ID: <8f42f103-d43e-75a1-749c-af8f32ac7064@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242101 We are walking heap regions multiple times during final mark pause. We also walk them during final update refs pause without any parallelism. We should really fix those, to allow more regions per heap. Webrev: https://cr.openjdk.java.net/~shade/8242101/webrev.01/ I had to drop shenandoah_assert_heaplocked_or_safepoint from update_watermark, because it expects that we are called from VMThread at safepoint, and with this patch, we are not. By my count, the whole thing saves about 50us in pauses with the default number of regions. Testing: hotspot_gc_shenandoah, benchmarks -- Thanks, -Aleksey From rkennke at redhat.com Fri Apr 3 12:28:10 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 14:28:10 +0200 Subject: RFR (S) 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses In-Reply-To: <8f42f103-d43e-75a1-749c-af8f32ac7064@redhat.com> References: <8f42f103-d43e-75a1-749c-af8f32ac7064@redhat.com> Message-ID: <3a78d1d8-15e3-156d-f380-95fde3f81412@redhat.com> Very nice! Patch looks good. Thank you! Roman Am 03.04.20 um 14:20 schrieb Aleksey Shipilev: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242101 > > We are walking heap regions multiple times during final mark pause. We also walk them during final > update refs pause without any parallelism. We should really fix those, to allow more regions per heap. > > Webrev: > https://cr.openjdk.java.net/~shade/8242101/webrev.01/ > > I had to drop shenandoah_assert_heaplocked_or_safepoint from update_watermark, because it expects > that we are called from VMThread at safepoint, and with this patch, we are not. > > By my count, the whole thing saves about 50us in pauses with the default number of regions. > > Testing: hotspot_gc_shenandoah, benchmarks > From rkennke at redhat.com Fri Apr 3 12:56:44 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 14:56:44 +0200 Subject: RFR: 8242082: Shenandoah: Purge Traversal mode In-Reply-To: <3f9bb525-2c31-fed8-3408-4c8fd0096f8c@redhat.com> References: <53511d36-1739-cac6-5fa7-378b39c73c63@redhat.com> <3f9bb525-2c31-fed8-3408-4c8fd0096f8c@redhat.com> Message-ID: Hi Aleksey, >> Traversal mode has become cumbersome to maintain. Every single >> non-trivial feature required extra work to play with Traversal, and >> usually caused a trail of follow-up issues. And all that for little >> gain. We are transplanting the interesting properties to the upcoming >> I-U mode (which is much less trouble-some), and can ditch Traversal mode >> altogether. >> >> My original plan was to ditch it after I-U is in, but now I want to do a >> couple of cleanups before I-U and I'm not in the mood to special-case >> Traversal there. Let's get rid of it ahead of time. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8242082 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8242082/webrev.00/ > > Good riddance. > > *) Do you have any hits if your grep for "traversal" / "Traversal" on the new code? When I was > playing with my own removal, that highlighted some easy things to ditch. > > *) The removal of ShenandoahConcurrentRoots::can_do_concurrent_roots seems premature. It mirrors > other {can|should}_do_* things. I understand it would return true all the time, that seems fine. > > *) The addition of is_concurrent_mark_in_progress is weird here. Should be deferred to IU? > > 88 inline void ShenandoahBarrierSet::storeval_barrier(oop obj) { > 89 if (obj != NULL && ShenandoahStoreValEnqueueBarrier && > 90 _heap->is_concurrent_mark_in_progress()) { > 91 enqueue(obj); > 92 } > 93 } > > *) In ShenandoahForwardedIsAliveClosure::do_object_b, can drop parentheses around the last arg and > put it on new line? > > 45 shenandoah_assert_not_forwarded_if(NULL, obj, > 46 (ShenandoahHeap::heap()->is_concurrent_mark_in_progress())) > I added all your suggestions, plus removed the last remaining seq_num stuff from ShHeapRegion as you suggested in the other email: http://cr.openjdk.java.net/~rkennke/JDK-8242082/webrev.02/ Tests are still passing fine. Roman From shade at redhat.com Fri Apr 3 13:02:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 15:02:21 +0200 Subject: RFR: 8242082: Shenandoah: Purge Traversal mode In-Reply-To: References: <53511d36-1739-cac6-5fa7-378b39c73c63@redhat.com> <3f9bb525-2c31-fed8-3408-4c8fd0096f8c@redhat.com> Message-ID: <49179a5f-e4ed-e47a-df73-b35d7a3c72ea@redhat.com> On 4/3/20 2:56 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8242082/webrev.02/ *) Missing space after comma in shenandoahClosures.inline.hpp now: 45 shenandoah_assert_not_forwarded_if(NULL, obj,ShenandoahHeap::heap()->is_concurrent_mark_in_progress()); Otherwise looks good! Fix the nit above before push. I think there would be some minor conflicts if you pull in recent changes from jdk/jdk. -- Thanks, -Aleksey From rkennke at redhat.com Fri Apr 3 13:33:49 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 15:33:49 +0200 Subject: RFR(T): 8242107: Shenandoah: Fix aarch64 build after JDK-8242082 Message-ID: <8dc4f445-0ca8-75eb-0eea-be1485e72686@redhat.com> I forgot to remove one traversal reference in aarch64 asm code in JDK-8242082. Ok? diff -r d8d2145c205c -r dfaf0661932c src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp --- a/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp Fri Apr 03 15:06:08 2020 +0200 +++ b/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp Fri Apr 03 15:32:35 2020 +0200 @@ -616,7 +616,7 @@ // Is marking still active? Address gc_state(thread, in_bytes(ShenandoahThreadLocalData::gc_state_offset())); __ ldrb(tmp, gc_state); - __ mov(rscratch2, ShenandoahHeap::MARKING | ShenandoahHeap::TRAVERSAL); + __ mov(rscratch2, ShenandoahHeap::MARKING); __ tst(tmp, rscratch2); __ br(Assembler::EQ, done); From shade at redhat.com Fri Apr 3 13:43:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 15:43:11 +0200 Subject: RFR(T): 8242107: Shenandoah: Fix aarch64 build after JDK-8242082 In-Reply-To: <8dc4f445-0ca8-75eb-0eea-be1485e72686@redhat.com> References: <8dc4f445-0ca8-75eb-0eea-be1485e72686@redhat.com> Message-ID: On 4/3/20 3:33 PM, Roman Kennke wrote: > diff -r d8d2145c205c -r dfaf0661932c > src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp > --- > a/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp > Fri Apr 03 15:06:08 2020 +0200 > +++ > b/src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp > Fri Apr 03 15:32:35 2020 +0200 > @@ -616,7 +616,7 @@ > // Is marking still active? > Address gc_state(thread, > in_bytes(ShenandoahThreadLocalData::gc_state_offset())); > __ ldrb(tmp, gc_state); > - __ mov(rscratch2, ShenandoahHeap::MARKING | ShenandoahHeap::TRAVERSAL); > + __ mov(rscratch2, ShenandoahHeap::MARKING); > __ tst(tmp, rscratch2); > __ br(Assembler::EQ, done); Looks good and trivial. -- Thanks, -Aleksey From shade at redhat.com Fri Apr 3 14:29:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 Apr 2020 16:29:01 +0200 Subject: RFR (S) 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8242114 This is a follow-up after removal of shared-alloc-counter (JDK-8241841) and removal of Traversal (JDK- 8242082). ShenandoahHeapRegion::reset_alloc_metadata_to_shared is now the same as ShenandoahHeapRegion::reset_alloc_metadata. Humongous allocation path also does not need resets, because the alloc metadata is already clean there. Webrev: https://cr.openjdk.java.net/~shade/8242114/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Fri Apr 3 17:52:13 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 19:52:13 +0200 Subject: RFR (S) 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared In-Reply-To: References: Message-ID: Ok! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242114 > > This is a follow-up after removal of shared-alloc-counter (JDK-8241841) and removal of Traversal > (JDK- 8242082). ShenandoahHeapRegion::reset_alloc_metadata_to_shared is now the same as > ShenandoahHeapRegion::reset_alloc_metadata. Humongous allocation path also does not need resets, > because the alloc metadata is already clean there. > > Webrev: > https://cr.openjdk.java.net/~shade/8242114/webrev.01/ > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Fri Apr 3 19:13:11 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 3 Apr 2020 21:13:11 +0200 Subject: RFR: 8242130: Shenandoah: Simplify arraycopy-barrier dispatching Message-ID: Currently, calling the arraycopy dispatches 3 times in a row: 1. In the asm stub (GC or no GC) 2. In arraycopy_pre (marking or evac/update) 3. In arraycopy_update (evac or update) This can be simplified by doing only the fast-path branch in asm stub, and the GC-phase dispatch once in the runtime. In addition, there are various cleanups that can be done on the way. Issue: https://bugs.openjdk.java.net/browse/JDK-8242130 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8242130/webrev.00/ Testing: hotspot_gc_shenandoah (x86/aarch64) Ok? Roman From rkennke at redhat.com Sat Apr 4 00:26:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 4 Apr 2020 02:26:31 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: <25192585-457e-4769-183c-fb635d029348@redhat.com> References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> Message-ID: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8242054 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.00/ I rebased this patch on top of "JDK-8242130: Shenandoah: Simplify arraycopy-barrier dispatching" Now that we purged traversal-mode, I also added tests for IU mode, by (mostly) mechanically adding back the tests that I removed with Traversal mode, and change ShenandoahGCMode=traversal -> ShenandoahGCMode=iu. > *) I would prefer for flag checks to be first. It makes it clearer to me that path is only taken in > some configurations. Example, this: > if (dest_uninitialized && ShenandoahSATBBarrier) ... > ...becomes this: > if (ShenandoahSATBBarrier && dest_uninitialized) ... Right. Fixed the occurances that I found (the mentioned one is gone with JDK-8242130. > *) These blocks should not be removed. At very least we want to make the check for SATB/StoreVal > barrier conditional on the mode. But other barrier checks should definitely stay. > > 47 // Final configuration checks > 48 SHENANDOAH_CHECK_FLAG_SET(ShenandoahLoadRefBarrier); > 49 SHENANDOAH_CHECK_FLAG_SET(ShenandoahSATBBarrier); > 50 SHENANDOAH_CHECK_FLAG_SET(ShenandoahCASBarrier); > 51 SHENANDOAH_CHECK_FLAG_SET(ShenandoahCloneBarrier); Ok. I turned it into: SHENANDOAH_CHECK_FLAG_SET(ShenandoahSATBBarrier || ShenandoahStoreValEnqueueBarrier) which required the macro to do !(name) instead of !name. > *) This is some local madness: > > 84 int gc_state = _heap->gc_state(); > 85 if ((gc_state & ShenandoahHeap::MARKING) != 0 && > 86 ShenandoahStoreValEnqueueBarrier && > 87 !_heap->marking_context()->allocated_after_mark_start(obj)) { > 88 ShenandoahUpdateRefsForOopClosure cl; > 89 obj->oop_iterate(&cl); > 90 } else if ((gc_state & ShenandoahHeap::HAS_FORWARDED) != 0) { > 91 if (skip_bulk_update(cast_from_oop(obj))) return; This should be gone with JDK-8242130, plus in this revision I also made the clone_barrier() to dispatch in a very similar fashion. > *) I don't think the rewrite in ShFinalMarkTask is equivalent. See, on the path here: > > 262 ShenandoahSATBAndRemarkCodeRootsThreadsClosure tc(&cl, > 263 ShenandoahStoreValEnqueueBarrier ? &mark_cl : NULL, > 264 &blobsCl); > > ...we used to pass NULL as blobsCL when do_nmethods is false. Right. Good catch! > *) Also, why ResourceMark here? > > 199 if (_cl != NULL) { > 200 ResourceMark rm; > 201 thread->oops_do(_cl, _code_cl); Because Threads::oops_do() allocates some Resource stuff. It's everywhere where Thread::oops_do() is called. Should probably be looked-at separately? http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.02/ Better? Roman From shade at redhat.com Mon Apr 6 10:43:53 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 12:43:53 +0200 Subject: RFR: 8242130: Shenandoah: Simplify arraycopy-barrier dispatching In-Reply-To: References: Message-ID: <4f888d21-bd8f-7fe6-3fb9-ece388518910@redhat.com> On 4/3/20 9:13 PM, Roman Kennke wrote: > Issue: > https://bugs.openjdk.java.net/browse/JDK-8242130 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8242130/webrev.00/ *) Is it actually safe to ignore dest_uninitialized path? Would the new arraycopy_marking routine walk over uninitialized memory now? Otherwise looks fine. -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 11:01:02 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 13:01:02 +0200 Subject: RFR: 8242130: Shenandoah: Simplify arraycopy-barrier dispatching In-Reply-To: <4f888d21-bd8f-7fe6-3fb9-ece388518910@redhat.com> References: <4f888d21-bd8f-7fe6-3fb9-ece388518910@redhat.com> Message-ID: >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8242130 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8242130/webrev.00/ > > *) Is it actually safe to ignore dest_uninitialized path? Would the new arraycopy_marking routine > walk over uninitialized memory now? This is not about safety, it is about optimization: when the destination array is uninitialized, we don't need to mark the previous values, because they are known to be NULL. Also, when dest is uninitialized, then we don't include MARKING in the gc-state check above. Which means it would never trigger during marking, and only during evac, in which case we're looking at the src array only. Does that make sense? Roman From shade at redhat.com Mon Apr 6 11:09:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 13:09:50 +0200 Subject: RFR: 8242130: Shenandoah: Simplify arraycopy-barrier dispatching In-Reply-To: References: <4f888d21-bd8f-7fe6-3fb9-ece388518910@redhat.com> Message-ID: <6e868b80-2377-b10c-bd95-f9fd8b53e78a@redhat.com> On 4/6/20 1:01 PM, Roman Kennke wrote: >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8242130 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8242130/webrev.00/ >> >> *) Is it actually safe to ignore dest_uninitialized path? Would the new arraycopy_marking routine >> walk over uninitialized memory now? > > This is not about safety, it is about optimization: when the destination > array is uninitialized, we don't need to mark the previous values, > because they are known to be NULL. > > Also, when dest is uninitialized, then we don't include MARKING in the > gc-state check above. Which means it would never trigger during marking, > and only during evac, in which case we're looking at the src array only. > > Does that make sense? Ah, I see. Yes, it does make sense. Looks good then. Minor nit in shenandoahRuntime.hpp, "narrowOop * dst": 37 static void arraycopy_barrier_narrow_oop_entry(narrowOop* src, narrowOop * dst, size_t length); -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 11:49:29 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 13:49:29 +0200 Subject: RFR: 8242130: Shenandoah: Simplify arraycopy-barrier dispatching In-Reply-To: <6e868b80-2377-b10c-bd95-f9fd8b53e78a@redhat.com> References: <4f888d21-bd8f-7fe6-3fb9-ece388518910@redhat.com> <6e868b80-2377-b10c-bd95-f9fd8b53e78a@redhat.com> Message-ID: Hi Aleksey, >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8242130 >>>> Webrev: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8242130/webrev.00/ >>> >>> *) Is it actually safe to ignore dest_uninitialized path? Would the new arraycopy_marking routine >>> walk over uninitialized memory now? >> >> This is not about safety, it is about optimization: when the destination >> array is uninitialized, we don't need to mark the previous values, >> because they are known to be NULL. >> >> Also, when dest is uninitialized, then we don't include MARKING in the >> gc-state check above. Which means it would never trigger during marking, >> and only during evac, in which case we're looking at the src array only. >> >> Does that make sense? > > Ah, I see. Yes, it does make sense. > > Looks good then. > > Minor nit in shenandoahRuntime.hpp, "narrowOop * dst": > 37 static void arraycopy_barrier_narrow_oop_entry(narrowOop* src, narrowOop * dst, size_t length); Thanks! Pushed with this formatting fixed. Roman From rkennke at redhat.com Mon Apr 6 12:21:48 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 14:21:48 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> Message-ID: I made a mistake with webrev.02, it included the change for JDK-8242130. Please review this webrev instead: http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.03/ Thanks, Roman >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8242054 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.00/ > > I rebased this patch on top of "JDK-8242130: Shenandoah: Simplify > arraycopy-barrier dispatching" > > Now that we purged traversal-mode, I also added tests for IU mode, by > (mostly) mechanically adding back the tests that I removed with > Traversal mode, and change ShenandoahGCMode=traversal -> > ShenandoahGCMode=iu. > >> *) I would prefer for flag checks to be first. It makes it clearer to me that path is only taken in >> some configurations. Example, this: >> if (dest_uninitialized && ShenandoahSATBBarrier) ... >> ...becomes this: >> if (ShenandoahSATBBarrier && dest_uninitialized) ... > > Right. Fixed the occurances that I found (the mentioned one is gone with > JDK-8242130. > >> *) These blocks should not be removed. At very least we want to make the check for SATB/StoreVal >> barrier conditional on the mode. But other barrier checks should definitely stay. >> >> 47 // Final configuration checks >> 48 SHENANDOAH_CHECK_FLAG_SET(ShenandoahLoadRefBarrier); >> 49 SHENANDOAH_CHECK_FLAG_SET(ShenandoahSATBBarrier); >> 50 SHENANDOAH_CHECK_FLAG_SET(ShenandoahCASBarrier); >> 51 SHENANDOAH_CHECK_FLAG_SET(ShenandoahCloneBarrier); > > Ok. I turned it into: > SHENANDOAH_CHECK_FLAG_SET(ShenandoahSATBBarrier || > ShenandoahStoreValEnqueueBarrier) > > which required the macro to do !(name) instead of !name. > >> *) This is some local madness: >> >> 84 int gc_state = _heap->gc_state(); >> 85 if ((gc_state & ShenandoahHeap::MARKING) != 0 && >> 86 ShenandoahStoreValEnqueueBarrier && >> 87 !_heap->marking_context()->allocated_after_mark_start(obj)) { >> 88 ShenandoahUpdateRefsForOopClosure cl; >> 89 obj->oop_iterate(&cl); >> 90 } else if ((gc_state & ShenandoahHeap::HAS_FORWARDED) != 0) { >> 91 if (skip_bulk_update(cast_from_oop(obj))) return; > > This should be gone with JDK-8242130, plus in this revision I also made > the clone_barrier() to dispatch in a very similar fashion. > >> *) I don't think the rewrite in ShFinalMarkTask is equivalent. See, on the path here: >> >> 262 ShenandoahSATBAndRemarkCodeRootsThreadsClosure tc(&cl, >> 263 ShenandoahStoreValEnqueueBarrier ? &mark_cl : NULL, >> 264 &blobsCl); >> >> ...we used to pass NULL as blobsCL when do_nmethods is false. > > Right. Good catch! > >> *) Also, why ResourceMark here? >> >> 199 if (_cl != NULL) { >> 200 ResourceMark rm; >> 201 thread->oops_do(_cl, _code_cl); > > Because Threads::oops_do() allocates some Resource stuff. It's > everywhere where Thread::oops_do() is called. Should probably be > looked-at separately? > > > http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.02/ > > Better? > > Roman > From shade at redhat.com Mon Apr 6 12:28:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 14:28:51 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> Message-ID: <7c19afef-6d1a-f205-5bb6-3c935a9882b0@redhat.com> On 4/6/20 2:21 PM, Roman Kennke wrote: > I made a mistake with webrev.02, it included the change for JDK-8242130. > Please review this webrev instead: > > http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.03/ *) shenandoahBarrierSetAssembler_aarch64.cpp: flag check should be first? 62 if (dest_uninitialized && !ShenandoahStoreValEnqueueBarrier) { *) I wonder if there is a test that checks ShenandoahSATBBarrier and ShenandoahStoreValEnqueueBarrier are not enabled at the same time. If not, I can add it later. *) I wonder ShenandoahBarrierSet::clone_barrier should actually check for ShenandoahHeap::UPDATEREFS on L110, like ShenandoahBarrierSet::arraycopy_barrier started doing it recently? http://hg.openjdk.java.net/jdk/jdk/rev/0c8345a2ad50#l4.36 105 int gc_state = _heap->gc_state(); 106 if ((gc_state & ShenandoahHeap::MARKING) != 0) { 107 clone_marking(obj); 108 } else if ((gc_state & ShenandoahHeap::EVACUATION) != 0) { 109 clone_evacuation(obj); 110 } else { 111 clone_update(obj); 112 } *) In ShenandoahSATBAndRemarkCodeRootsThreadsClosure, double space in "else if" here: 202 } else if (_code_cl != NULL) { *) In TestObjItrWithHeapDump.java, the indent is wrong: 60 {{"normal"}, {"adaptive", "compact", "static", "aggressive"}}, 61 {{"iu"}, {"adaptive", "aggressive"}}, 62 {{"passive"}, {"passive"}} *) Same thing in TestClassLoaderLeak.java: 128 String[][][] modeHeuristics = new String[][][] { 129 {{"normal"}, {"adaptive", "compact", "static", "aggressive"}}, 130 {{"iu"}, {"adaptive", "aggressive"}}, 131 {{"passive"}, {"passive"}} 132 }; *) In TestWrongArrayMember.java, the indent is wrong: 30 * @run main/othervm -Xmx128m -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC TestWrongArrayMember 31 * @run main/othervm -Xmx128m -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=iu TestWrongArrayMember *) TestHeuristicsUnlock.java change actually raises a question: should this mode be experimental? 52 testWith("-XX:ShenandoahGCMode=iu", Mode.PRODUCT); Otherwise looks fine! -- Thanks, -Aleksey From shade at redhat.com Mon Apr 6 12:45:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 14:45:19 +0200 Subject: RFR (XS) 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8242211 This field is not needed anymore after Traversal removal, and it only wastes native memory and time spent working through region data. Fix: diff -r 4d759a99c277 src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Mon Apr 06 10:31:07 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Mon Apr 06 14:43:55 2020 +0200 @@ -43,24 +43,4 @@ } -int ShenandoahHeuristics::compare_by_garbage_then_alloc_seq_ascending(RegionData a, RegionData b) { - int r = compare_by_garbage(a, b); - if (r != 0) { - return r; - } - return compare_by_alloc_seq_ascending(a, b); -} - -int ShenandoahHeuristics::compare_by_alloc_seq_ascending(RegionData a, RegionData b) { - if (a._seqnum_last_alloc == b._seqnum_last_alloc) - return 0; - else if (a._seqnum_last_alloc < b._seqnum_last_alloc) - return -1; - else return 1; -} - -int ShenandoahHeuristics::compare_by_alloc_seq_descending(RegionData a, RegionData b) { - return -compare_by_alloc_seq_ascending(a, b); -} - ShenandoahHeuristics::ShenandoahHeuristics() : _region_data(NULL), diff -r 4d759a99c277 src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Mon Apr 06 10:31:07 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Mon Apr 06 14:43:55 2020 +0200 @@ -76,5 +76,4 @@ ShenandoahHeapRegion* _region; size_t _garbage; - uint64_t _seqnum_last_alloc; } RegionData; @@ -98,7 +97,4 @@ static int compare_by_garbage(RegionData a, RegionData b); - static int compare_by_garbage_then_alloc_seq_ascending(RegionData a, RegionData b); - static int compare_by_alloc_seq_ascending(RegionData a, RegionData b); - static int compare_by_alloc_seq_descending(RegionData a, RegionData b); RegionData* get_region_data_cache(size_t num); Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 12:52:07 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 14:52:07 +0200 Subject: RFR (XS) 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc In-Reply-To: References: Message-ID: Right. Do it! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242211 > > This field is not needed anymore after Traversal removal, and it only wastes native memory and time > spent working through region data. > > Fix: > > diff -r 4d759a99c277 src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Mon Apr 06 10:31:07 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Mon Apr 06 14:43:55 2020 +0200 > @@ -43,24 +43,4 @@ > } > > -int ShenandoahHeuristics::compare_by_garbage_then_alloc_seq_ascending(RegionData a, RegionData b) { > - int r = compare_by_garbage(a, b); > - if (r != 0) { > - return r; > - } > - return compare_by_alloc_seq_ascending(a, b); > -} > - > -int ShenandoahHeuristics::compare_by_alloc_seq_ascending(RegionData a, RegionData b) { > - if (a._seqnum_last_alloc == b._seqnum_last_alloc) > - return 0; > - else if (a._seqnum_last_alloc < b._seqnum_last_alloc) > - return -1; > - else return 1; > -} > - > -int ShenandoahHeuristics::compare_by_alloc_seq_descending(RegionData a, RegionData b) { > - return -compare_by_alloc_seq_ascending(a, b); > -} > - > ShenandoahHeuristics::ShenandoahHeuristics() : > _region_data(NULL), > diff -r 4d759a99c277 src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Mon Apr 06 10:31:07 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Mon Apr 06 14:43:55 2020 +0200 > @@ -76,5 +76,4 @@ > ShenandoahHeapRegion* _region; > size_t _garbage; > - uint64_t _seqnum_last_alloc; > } RegionData; > > @@ -98,7 +97,4 @@ > > static int compare_by_garbage(RegionData a, RegionData b); > - static int compare_by_garbage_then_alloc_seq_ascending(RegionData a, RegionData b); > - static int compare_by_alloc_seq_ascending(RegionData a, RegionData b); > - static int compare_by_alloc_seq_descending(RegionData a, RegionData b); > > RegionData* get_region_data_cache(size_t num); > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Mon Apr 6 12:56:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 14:56:04 +0200 Subject: RFR (S) 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly Message-ID: <3894a7cb-29c4-39f1-4ec3-d8460632dfd7@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242212 This is the leftover from the time Shenandoah heap sizing policy drove the dynamic number of regions. Now Shenandoah always have the same number of regions, so we can initialize _region_data eagerly and dodge the hiccup on the very first GC cycle. Fix: https://cr.openjdk.java.net/~shade/8242212/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 13:04:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 15:04:31 +0200 Subject: RFR (S) 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly In-Reply-To: <3894a7cb-29c4-39f1-4ec3-d8460632dfd7@redhat.com> References: <3894a7cb-29c4-39f1-4ec3-d8460632dfd7@redhat.com> Message-ID: Yes! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242212 > > This is the leftover from the time Shenandoah heap sizing policy drove the dynamic number of > regions. Now Shenandoah always have the same number of regions, so we can initialize _region_data > eagerly and dodge the hiccup on the very first GC cycle. > > Fix: > https://cr.openjdk.java.net/~shade/8242212/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Mon Apr 6 13:05:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 15:05:39 +0200 Subject: RFR (XS) 8242213: Shenandoah: remove unused ShenandoahHeuristics::_bytes_in_cset Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8242213 That field does not seem to be used for anything, yet we update it on critical path during cset selection. We should ditch the field and all "uses" of it. Cursory examination seems to indicate it was there since the initial integration. Fix: diff -r f30c66ecc928 src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp --- a/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp Mon Apr 06 14:46:40 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp Mon Apr 06 15:04:29 2020 +0200 @@ -78,3 +78,2 @@ size_t cur_garbage = 0; - _bytes_in_cset = 0; @@ -92,3 +91,2 @@ cset->add_region(r); - _bytes_in_cset += r->used(); cur_cset = new_cset; diff -r f30c66ecc928 src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Mon Apr 06 14:46:40 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Mon Apr 06 15:04:29 2020 +0200 @@ -48,3 +48,2 @@ _successful_cycles_in_a_row(0), - _bytes_in_cset(0), _cycle_start(os::elapsedTime()), @@ -260,3 +259,3 @@ void ShenandoahHeuristics::record_allocation_failure_gc() { - _bytes_in_cset = 0; + // Do nothing. } @@ -264,4 +263,2 @@ void ShenandoahHeuristics::record_requested_gc() { - _bytes_in_cset = 0; - // Assume users call System.gc() when external state changes significantly, diff -r f30c66ecc928 src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Mon Apr 06 14:46:40 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Mon Apr 06 15:04:29 2020 +0200 @@ -84,4 +84,2 @@ - size_t _bytes_in_cset; - double _cycle_start; Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 13:12:41 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 15:12:41 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: <7c19afef-6d1a-f205-5bb6-3c935a9882b0@redhat.com> References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> <7c19afef-6d1a-f205-5bb6-3c935a9882b0@redhat.com> Message-ID: <6a7b487f-62a8-1ed5-945b-109abc857d36@redhat.com> >> I made a mistake with webrev.02, it included the change for JDK-8242130. >> Please review this webrev instead: >> >> http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.03/ > > *) shenandoahBarrierSetAssembler_aarch64.cpp: flag check should be first? > > 62 if (dest_uninitialized && !ShenandoahStoreValEnqueueBarrier) { Yeah. In-fact, it is cleaner to check for ShenandoahSATBBarrier instead. > *) I wonder if there is a test that checks ShenandoahSATBBarrier and > ShenandoahStoreValEnqueueBarrier are not enabled at the same time. If not, I can add it later. I don't think we have this. > *) I wonder ShenandoahBarrierSet::clone_barrier should actually check for ShenandoahHeap::UPDATEREFS > on L110, like ShenandoahBarrierSet::arraycopy_barrier started doing it recently? > http://hg.openjdk.java.net/jdk/jdk/rev/0c8345a2ad50#l4.36 > > 105 int gc_state = _heap->gc_state(); > 106 if ((gc_state & ShenandoahHeap::MARKING) != 0) { > 107 clone_marking(obj); > 108 } else if ((gc_state & ShenandoahHeap::EVACUATION) != 0) { > 109 clone_evacuation(obj); > 110 } else { > 111 clone_update(obj); > 112 } I it is not necessary. All entries check that we only get there when we have HAS_FORWARDED set. We also assert that update-refs is in progress in clone_update(). In arraycopy it is slightly different because the entry that comes from runtime-arraycopy does not check HAS_FORWARDED. > *) In ShenandoahSATBAndRemarkCodeRootsThreadsClosure, double space in "else if" here: > 202 } else if (_code_cl != NULL) { Oops. Fixed. > *) In TestObjItrWithHeapDump.java, the indent is wrong: > 60 {{"normal"}, {"adaptive", "compact", "static", "aggressive"}}, > 61 {{"iu"}, {"adaptive", "aggressive"}}, > 62 {{"passive"}, {"passive"}} Fixed. > *) Same thing in TestClassLoaderLeak.java: > > 128 String[][][] modeHeuristics = new String[][][] { > 129 {{"normal"}, {"adaptive", "compact", "static", "aggressive"}}, > 130 {{"iu"}, {"adaptive", "aggressive"}}, > 131 {{"passive"}, {"passive"}} > 132 }; Fixed. > *) In TestWrongArrayMember.java, the indent is wrong: > > 30 * @run main/othervm -Xmx128m -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC > TestWrongArrayMember > 31 * @run main/othervm -Xmx128m -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC > -XX:ShenandoahGCMode=iu TestWrongArrayMember Fixed. > *) TestHeuristicsUnlock.java change actually raises a question: should this mode be experimental? > 52 testWith("-XX:ShenandoahGCMode=iu", Mode.PRODUCT); I am not sure. On one side we now have all the tests that we considered sufficient for traversal in place. Should we make it experimental, run it for a while in our CIs (which also needs changing from traversal -> iu), and then declare it product soon-ish? What do you think? Above fixes, still product-flag: http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.04/ Roman From shade at redhat.com Mon Apr 6 13:25:47 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 15:25:47 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: <6a7b487f-62a8-1ed5-945b-109abc857d36@redhat.com> References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> <7c19afef-6d1a-f205-5bb6-3c935a9882b0@redhat.com> <6a7b487f-62a8-1ed5-945b-109abc857d36@redhat.com> Message-ID: <63a5c745-52e7-29bb-f96a-e5cb13d75e13@redhat.com> On 4/6/20 3:12 PM, Roman Kennke wrote: >> >> *) shenandoahBarrierSetAssembler_aarch64.cpp: flag check should be first? >> >> 62 if (dest_uninitialized && !ShenandoahStoreValEnqueueBarrier) { > > Yeah. In-fact, it is cleaner to check for ShenandoahSATBBarrier instead. Eh. shenandoahBarrierSetAssembler_x86.cpp should do the same for consistency? I understand it would require both branches initializing "flags". >> *) TestHeuristicsUnlock.java change actually raises a question: should this mode be experimental? >> 52 testWith("-XX:ShenandoahGCMode=iu", Mode.PRODUCT); > > I am not sure. On one side we now have all the tests that we considered > sufficient for traversal in place. Should we make it experimental, run > it for a while in our CIs (which also needs changing from traversal -> > iu), and then declare it product soon-ish? What do you think? Yeah, I think it should be experimental for a while. We would say it is product-ready explicitly. -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 14:08:15 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 16:08:15 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: <63a5c745-52e7-29bb-f96a-e5cb13d75e13@redhat.com> References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> <7c19afef-6d1a-f205-5bb6-3c935a9882b0@redhat.com> <6a7b487f-62a8-1ed5-945b-109abc857d36@redhat.com> <63a5c745-52e7-29bb-f96a-e5cb13d75e13@redhat.com> Message-ID: <760b5cf2-c1c0-7253-64b5-316ef0f82f06@redhat.com> >>> *) shenandoahBarrierSetAssembler_aarch64.cpp: flag check should be first? >>> >>> 62 if (dest_uninitialized && !ShenandoahStoreValEnqueueBarrier) { >> >> Yeah. In-fact, it is cleaner to check for ShenandoahSATBBarrier instead. > > Eh. shenandoahBarrierSetAssembler_x86.cpp should do the same for consistency? I understand it would > require both branches initializing "flags". Ok, done. >>> *) TestHeuristicsUnlock.java change actually raises a question: should this mode be experimental? >>> 52 testWith("-XX:ShenandoahGCMode=iu", Mode.PRODUCT); >> >> I am not sure. On one side we now have all the tests that we considered >> sufficient for traversal in place. Should we make it experimental, run >> it for a while in our CIs (which also needs changing from traversal -> >> iu), and then declare it product soon-ish? What do you think? > > Yeah, I think it should be experimental for a while. We would say it is product-ready explicitly. Ok. I introduced some machinery to make GC mode diagnostic or experimental, and also report its name. This mirrors what we do for heuristics: Differential: http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05.diff/ Full: http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05/ Ok now? Roman From shade at redhat.com Mon Apr 6 14:12:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 16:12:01 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: <760b5cf2-c1c0-7253-64b5-316ef0f82f06@redhat.com> References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> <7c19afef-6d1a-f205-5bb6-3c935a9882b0@redhat.com> <6a7b487f-62a8-1ed5-945b-109abc857d36@redhat.com> <63a5c745-52e7-29bb-f96a-e5cb13d75e13@redhat.com> <760b5cf2-c1c0-7253-64b5-316ef0f82f06@redhat.com> Message-ID: <67002e53-16a3-e4ba-776e-f8af6e853e42@redhat.com> On 4/6/20 4:08 PM, Roman Kennke wrote: > Differential: > http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05/ I would probably do the diagnostic/experimental mode change separately, but that is your call. Looks fine. -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 14:26:48 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 16:26:48 +0200 Subject: RFR: 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name Message-ID: <5bd2c6bd-442f-cf6b-4866-0a98f1085643@redhat.com> Currently, only heuristics can be flagged experimental or diagnostic, or even have their name reported on -Xlog:gc+init. GC modes should have those properties too. Issue: https://bugs.openjdk.java.net/browse/JDK-8242217 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8242217/webrev.00/ Testing: hotspot_gc_shenandoah Good? Roman From shade at redhat.com Mon Apr 6 14:31:45 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 16:31:45 +0200 Subject: RFR: 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name In-Reply-To: <5bd2c6bd-442f-cf6b-4866-0a98f1085643@redhat.com> References: <5bd2c6bd-442f-cf6b-4866-0a98f1085643@redhat.com> Message-ID: <1d324108-057d-fb92-bd4e-008c7bf2f4d6@redhat.com> On 4/6/20 4:26 PM, Roman Kennke wrote: > Issue: > https://bugs.openjdk.java.net/browse/JDK-8242217 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8242217/webrev.00/ Looks good, thanks. -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 14:45:02 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 16:45:02 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: <67002e53-16a3-e4ba-776e-f8af6e853e42@redhat.com> References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> <7c19afef-6d1a-f205-5bb6-3c935a9882b0@redhat.com> <6a7b487f-62a8-1ed5-945b-109abc857d36@redhat.com> <63a5c745-52e7-29bb-f96a-e5cb13d75e13@redhat.com> <760b5cf2-c1c0-7253-64b5-316ef0f82f06@redhat.com> <67002e53-16a3-e4ba-776e-f8af6e853e42@redhat.com> Message-ID: <08f23e82-fa23-507a-68c7-ee01b103cc91@redhat.com> >> Differential: >> http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05.diff/ >> Full: >> http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05/ > > I would probably do the diagnostic/experimental mode change separately, but that is your call. Alright, re-based on top of "8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name": http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.06/ Good now? Roman From shade at redhat.com Mon Apr 6 14:48:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 16:48:03 +0200 Subject: RFR: 8242054: Shenandoah: New incremental-update mode In-Reply-To: <08f23e82-fa23-507a-68c7-ee01b103cc91@redhat.com> References: <83cac288-4831-4731-b39e-41eaee210a8b@redhat.com> <25192585-457e-4769-183c-fb635d029348@redhat.com> <7c19afef-6d1a-f205-5bb6-3c935a9882b0@redhat.com> <6a7b487f-62a8-1ed5-945b-109abc857d36@redhat.com> <63a5c745-52e7-29bb-f96a-e5cb13d75e13@redhat.com> <760b5cf2-c1c0-7253-64b5-316ef0f82f06@redhat.com> <67002e53-16a3-e4ba-776e-f8af6e853e42@redhat.com> <08f23e82-fa23-507a-68c7-ee01b103cc91@redhat.com> Message-ID: On 4/6/20 4:45 PM, Roman Kennke wrote: >>> Differential: >>> http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05.diff/ >>> Full: >>> http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.05/ >> >> I would probably do the diagnostic/experimental mode change separately, but that is your call. > > Alright, re-based on top of "8242217: Shenandoah: Enable GC mode to be > diagnostic/experimental and have a name": > > http://cr.openjdk.java.net/~rkennke/JDK-8242054/webrev.06/ Yes, thank you. -- -Aleksey From shade at redhat.com Mon Apr 6 16:43:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 18:43:31 +0200 Subject: RFR (S) 8242227: Shenandoah: transit regions to cset state when adding to collection set Message-ID: <14b91faf-772c-aa42-5acc-bae405d04db2@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242227 Current code has awkward ShenandoahCollectionSet method that is called after cset selection. It walks the regions again and transits the regions to cset status. At this point, we can just do this during SHCSet::add_region() and save a walk. Webrev: https://cr.openjdk.java.net/~shade/8242227/webrev.01/ Testing: hotspot_gc_shenandoah, benchmarks -- Thanks, -Aleksey From shade at redhat.com Mon Apr 6 16:44:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 18:44:35 +0200 Subject: RFR (XS) 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8242228 Fix: diff -r 5461ecb40ab4 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp Mon Apr 06 18:39:02 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp Mon Apr 06 18:44:12 2020 +0200 @@ -94,21 +94,4 @@ } -bool ShenandoahCollectionSet::add_region_check_for_duplicates(ShenandoahHeapRegion* r) { - if (!is_in(r)) { - add_region(r); - return true; - } else { - return false; - } -} - -void ShenandoahCollectionSet::remove_region(ShenandoahHeapRegion* r) { - assert(ShenandoahSafepoint::is_at_shenandoah_safepoint(), "Must be at a safepoint"); - assert(Thread::current()->is_VM_thread(), "Must be VMThread"); - assert(is_in(r), "Not in collection set"); - _cset_map[r->index()] = 0; - _region_count --; -} - void ShenandoahCollectionSet::clear() { assert(ShenandoahSafepoint::is_at_shenandoah_safepoint(), "Must be at a safepoint"); diff -r 5461ecb40ab4 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Mon Apr 06 18:39:02 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Mon Apr 06 18:44:12 2020 +0200 @@ -57,8 +57,4 @@ // Add region to collection set void add_region(ShenandoahHeapRegion* r); - bool add_region_check_for_duplicates(ShenandoahHeapRegion* r); - - // Remove region from collection set - void remove_region(ShenandoahHeapRegion* r); // MT version Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Mon Apr 6 16:56:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 6 Apr 2020 18:56:12 +0200 Subject: RFR (S) 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods Message-ID: <78603db2-1ba3-0a54-b80a-b8af09a40e07@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242229 Webrev: https://cr.openjdk.java.net/~shade/8242229/webrev.01/ These methods are used on critical paths during choosing the collection set, and should be inlined. While shenandoahHeapRegion.inline.hpp is transitively included by shenandoahHeap.inline.hpp, which pretty much every other compilation unit includes, I still opted to include it directly in the affected compilation units. Testing: hotspot_gc_shenadoah, benchmarks, eyeballing disassemblies, non-PCH {slowdebug, fastdebug,release} builds -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 6 17:53:17 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 19:53:17 +0200 Subject: RFR (XS) 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods In-Reply-To: References: Message-ID: <76461341-a172-c824-e87e-f907bea0c163@redhat.com> Yes, good! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242228 > > Fix: > > diff -r 5461ecb40ab4 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp Mon Apr 06 18:39:02 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp Mon Apr 06 18:44:12 2020 +0200 > @@ -94,21 +94,4 @@ > } > > -bool ShenandoahCollectionSet::add_region_check_for_duplicates(ShenandoahHeapRegion* r) { > - if (!is_in(r)) { > - add_region(r); > - return true; > - } else { > - return false; > - } > -} > - > -void ShenandoahCollectionSet::remove_region(ShenandoahHeapRegion* r) { > - assert(ShenandoahSafepoint::is_at_shenandoah_safepoint(), "Must be at a safepoint"); > - assert(Thread::current()->is_VM_thread(), "Must be VMThread"); > - assert(is_in(r), "Not in collection set"); > - _cset_map[r->index()] = 0; > - _region_count --; > -} > - > void ShenandoahCollectionSet::clear() { > assert(ShenandoahSafepoint::is_at_shenandoah_safepoint(), "Must be at a safepoint"); > diff -r 5461ecb40ab4 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Mon Apr 06 18:39:02 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Mon Apr 06 18:44:12 2020 +0200 > @@ -57,8 +57,4 @@ > // Add region to collection set > void add_region(ShenandoahHeapRegion* r); > - bool add_region_check_for_duplicates(ShenandoahHeapRegion* r); > - > - // Remove region from collection set > - void remove_region(ShenandoahHeapRegion* r); > > // MT version > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Mon Apr 6 17:54:18 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 19:54:18 +0200 Subject: RFR (S) 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods In-Reply-To: <78603db2-1ba3-0a54-b80a-b8af09a40e07@redhat.com> References: <78603db2-1ba3-0a54-b80a-b8af09a40e07@redhat.com> Message-ID: <86127095-2136-9237-07fc-06c1006ad212@redhat.com> Ok. Yes, explicit includes is always preferred if it's used in the compilation unit. Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242229 > > Webrev: > https://cr.openjdk.java.net/~shade/8242229/webrev.01/ > > These methods are used on critical paths during choosing the collection set, and should be inlined. > > While shenandoahHeapRegion.inline.hpp is transitively included by shenandoahHeap.inline.hpp, which > pretty much every other compilation unit includes, I still opted to include it directly in the > affected compilation units. > > Testing: hotspot_gc_shenadoah, benchmarks, eyeballing disassemblies, non-PCH {slowdebug, > fastdebug,release} builds > From rkennke at redhat.com Mon Apr 6 17:52:55 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 19:52:55 +0200 Subject: RFR (S) 8242227: Shenandoah: transit regions to cset state when adding to collection set In-Reply-To: <14b91faf-772c-aa42-5acc-bae405d04db2@redhat.com> References: <14b91faf-772c-aa42-5acc-bae405d04db2@redhat.com> Message-ID: <723cf481-7ca7-8a79-63e9-bb3ffaa0e1ac@redhat.com> Yes, looks good! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242227 > > Current code has awkward ShenandoahCollectionSet method that is called after cset selection. It > walks the regions again and transits the regions to cset status. At this point, we can just do this > during SHCSet::add_region() and save a walk. > > Webrev: > https://cr.openjdk.java.net/~shade/8242227/webrev.01/ > > Testing: hotspot_gc_shenandoah, benchmarks > From rkennke at redhat.com Mon Apr 6 18:28:21 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 6 Apr 2020 20:28:21 +0200 Subject: RFR (XS) 8242213: Shenandoah: remove unused ShenandoahHeuristics::_bytes_in_cset In-Reply-To: References: Message-ID: Ok, let it go! :-) Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242213 > > That field does not seem to be used for anything, yet we update it on critical path during cset > selection. We should ditch the field and all "uses" of it. Cursory examination seems to indicate it > was there since the initial integration. > > Fix: > > diff -r f30c66ecc928 src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp > --- a/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp Mon Apr 06 > 14:46:40 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp Mon Apr 06 > 15:04:29 2020 +0200 > @@ -78,3 +78,2 @@ > size_t cur_garbage = 0; > - _bytes_in_cset = 0; > > @@ -92,3 +91,2 @@ > cset->add_region(r); > - _bytes_in_cset += r->used(); > cur_cset = new_cset; > diff -r f30c66ecc928 src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Mon Apr 06 14:46:40 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Mon Apr 06 15:04:29 2020 +0200 > @@ -48,3 +48,2 @@ > _successful_cycles_in_a_row(0), > - _bytes_in_cset(0), > _cycle_start(os::elapsedTime()), > @@ -260,3 +259,3 @@ > void ShenandoahHeuristics::record_allocation_failure_gc() { > - _bytes_in_cset = 0; > + // Do nothing. > } > @@ -264,4 +263,2 @@ > void ShenandoahHeuristics::record_requested_gc() { > - _bytes_in_cset = 0; > - > // Assume users call System.gc() when external state changes significantly, > diff -r f30c66ecc928 src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Mon Apr 06 14:46:40 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp Mon Apr 06 15:04:29 2020 +0200 > @@ -84,4 +84,2 @@ > > - size_t _bytes_in_cset; > - > double _cycle_start; > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Tue Apr 7 10:07:36 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Apr 2020 12:07:36 +0200 Subject: RFR (S) 8242271: Shenandoah: add test to verify GC mode unlock Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8242271 Webrev: https://cr.openjdk.java.net/~shade/8242271/webrev.01/ Pretty much a copy of gc/shenandoah/options/TestHeuristicsUnlock.java. Testing: new test in fastdebug/release modes -- Thanks, -Aleksey From shade at redhat.com Tue Apr 7 10:14:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Apr 2020 12:14:37 +0200 Subject: RFR (S) 8242273: Shenandoah: accept either SATB or IU barriers, but not both Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8242273 The follow-up for JDK-8242054, we need to make sure users cannot enable both SATB and IU barriers together. Currently Shenandoah blindly accepts +ShenandoahSATBBarrier +ShenandoahStoreValEnqueueBarrier, which might lead to surprising behaviors. Since "mode" is what defines the barriers, I moved all relevant barrier checking code there. Fix: https://cr.openjdk.java.net/~shade/8242273/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 7 10:36:34 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Apr 2020 12:36:34 +0200 Subject: RFR (S) 8242271: Shenandoah: add test to verify GC mode unlock In-Reply-To: References: Message-ID: <8b5de66b-3ab4-924e-7c39-e54d13c21909@redhat.com> Yup. Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242271 > > Webrev: > https://cr.openjdk.java.net/~shade/8242271/webrev.01/ > > Pretty much a copy of gc/shenandoah/options/TestHeuristicsUnlock.java. > > Testing: new test in fastdebug/release modes > From rkennke at redhat.com Tue Apr 7 10:38:56 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Apr 2020 12:38:56 +0200 Subject: RFR (S) 8242273: Shenandoah: accept either SATB or IU barriers, but not both In-Reply-To: References: Message-ID: <999d40db-9f3d-303d-ca23-d2dedeca9b50@redhat.com> Yes, looks good! Thanks, Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8242273 > > The follow-up for JDK-8242054, we need to make sure users cannot enable both SATB and IU barriers > together. Currently Shenandoah blindly accepts +ShenandoahSATBBarrier > +ShenandoahStoreValEnqueueBarrier, which might lead to surprising behaviors. > > Since "mode" is what defines the barriers, I moved all relevant barrier checking code there. > > Fix: > https://cr.openjdk.java.net/~shade/8242273/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Tue Apr 7 10:44:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Apr 2020 12:44:50 +0200 Subject: RFR (XS) 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8242267 SAP folks report their Windows CI fails Shenandoah tests. I believe this is the fix: diff -r 3f8d03880bf5 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 07 03:25:11 2020 +0000 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 07 11:48:56 2020 +0200 @@ -284,4 +284,5 @@ size_t region_align = align_up(sizeof(ShenandoahHeapRegion), SHENANDOAH_CACHE_LINE_SIZE); size_t region_storage_size = align_up(region_align * _num_regions, region_page_size); + region_storage_size = align_up(region_storage_size, os::vm_allocation_granularity()); ReservedSpace region_storage(region_storage_size, region_page_size); Testing: Linux x86_64 hotspot_gc_shenandoah + asked SAP folks to confirm -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 7 12:32:08 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Apr 2020 14:32:08 +0200 Subject: RFR (XS) 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() In-Reply-To: References: Message-ID: <902018b4-3c42-daec-0f47-e34cf772e710@redhat.com> Looks good. Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8242267 > > SAP folks report their Windows CI fails Shenandoah tests. > > I believe this is the fix: > > diff -r 3f8d03880bf5 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 07 03:25:11 2020 +0000 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 07 11:48:56 2020 +0200 > @@ -284,4 +284,5 @@ > size_t region_align = align_up(sizeof(ShenandoahHeapRegion), SHENANDOAH_CACHE_LINE_SIZE); > size_t region_storage_size = align_up(region_align * _num_regions, region_page_size); > + region_storage_size = align_up(region_storage_size, os::vm_allocation_granularity()); > > ReservedSpace region_storage(region_storage_size, region_page_size); > > Testing: Linux x86_64 hotspot_gc_shenandoah + asked SAP folks to confirm > From zgu at redhat.com Tue Apr 7 12:33:06 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 7 Apr 2020 08:33:06 -0400 Subject: RFR (XS) 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() In-Reply-To: References: Message-ID: Looks good to me. -Zhengyu On 4/7/20 6:44 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8242267 > > SAP folks report their Windows CI fails Shenandoah tests. > > I believe this is the fix: > > diff -r 3f8d03880bf5 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 07 03:25:11 2020 +0000 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 07 11:48:56 2020 +0200 > @@ -284,4 +284,5 @@ > size_t region_align = align_up(sizeof(ShenandoahHeapRegion), SHENANDOAH_CACHE_LINE_SIZE); > size_t region_storage_size = align_up(region_align * _num_regions, region_page_size); > + region_storage_size = align_up(region_storage_size, os::vm_allocation_granularity()); > > ReservedSpace region_storage(region_storage_size, region_page_size); > > Testing: Linux x86_64 hotspot_gc_shenandoah + asked SAP folks to confirm > From zgu at redhat.com Tue Apr 7 18:21:07 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 7 Apr 2020 14:21:07 -0400 Subject: [15] RFR 8241984: Shenandoah: enhance GCTimer and JFR support Message-ID: <3427c356-5a00-a3b4-606f-34ef6ec9d4b8@redhat.com> There are a few enhancement to GC timer tracing and JFR support: 1) Setup for concurrent phase 2) Report sub phases to JFR 3) Report reference processing to JFR. Bug: https://bugs.openjdk.java.net/browse/JDK-8241984 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8241984/webrev.00/ Test: hotspot_gc_shenandoah Eyeball GC events in JMC Thanks, -Zhengyu From rkennke at redhat.com Tue Apr 7 20:06:20 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Apr 2020 22:06:20 +0200 Subject: RFR: 8242301: Shenandoah: Inline LRB runtime call Message-ID: Currently, the LRB slow-path call does 2-3 calls in a row: compiled code -> runtime entry runtime entry -> ShBS::load_reference_barrier_mutator() ShBS::lrb_mutator() -> ShBS::lrb_mutator_work() The first in unavoidable, but none of the other two are marked inlined and are in a separate compilation-unit. Further, the middle-call is not needed. We can call straight from ShRuntime into the templated-inlined lrb_mutator() method. Issue: https://bugs.openjdk.java.net/browse/JDK-8242301 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8242301/webrev.00/ Testing: hotspot_gc_shenandoah (fastdebug/release) Ok? Roman From zgu at redhat.com Tue Apr 7 20:12:39 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 7 Apr 2020 16:12:39 -0400 Subject: RFR: 8242301: Shenandoah: Inline LRB runtime call In-Reply-To: References: Message-ID: Looks good. -Zhengyu On 4/7/20 4:06 PM, Roman Kennke wrote: > Currently, the LRB slow-path call does 2-3 calls in a row: > compiled code -> runtime entry > runtime entry -> ShBS::load_reference_barrier_mutator() > ShBS::lrb_mutator() -> ShBS::lrb_mutator_work() > > The first in unavoidable, but none of the other two are marked inlined > and are in a separate compilation-unit. Further, the middle-call is not > needed. We can call straight from ShRuntime into the templated-inlined > lrb_mutator() method. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8242301 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8242301/webrev.00/ > > Testing: hotspot_gc_shenandoah (fastdebug/release) > > Ok? > > Roman > From rkennke at redhat.com Tue Apr 7 20:30:27 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Apr 2020 22:30:27 +0200 Subject: [15] RFR 8241984: Shenandoah: enhance GCTimer and JFR support In-Reply-To: <3427c356-5a00-a3b4-606f-34ef6ec9d4b8@redhat.com> References: <3427c356-5a00-a3b4-606f-34ef6ec9d4b8@redhat.com> Message-ID: <9f31d576-29c4-cc7b-fe3e-c37cd79ac79d@redhat.com> Looks good to me! Thank you! Roman > There are a few enhancement to GC timer tracing and JFR support: > > 1) Setup for concurrent phase > 2) Report sub phases to JFR > 3) Report reference processing to JFR. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241984 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8241984/webrev.00/ > > Test: > ? hotspot_gc_shenandoah > ? Eyeball GC events in JMC > > Thanks, > > -Zhengyu > From rkennke at redhat.com Tue Apr 7 20:41:59 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 7 Apr 2020 22:41:59 +0200 Subject: RFR: 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry Message-ID: In ShenandoahRuntime, we do an explicit NULL-check with return, that has otherwise only an assert(false). We can turn that into a simple assert. We might have left the check there as a safety-net, but it never triggered anywhere. Also, we better make sure we never send NULL to the SATB-slowpath to begin with. Issue: https://bugs.openjdk.java.net/browse/JDK-8242316 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8242316/webrev.00/ Testing: hotspot_gc_shenandoah Ok? Roman From zgu at redhat.com Tue Apr 7 20:44:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 7 Apr 2020 16:44:28 -0400 Subject: RFR: 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry In-Reply-To: References: Message-ID: <8bf05078-c6a6-3352-4028-e55d252701ae@redhat.com> Sure. -Zhengyu On 4/7/20 4:41 PM, Roman Kennke wrote: > In ShenandoahRuntime, we do an explicit NULL-check with return, that has > otherwise only an assert(false). We can turn that into a simple assert. > > We might have left the check there as a safety-net, but it never > triggered anywhere. Also, we better make sure we never send NULL to the > SATB-slowpath to begin with. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8242316 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8242316/webrev.00/ > > Testing: hotspot_gc_shenandoah > > Ok? > > Roman > From shade at redhat.com Wed Apr 8 06:36:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Apr 2020 08:36:41 +0200 Subject: RFR: 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry In-Reply-To: References: Message-ID: <0bf5de7b-80aa-d123-a25c-c50c413b510c@redhat.com> On 4/7/20 10:41 PM, Roman Kennke wrote: > In ShenandoahRuntime, we do an explicit NULL-check with return, that has > otherwise only an assert(false). We can turn that into a simple assert. > > We might have left the check there as a safety-net, but it never > triggered anywhere. Also, we better make sure we never send NULL to the > SATB-slowpath to begin with. This check copies what G1 does in its own slowpath. That said, I cannot see where Shenandoah code is called with NULL obj. > Issue: > https://bugs.openjdk.java.net/browse/JDK-8242316 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8242316/webrev.00/ Looks good. I think you can even drop the assert wholesale, because the subsequent shenandoah_assert_correct implicitly checks for NULL by doing heap->is_in(...). The only reason to keep the assert is to get the "should be optimized out" message. -- Thanks, -Aleksey From shade at redhat.com Wed Apr 8 07:00:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Apr 2020 09:00:51 +0200 Subject: RFR: 8242301: Shenandoah: Inline LRB runtime call In-Reply-To: References: Message-ID: <6fcb381d-ff19-32fa-84d0-f6170a6e0a89@redhat.com> On 4/7/20 10:06 PM, Roman Kennke wrote: > Issue: > https://bugs.openjdk.java.net/browse/JDK-8242301 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8242301/webrev.00/ I remember some compilation problems with inferring the template type when called from ShenandoahRuntime. But, I cannot reproduce them with this patch, in either release/fastdebug/slowdebug. So, looks good! -- Thanks, -Aleksey From shade at redhat.com Wed Apr 8 09:53:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Apr 2020 11:53:31 +0200 Subject: RFR (S) 8242353: Shenandoah: micro-optimize region liveness handling Message-ID: <4a7d0333-f550-1f82-9b17-7fea0fcb8e39@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242353 Webrev: https://cr.openjdk.java.net/~shade/8242353/webrev.01/ There are two micro-optimizations in liveness handling: - No need to acquire the region eagerly in SH::flush_liveness_cache - No need to bypass liveness cache for bulk object separately, we can just use the usual overflow path This makes a small but visible dent in marking times. Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 8 10:04:20 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 8 Apr 2020 12:04:20 +0200 Subject: RFR (S) 8242353: Shenandoah: micro-optimize region liveness handling In-Reply-To: <4a7d0333-f550-1f82-9b17-7fea0fcb8e39@redhat.com> References: <4a7d0333-f550-1f82-9b17-7fea0fcb8e39@redhat.com> Message-ID: Ok. Nice! Patch looks good! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242353 > > Webrev: > https://cr.openjdk.java.net/~shade/8242353/webrev.01/ > > There are two micro-optimizations in liveness handling: > - No need to acquire the region eagerly in SH::flush_liveness_cache > - No need to bypass liveness cache for bulk object separately, we can just use the usual overflow path > > This makes a small but visible dent in marking times. > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Wed Apr 8 11:32:32 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Apr 2020 13:32:32 +0200 Subject: RFR (S) 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache Message-ID: <575bb8fe-3cbb-53d5-0fc3-fd0e8c72609e@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242365 I was actually looking into this weird statement: size_t max = (1 << (sizeof(jushort) * 8)) - 1; ...which is borderline UB, because we can shift for more than datatype width. Then I figured we might as well replace jushort with uint16_t. Webrev: https://cr.openjdk.java.net/~shade/8242365/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 8 11:37:37 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 8 Apr 2020 13:37:37 +0200 Subject: RFR (S) 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache In-Reply-To: <575bb8fe-3cbb-53d5-0fc3-fd0e8c72609e@redhat.com> References: <575bb8fe-3cbb-53d5-0fc3-fd0e8c72609e@redhat.com> Message-ID: Looks good. Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242365 > > I was actually looking into this weird statement: > size_t max = (1 << (sizeof(jushort) * 8)) - 1; > > ...which is borderline UB, because we can shift for more than datatype width. Then I figured we > might as well replace jushort with uint16_t. > > Webrev: > https://cr.openjdk.java.net/~shade/8242365/webrev.01/ > > Testing: hotspot_gc_shenandoah > From zgu at redhat.com Wed Apr 8 12:46:40 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 8 Apr 2020 08:46:40 -0400 Subject: [15] RFR(T) 8242370: Enable JFR TestGCPhaseConcurrent test for Shenandoah Message-ID: <26dac841-3458-9752-bcbb-0c05cef56d17@redhat.com> JDK-8241984 fixed top level concurrent event in Shenandoah, let's enable this test to ensure no regression in the future. Bug: https://bugs.openjdk.java.net/browse/JDK-8242370 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242370/webrev.00/ Test: TestGCPhaseConcurrent.java test on Linux x86_64 Thanks, -Zhengyu From zgu at redhat.com Wed Apr 8 13:55:00 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 8 Apr 2020 09:55:00 -0400 Subject: [15] RFR(T) 8242370: Enable JFR TestGCPhaseConcurrent test for Shenandoah In-Reply-To: References: <26dac841-3458-9752-bcbb-0c05cef56d17@redhat.com> Message-ID: <5f279a05-3f9e-26f7-42d7-c28070335197@redhat.com> Hi Stefan, Thanks for pointing out. I am taking your patch. Okay to push? -Zhengyu On 4/8/20 9:25 AM, Stefan Karlsson wrote: > Hi Zhengyu, > > Unfortunately, this patch breaks the dispatching of the tests if the > user specifies the the GC to test. > > For example: > makec ../build/fastdebug test > TEST=test/jdk/jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java > JTREG="JAVA_OPTIONS=-XX:+UseZGC" > > Will try to run the Shenandoah run line with both -XX:+UseZGC and > -XX:+UseShenandoahGC. > > You need to split this up into separate run like this: > https://cr.openjdk.java.net/~stefank/8242370/webrev.01/ > > Thanks, > StefanK > > On 2020-04-08 14:46, Zhengyu Gu wrote: >> JDK-8241984 fixed top level concurrent event in Shenandoah, let's >> enable this test to ensure no regression in the future. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242370 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242370/webrev.00/ >> >> Test: >> ?? TestGCPhaseConcurrent.java test on Linux x86_64 >> >> >> Thanks, >> >> -Zhengyu >> > From stefan.karlsson at oracle.com Wed Apr 8 13:25:44 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 8 Apr 2020 15:25:44 +0200 Subject: [15] RFR(T) 8242370: Enable JFR TestGCPhaseConcurrent test for Shenandoah In-Reply-To: <26dac841-3458-9752-bcbb-0c05cef56d17@redhat.com> References: <26dac841-3458-9752-bcbb-0c05cef56d17@redhat.com> Message-ID: Hi Zhengyu, Unfortunately, this patch breaks the dispatching of the tests if the user specifies the the GC to test. For example: makec ../build/fastdebug test TEST=test/jdk/jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java JTREG="JAVA_OPTIONS=-XX:+UseZGC" Will try to run the Shenandoah run line with both -XX:+UseZGC and -XX:+UseShenandoahGC. You need to split this up into separate run like this: https://cr.openjdk.java.net/~stefank/8242370/webrev.01/ Thanks, StefanK On 2020-04-08 14:46, Zhengyu Gu wrote: > JDK-8241984 fixed top level concurrent event in Shenandoah, let's enable > this test to ensure no regression in the future. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242370 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242370/webrev.00/ > > Test: > ? TestGCPhaseConcurrent.java test on Linux x86_64 > > > Thanks, > > -Zhengyu > From stefan.karlsson at oracle.com Wed Apr 8 13:56:08 2020 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 8 Apr 2020 15:56:08 +0200 Subject: [15] RFR(T) 8242370: Enable JFR TestGCPhaseConcurrent test for Shenandoah In-Reply-To: <5f279a05-3f9e-26f7-42d7-c28070335197@redhat.com> References: <26dac841-3458-9752-bcbb-0c05cef56d17@redhat.com> <5f279a05-3f9e-26f7-42d7-c28070335197@redhat.com> Message-ID: <8bd98659-7272-e0fb-7b96-8cd2facdc186@oracle.com> On 2020-04-08 15:55, Zhengyu Gu wrote: > Hi Stefan, > > Thanks for pointing out. I am taking your patch. > > Okay to push? Yes. Thanks, StefanK > > -Zhengyu > > On 4/8/20 9:25 AM, Stefan Karlsson wrote: >> Hi Zhengyu, >> >> Unfortunately, this patch breaks the dispatching of the tests if the >> user specifies the the GC to test. >> >> For example: >> makec ../build/fastdebug test >> TEST=test/jdk/jdk/jfr/event/gc/detailed/TestGCPhaseConcurrent.java >> JTREG="JAVA_OPTIONS=-XX:+UseZGC" >> >> Will try to run the Shenandoah run line with both -XX:+UseZGC and >> -XX:+UseShenandoahGC. >> >> You need to split this up into separate run like this: >> https://cr.openjdk.java.net/~stefank/8242370/webrev.01/ >> >> Thanks, >> StefanK >> >> On 2020-04-08 14:46, Zhengyu Gu wrote: >>> JDK-8241984 fixed top level concurrent event in Shenandoah, let's >>> enable this test to ensure no regression in the future. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242370 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242370/webrev.00/ >>> >>> Test: >>> ?? TestGCPhaseConcurrent.java test on Linux x86_64 >>> >>> >>> Thanks, >>> >>> -Zhengyu >>> >> > From zgu at redhat.com Wed Apr 8 14:32:45 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 8 Apr 2020 10:32:45 -0400 Subject: [15] RFR 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods Message-ID: <256ecae7-92d5-b32b-3d34-bd34a513fff2@redhat.com> Please review this patch to remove ShenandoahHeuristic::record_gc_start()/end() methods, they have no implementation and are called from wrong places. Bug: https://bugs.openjdk.java.net/browse/JDK-8242375 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242375/webrev.00/index.html Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Wed Apr 8 15:10:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Apr 2020 17:10:14 +0200 Subject: [15] RFR 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods In-Reply-To: <256ecae7-92d5-b32b-3d34-bd34a513fff2@redhat.com> References: <256ecae7-92d5-b32b-3d34-bd34a513fff2@redhat.com> Message-ID: <7004c4a5-a2fb-93ff-8dde-3a6d41204d5b@redhat.com> On 4/8/20 4:32 PM, Zhengyu Gu wrote: > Please review this patch to remove > ShenandoahHeuristic::record_gc_start()/end() methods, they have no > implementation and are called from wrong places. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242375 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242375/webrev.00/index.html Looks good! -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 8 15:12:38 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 8 Apr 2020 17:12:38 +0200 Subject: [15] RFR 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods In-Reply-To: <256ecae7-92d5-b32b-3d34-bd34a513fff2@redhat.com> References: <256ecae7-92d5-b32b-3d34-bd34a513fff2@redhat.com> Message-ID: <0ade8c16-9779-026a-ef4e-fdd86167835f@redhat.com> Ok, looks good! Thank you! Roman > Please review this patch to remove > ShenandoahHeuristic::record_gc_start()/end() methods, they have no > implementation and are called from wrong places. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242375 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242375/webrev.00/index.html > > > Test: > ? hotspot_gc_shenandoah > > > Thanks, > > -Zhengyu > From zgu at redhat.com Wed Apr 8 20:12:16 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 8 Apr 2020 16:12:16 -0400 Subject: [15] 8242400: Shenandoah: Restore logging to pre-jdk8241984 format Message-ID: JDK-8241984 changed logging format, which is not desirable. This patch intents to restore old format: For example: ... 0.261s][info][gc,start ] GC(0) Concurrent roots processing [0.261s][info][gc,task ] GC(0) Using 2 of 4 workers for concurrent root processing [0.262s][info][gc ] GC(0) Concurrent roots processing 0.478ms [0.262s][info][gc,start ] GC(0) Concurrent cleanup [0.268s][info][gc ] GC(0) Concurrent cleanup 68M->12M(256M) 5.745ms [0.268s][info][gc,ergo ] GC(0) Free: 230M, Max: 256K regular, 174M humongous, Frag: 25% external, 0% internal; Reserve: 13312K, Max: 256K ... Bug: https://bugs.openjdk.java.net/browse/JDK-8242400 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242400/webrev.00/index.html Test: hotspot_gc_shenandoah Eyeball outputs Eyeball JMC events Thanks, -Zhengyu From shade at redhat.com Thu Apr 9 05:05:55 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 9 Apr 2020 07:05:55 +0200 Subject: [15] 8242400: Shenandoah: Restore logging to pre-jdk8241984 format In-Reply-To: References: Message-ID: <108c8e0b-461b-4d12-8944-58ca9ad6eabd@redhat.com> On 4/8/20 10:12 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8242400 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242400/webrev.00/index.html Looks good! -- Thanks, -Aleksey From adityam at microsoft.com Sat Apr 11 01:09:04 2020 From: adityam at microsoft.com (Aditya Mandaleeka) Date: Sat, 11 Apr 2020 01:09:04 +0000 Subject: RFR: 8241142: Shenandoah: should not use parallel reference processing with single GC thread Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8241142 Webrev: https://cr.openjdk.java.net/~adityam/8241142/webrev.00/ This change makes it so that MT reference processing is no longer enabled when there is only a single GC thread. hotspot_gc_shenandoah passes with -XX:ParallelGCThreads=1 Thanks, Aditya From cocorossello at gmail.com Sun Apr 12 17:51:20 2020 From: cocorossello at gmail.com (Vicente Rossello) Date: Sun, 12 Apr 2020 19:51:20 +0200 Subject: Class unloading in jdk15 Message-ID: Hi, I tried shenandoah with JDK15 (latest build from builds.shipilev.net) in our build, it works better than with G1, without even tuning anything, so that's great. I also tried enabling class unloading (we have it disabled with G1, we don't really get a lot of memory back, but GC times do increase a little bit), but it didn't work with shenandoah, GC times become very high. These are GC logs of our full build, with and without class unloading: https://gist.github.com/cocorossello/2c7e774b89f7cb3e3c97ec5758d879ff Our application is a web application, using dependency injection and dynamic proxies. I have tried to make a reproducer but I couldn't, it's not an easy task... Maybe the problem comes from dependency injection that creates proxies... I have tried reducing the build and enabling class load/unload logs (-verbose:class), to see if that helps: https://gist.github.com/cocorossello/f77049148e694b91e785696b1808fb4e -> Reduced build, class unloading off, verbose class define https://gist.github.com/cocorossello/52c1c88c782adc1a0537fd8aa92a6c82 -> Reduced build, class unloading on, verbose class define Please let me know if I can do something else, unfortunately I can't share the code. Thank you, Vicente. From zgu at redhat.com Mon Apr 13 13:08:56 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 13 Apr 2020 09:08:56 -0400 Subject: Class unloading in jdk15 In-Reply-To: References: Message-ID: Hi Vicente, Thanks for reporting the problem. I think we have a bug in setting up pacing for evacuation, where we can not reuse immediately garbage regions until concurrent class unloading is completed. I see a few allocation failures during that phase, that sent GCs into STW modes. In the meanwhile, you way want to play with pacing parameters for aggressive pacing. -Zhengyu On 4/12/20 1:51 PM, Vicente Rossello wrote: > Hi, > > I tried shenandoah with JDK15 (latest build from builds.shipilev.net) in > our build, it works better than with G1, without even tuning anything, so > that's great. > > I also tried enabling class unloading (we have it disabled with G1, > we don't really get a lot of memory back, but GC times do increase a little > bit), but it didn't work with shenandoah, GC times become very high. > > These are GC logs of our full build, with and without class unloading: > https://gist.github.com/cocorossello/2c7e774b89f7cb3e3c97ec5758d879ff > > Our application is a web application, using dependency injection and > dynamic proxies. I have tried to make a reproducer but I couldn't, it's not > an easy task... Maybe the problem comes from dependency injection that > creates proxies... > > I have tried reducing the build and enabling class load/unload logs > (-verbose:class), to see if that helps: > > https://gist.github.com/cocorossello/f77049148e694b91e785696b1808fb4e -> > Reduced build, class unloading off, verbose class define > > > https://gist.github.com/cocorossello/52c1c88c782adc1a0537fd8aa92a6c82 -> > Reduced build, class unloading on, verbose class define > > Please let me know if I can do something else, unfortunately I can't share > the code. > > Thank you, > Vicente. > From shade at redhat.com Tue Apr 14 06:41:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 08:41:42 +0200 Subject: RFR: 8241142: Shenandoah: should not use parallel reference processing with single GC thread In-Reply-To: References: Message-ID: <4468427e-6950-d81b-5554-b56f6ed5edf0@redhat.com> Hi, On 4/11/20 3:09 AM, Aditya Mandaleeka wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8241142 > > Webrev: > https://cr.openjdk.java.net/~adityam/8241142/webrev.00/ > > This change makes it so that MT reference processing is no longer enabled when there is only a > single GC thread. Sorry for late reply, Easter holidays. The patch looks good, but I think it could be improved like this: https://cr.openjdk.java.net/~shade/8241142/webrev.01/ Agree? -- Thanks, -Aleksey From shade at redhat.com Tue Apr 14 09:54:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 11:54:33 +0200 Subject: RFR (S) 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles Message-ID: <417fbfd7-9df9-7330-40d7-c8e5eb483e3f@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8242625 This is another logging regression since JDK-8241984. Fix is similar to what JDK-8242400 done: https://hg.openjdk.java.net/jdk/jdk/rev/7992ff451fec Webrev: https://cr.openjdk.java.net/~shade/8242625/webrev.01/ Testing: eyeballing gc logs, hotspot_gc_shenandoah (running) -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 14 10:29:19 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Apr 2020 12:29:19 +0200 Subject: RFR (S) 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles In-Reply-To: <417fbfd7-9df9-7330-40d7-c8e5eb483e3f@redhat.com> References: <417fbfd7-9df9-7330-40d7-c8e5eb483e3f@redhat.com> Message-ID: <8ab17f57-c205-16ac-7d5f-5cecc45d3b2f@redhat.com> Ok. Thanks, Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8242625 > > This is another logging regression since JDK-8241984. Fix is similar to what JDK-8242400 done: > https://hg.openjdk.java.net/jdk/jdk/rev/7992ff451fec > > Webrev: > https://cr.openjdk.java.net/~shade/8242625/webrev.01/ > > Testing: eyeballing gc logs, hotspot_gc_shenandoah (running) > From cocorossello at gmail.com Tue Apr 14 11:35:11 2020 From: cocorossello at gmail.com (Vicente Rossello) Date: Tue, 14 Apr 2020 13:35:11 +0200 Subject: Class unloading in jdk15 In-Reply-To: References: Message-ID: Hi, I can wait for a patch, it doesn't matter. We don't really need class unloading (at least now), I was just testing. Please let me know if I can try a patch (once available) or do something else. I'm planning to switch our production to shenandoah once jdk15 is out (or at least RC), with class unloading enabled or disabled. Vicente. On Mon, Apr 13, 2020 at 3:09 PM Zhengyu Gu wrote: > Hi Vicente, > > Thanks for reporting the problem. > > I think we have a bug in setting up pacing for evacuation, where we can > not reuse immediately garbage regions until concurrent class unloading > is completed. I see a few allocation failures during that phase, that > sent GCs into STW modes. > > In the meanwhile, you way want to play with pacing parameters for > aggressive pacing. > > -Zhengyu > > On 4/12/20 1:51 PM, Vicente Rossello wrote: > > Hi, > > > > I tried shenandoah with JDK15 (latest build from builds.shipilev.net) in > > our build, it works better than with G1, without even tuning anything, so > > that's great. > > > > I also tried enabling class unloading (we have it disabled with G1, > > we don't really get a lot of memory back, but GC times do increase a > little > > bit), but it didn't work with shenandoah, GC times become very high. > > > > These are GC logs of our full build, with and without class unloading: > > https://gist.github.com/cocorossello/2c7e774b89f7cb3e3c97ec5758d879ff > > > > Our application is a web application, using dependency injection and > > dynamic proxies. I have tried to make a reproducer but I couldn't, it's > not > > an easy task... Maybe the problem comes from dependency injection that > > creates proxies... > > > > I have tried reducing the build and enabling class load/unload logs > > (-verbose:class), to see if that helps: > > > > https://gist.github.com/cocorossello/f77049148e694b91e785696b1808fb4e > -> > > Reduced build, class unloading off, verbose class define > > > > > > https://gist.github.com/cocorossello/52c1c88c782adc1a0537fd8aa92a6c82 > -> > > Reduced build, class unloading on, verbose class define > > > > Please let me know if I can do something else, unfortunately I can't > share > > the code. > > > > Thank you, > > Vicente. > > > > From zgu at redhat.com Tue Apr 14 12:40:52 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Apr 2020 08:40:52 -0400 Subject: RFR (S) 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles In-Reply-To: <417fbfd7-9df9-7330-40d7-c8e5eb483e3f@redhat.com> References: <417fbfd7-9df9-7330-40d7-c8e5eb483e3f@redhat.com> Message-ID: Hi Aleksey, Thanks for fixing it. There are two issues comparing to pre-JDK-8241984 1) entry_uncommit also reports heap usage. 2) full gc reports GC cause. -Zhengyu On 4/14/20 5:54 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8242625 > > This is another logging regression since JDK-8241984. Fix is similar to what JDK-8242400 done: > https://hg.openjdk.java.net/jdk/jdk/rev/7992ff451fec > > Webrev: > https://cr.openjdk.java.net/~shade/8242625/webrev.01/ > > Testing: eyeballing gc logs, hotspot_gc_shenandoah (running) > From shade at redhat.com Tue Apr 14 12:48:45 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 14:48:45 +0200 Subject: RFR (S) 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles In-Reply-To: References: <417fbfd7-9df9-7330-40d7-c8e5eb483e3f@redhat.com> Message-ID: <57f2634b-27a6-bc9c-8ccc-6e9bfe878aa8@redhat.com> On 4/14/20 2:40 PM, Zhengyu Gu wrote: > 1) entry_uncommit also reports heap usage. Right. I would file a follow-up for that. > 2) full gc reports GC cause. I think we can ignore this for now, as our "Trigger: " message provides a better diagnostics anyway. -- Thanks, -Aleksey From shade at redhat.com Tue Apr 14 13:24:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 15:24:01 +0200 Subject: RFR (XS) 8242638: Shenandoah: restore heap logging for uncommit Message-ID: <12f25696-8664-88e9-a542-923f90e2ca29@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8242638 Fix: diff -r 72920184520f src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 14 14:45:24 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 14 15:22:52 2020 +0200 @@ -2870,5 +2870,5 @@ void ShenandoahHeap::entry_uncommit(double shrink_before) { static const char *msg = "Concurrent uncommit"; - ShenandoahConcurrentPhase gc_phase(msg); + ShenandoahConcurrentPhase gc_phase(msg, true /* log_heap_usage */); EventMark em("%s", msg); Testing: hotspot_gc_shenandoah, eyeballing logs -- Thanks, -Aleksey From zgu at redhat.com Tue Apr 14 13:27:47 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Apr 2020 09:27:47 -0400 Subject: RFR (XS) 8242638: Shenandoah: restore heap logging for uncommit In-Reply-To: <12f25696-8664-88e9-a542-923f90e2ca29@redhat.com> References: <12f25696-8664-88e9-a542-923f90e2ca29@redhat.com> Message-ID: Looks good. -Zhengyu On 4/14/20 9:24 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8242638 > > Fix: > > diff -r 72920184520f src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 14 14:45:24 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 14 15:22:52 2020 +0200 > @@ -2870,5 +2870,5 @@ > void ShenandoahHeap::entry_uncommit(double shrink_before) { > static const char *msg = "Concurrent uncommit"; > - ShenandoahConcurrentPhase gc_phase(msg); > + ShenandoahConcurrentPhase gc_phase(msg, true /* log_heap_usage */); > EventMark em("%s", msg); > > Testing: hotspot_gc_shenandoah, eyeballing logs > From shade at redhat.com Tue Apr 14 14:27:59 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 16:27:59 +0200 Subject: RFR (S) 8242641: Shenandoah: clear live data and update TAMS optimistically Message-ID: <826b747b-e904-61f5-da94-f6ad91769ea4@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8242641 After CM-with-UR removal, we are open to clear liveness data and update TAMS concurrently/optimistically. Shaves off a few microseconds on large number of regions. Webrev: https://cr.openjdk.java.net/~shade/8242641/webrev.01/ Testing: hotspot_gc_shenandoah, eyeballing benchmarks -- Thanks, -Aleksey From zgu at redhat.com Tue Apr 14 15:11:43 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Apr 2020 11:11:43 -0400 Subject: [15] RFR 8242602: Shenandoah: allow earlier recycle of trashed regions during concurrent root processing Message-ID: Please review this patch that allows early recycling of trashed regions during concurrent root processing. We need to preserve immediate garbage regions during weak root processing, since they may contain those dead oops and we need to be able to identify them via is_alive closure. After that, we can safely recycle them. Bug: https://bugs.openjdk.java.net/browse/JDK-8242602 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242602/webrev.00/ Test: hotspot_gc_shenandoah tools/javac Thanks, -Zhengyu From shade at redhat.com Tue Apr 14 16:28:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 18:28:08 +0200 Subject: [15] RFR 8242602: Shenandoah: allow earlier recycle of trashed regions during concurrent root processing In-Reply-To: References: Message-ID: <2db11184-b038-aad6-43d9-9efe81d838f1@redhat.com> On 4/14/20 5:11 PM, Zhengyu Gu wrote: > Please review this patch that allows early recycling of trashed regions > during concurrent root processing. > > We need to preserve immediate garbage regions during weak root > processing, since they may contain those dead oops and we need to be > able to identify them via is_alive closure. After that, we can safely > recycle them. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242602 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242602/webrev.00/ I don't understand the interaction between flags and should_do* in op_roots. void ShenandoahHeap::op_roots() { if (is_concurrent_root_in_progress()) { if (ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) { ...weak roots... set_concurrent_weak_root_in_progress(false); } if (ShenandoahConcurrentRoots::should_do_concurrent_roots()) { ...all roots... } set_concurrent_weak_root_in_progress(false); set_concurrent_root_in_progress(false); } } Can't we just follow the flags in op_roots? void ShenandoahHeap::op_roots() { if (is_concurrent_root_in_progress()) { if (is_concurrent_weak_root_in_progress()) { ... set_concurrent_weak_root_in_progress(false); } ...all roots... set_concurrent_root_in_progress(false); } } ...and then make prepare_concurrent_roots() do: void ShenandoahHeap::prepare_concurrent_roots() { assert(SafepointSynchronize::is_at_safepoint(), "Must be at a safepoint"); if (ShenandoahConcurrentRoots::should_do_concurrent_roots()) { set_concurrent_root_in_progress(true); if (ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) { set_concurrent_weak_root_in_progress(true); } } } This carries what needs to be done in flags, and flags get down as soon as the relevant block is finished. -- Thanks, -Aleksey From shade at redhat.com Tue Apr 14 16:33:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 18:33:01 +0200 Subject: [15] RFR 8242602: Shenandoah: allow earlier recycle of trashed regions during concurrent root processing In-Reply-To: <2db11184-b038-aad6-43d9-9efe81d838f1@redhat.com> References: <2db11184-b038-aad6-43d9-9efe81d838f1@redhat.com> Message-ID: <0f5ab664-1ed1-1330-4345-c7e37ef8728d@redhat.com> On 4/14/20 6:28 PM, Aleksey Shipilev wrote: > On 4/14/20 5:11 PM, Zhengyu Gu wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242602 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242602/webrev.00/ > > This carries what needs to be done in flags, and flags get down as soon as the relevant block is > finished. ...or maybe we should just split weak/strong roots into phases: https://bugs.openjdk.java.net/browse/JDK-8242643 ...which would handle all this already? -- Thanks, -Aleksey From zgu at redhat.com Tue Apr 14 17:22:37 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Apr 2020 13:22:37 -0400 Subject: [15] RFR 8242602: Shenandoah: allow earlier recycle of trashed regions during concurrent root processing In-Reply-To: <0f5ab664-1ed1-1330-4345-c7e37ef8728d@redhat.com> References: <2db11184-b038-aad6-43d9-9efe81d838f1@redhat.com> <0f5ab664-1ed1-1330-4345-c7e37ef8728d@redhat.com> Message-ID: <3f8fc956-26d8-1d99-0164-01cda6a3ace2@redhat.com> On 4/14/20 12:33 PM, Aleksey Shipilev wrote: > On 4/14/20 6:28 PM, Aleksey Shipilev wrote: >> On 4/14/20 5:11 PM, Zhengyu Gu wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242602 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242602/webrev.00/ >> >> This carries what needs to be done in flags, and flags get down as soon as the relevant block is >> finished. > > ...or maybe we should just split weak/strong roots into phases: > https://bugs.openjdk.java.net/browse/JDK-8242643 > > ...which would handle all this already? Yes, the flags are handled in JDK-8242643 -Zhengyu > From zgu at redhat.com Tue Apr 14 18:00:36 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Apr 2020 14:00:36 -0400 Subject: [15] RFR 8242643: Shenandoah: split concurrent weak and strong root processing Message-ID: Let's split concurrent root phase into concurrent weak root and concurrent strong root phases. Bug: https://bugs.openjdk.java.net/browse/JDK-8242643 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242643/webrev.00/index.html Test: hotspot_gc_shenandoah tools/javac Thanks, -Zhengyu From shade at redhat.com Tue Apr 14 18:03:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 20:03:52 +0200 Subject: [15] RFR 8242602: Shenandoah: allow earlier recycle of trashed regions during concurrent root processing In-Reply-To: <3f8fc956-26d8-1d99-0164-01cda6a3ace2@redhat.com> References: <2db11184-b038-aad6-43d9-9efe81d838f1@redhat.com> <0f5ab664-1ed1-1330-4345-c7e37ef8728d@redhat.com> <3f8fc956-26d8-1d99-0164-01cda6a3ace2@redhat.com> Message-ID: <4364b81d-9a9f-be85-ae85-2ff6a7ce97d0@redhat.com> On 4/14/20 7:22 PM, Zhengyu Gu wrote: > On 4/14/20 12:33 PM, Aleksey Shipilev wrote: >> On 4/14/20 6:28 PM, Aleksey Shipilev wrote: >>> On 4/14/20 5:11 PM, Zhengyu Gu wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242602 >>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242602/webrev.00/ >>> >>> This carries what needs to be done in flags, and flags get down as soon as the relevant block is >>> finished. >> >> ...or maybe we should just split weak/strong roots into phases: >> https://bugs.openjdk.java.net/browse/JDK-8242643 >> >> ...which would handle all this already? > > Yes, the flags are handled in JDK-8242643 All right, fine. -- Thanks, -Aleksey From shade at redhat.com Tue Apr 14 18:10:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 20:10:56 +0200 Subject: [15] RFR 8242643: Shenandoah: split concurrent weak and strong root processing In-Reply-To: References: Message-ID: On 4/14/20 8:00 PM, Zhengyu Gu wrote: > Let's split concurrent root phase into concurrent weak root and > concurrent strong root phases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242643 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242643/webrev.00/index.html *) shenandoahHeap.cpp: can we label them "Concurrent weak roots" and "Concurrent strong roots"? At very least drop the underscore. "processing" feels redundant. 2810 static const char* msg = "Concurrent weak_roots processing"; ... 2825 static const char* msg = "Concurrent strong roots processing"; *) shenandoahHeap.cpp, excess newline: 2838 2839 *) shenandoahHeap.cpp: I suggest we rename the flags to is_strong_roots_in_progress and is_weak_roots_in_progress. It would underline they are siblings, not parent-child. *) shenandoahControlThread.cpp: I thought one of the points was to allow concurrent cleanup to run right after weak roots? Since strong roots are only updated-evac'ed, they are not need with shortcut cycles, so we can move them below under heap->is_evacuation_in_progress block? 345 // Processing weak roots 346 heap->entry_weak_roots(); 347 348 // Processing strong 349 heap->entry_strong_roots(); 350 -- Thanks, -Aleksey From adityam at microsoft.com Tue Apr 14 19:15:02 2020 From: adityam at microsoft.com (Aditya Mandaleeka) Date: Tue, 14 Apr 2020 19:15:02 +0000 Subject: RFR: 8241142: Shenandoah: should not use parallel reference processing with single GC thread In-Reply-To: <4468427e-6950-d81b-5554-b56f6ed5edf0@redhat.com> References: <4468427e-6950-d81b-5554-b56f6ed5edf0@redhat.com> Message-ID: Yes, I like it. Thanks! -----Original Message----- From: Aleksey Shipilev Sent: Monday, April 13, 2020 11:42 PM To: Aditya Mandaleeka ; shenandoah-dev Subject: Re: RFR: 8241142: Shenandoah: should not use parallel reference processing with single GC thread Hi, On 4/11/20 3:09 AM, Aditya Mandaleeka wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8241142 > > Webrev: > https://cr.openjdk.java.net/~adityam/8241142/webrev.00/ > > This change makes it so that MT reference processing is no longer enabled when there is only a > single GC thread. Sorry for late reply, Easter holidays. The patch looks good, but I think it could be improved like this: https://cr.openjdk.java.net/~shade/8241142/webrev.01/ Agree? -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 14 19:40:21 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 14 Apr 2020 21:40:21 +0200 Subject: RFR (S) 8242641: Shenandoah: clear live data and update TAMS optimistically In-Reply-To: <826b747b-e904-61f5-da94-f6ad91769ea4@redhat.com> References: <826b747b-e904-61f5-da94-f6ad91769ea4@redhat.com> Message-ID: <9d794453-e713-71d2-ce74-ac235791dcf6@redhat.com> Looks good. Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8242641 > > After CM-with-UR removal, we are open to clear liveness data and update TAMS > concurrently/optimistically. Shaves off a few microseconds on large number of regions. > > Webrev: > https://cr.openjdk.java.net/~shade/8242641/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing benchmarks > From zgu at redhat.com Tue Apr 14 19:41:27 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Apr 2020 15:41:27 -0400 Subject: [15] RFR 8242643: Shenandoah: split concurrent weak and strong root processing In-Reply-To: References: Message-ID: <2d814ab7-ddce-6009-3857-ac09962dfab0@redhat.com> On 4/14/20 2:10 PM, Aleksey Shipilev wrote: > On 4/14/20 8:00 PM, Zhengyu Gu wrote: >> Let's split concurrent root phase into concurrent weak root and >> concurrent strong root phases. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242643 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242643/webrev.00/index.html > > *) shenandoahHeap.cpp: can we label them "Concurrent weak roots" and "Concurrent strong roots"? At > very least drop the underscore. "processing" feels redundant. > > 2810 static const char* msg = "Concurrent weak_roots processing"; > ... > 2825 static const char* msg = "Concurrent strong roots processing"; > > *) shenandoahHeap.cpp, excess newline: > > 2838 > 2839 > Fixed > *) shenandoahHeap.cpp: I suggest we rename the flags to is_strong_roots_in_progress and > is_weak_roots_in_progress. It would underline they are siblings, not parent-child. Right. > > *) shenandoahControlThread.cpp: I thought one of the points was to allow concurrent cleanup to run > right after weak roots? Since strong roots are only updated-evac'ed, they are not need with shortcut > cycles, so we can move them below under heap->is_evacuation_in_progress block? Let's set concurrent_strong_in_progress conditionally, so it does not leak in case of !is_evacuation_in_progress. Update: http://cr.openjdk.java.net/~zgu/JDK-8242643/webrev.01/index.html Test in progress. Thanks, -Zhengyu > > 345 // Processing weak roots > 346 heap->entry_weak_roots(); > 347 > 348 // Processing strong > 349 heap->entry_strong_roots(); > 350 > > From zgu at redhat.com Tue Apr 14 20:15:00 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Apr 2020 16:15:00 -0400 Subject: [15] RFR 8242643: Shenandoah: split concurrent weak and strong root processing In-Reply-To: <2d814ab7-ddce-6009-3857-ac09962dfab0@redhat.com> References: <2d814ab7-ddce-6009-3857-ac09962dfab0@redhat.com> Message-ID: <34ef4881-9e17-9ced-ed48-2fb4b4c943cb@redhat.com> Updated based on offline discussion: http://cr.openjdk.java.net/~zgu/JDK-8242643/webrev.02/ -Zhengyu On 4/14/20 3:41 PM, Zhengyu Gu wrote: > > > On 4/14/20 2:10 PM, Aleksey Shipilev wrote: >> On 4/14/20 8:00 PM, Zhengyu Gu wrote: >>> Let's split concurrent root phase into concurrent weak root and >>> concurrent strong root phases. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8242643 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242643/webrev.00/index.html >> >> *) shenandoahHeap.cpp: can we label them "Concurrent weak roots" and >> "Concurrent strong roots"? At >> very least drop the underscore. "processing" feels redundant. >> >> 2810?? static const char* msg = "Concurrent weak_roots processing"; >> ... >> 2825?? static const char* msg = "Concurrent strong roots processing"; >> >> *) shenandoahHeap.cpp, excess newline: >> >> 2838 >> 2839 >> > Fixed > >> *) shenandoahHeap.cpp: I suggest we rename the flags to >> is_strong_roots_in_progress and >> is_weak_roots_in_progress. It would underline they are siblings, not >> parent-child. > Right. > >> >> *) shenandoahControlThread.cpp: I thought one of the points was to >> allow concurrent cleanup to run >> right after weak roots? Since strong roots are only updated-evac'ed, >> they are not need with shortcut >> cycles, so we can move them below under >> heap->is_evacuation_in_progress block? > > Let's set concurrent_strong_in_progress conditionally, so it does not > leak in case of !is_evacuation_in_progress. > > > Update: http://cr.openjdk.java.net/~zgu/JDK-8242643/webrev.01/index.html > > Test in progress. > > Thanks, > > -Zhengyu > >> >> ? 345?? // Processing weak roots >> ? 346?? heap->entry_weak_roots(); >> ? 347 >> ? 348?? // Processing strong >> ? 349?? heap->entry_strong_roots(); >> ? 350 >> >> From shade at redhat.com Tue Apr 14 20:18:17 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 22:18:17 +0200 Subject: [15] RFR 8242643: Shenandoah: split concurrent weak and strong root processing In-Reply-To: <34ef4881-9e17-9ced-ed48-2fb4b4c943cb@redhat.com> References: <2d814ab7-ddce-6009-3857-ac09962dfab0@redhat.com> <34ef4881-9e17-9ced-ed48-2fb4b4c943cb@redhat.com> Message-ID: <9a92fb1e-4b37-0399-a648-cbf3d1e8f85c@redhat.com> On 4/14/20 10:15 PM, Zhengyu Gu wrote: > Updated based on offline discussion: > > http://cr.openjdk.java.net/~zgu/JDK-8242643/webrev.02/ Looks fine. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Apr 14 20:25:35 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 Apr 2020 21:25:35 +0100 Subject: [RFR] [8u] 8u252-b09 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b09: - S8204152: SignedObject throws NullPointerException for null keys with an initialized Signature object - S8219597: (bf) Heap buffer state changes could provoke unexpected exceptions - S8223898: Forward references to Nashorn - S8223904: Improve Nashorn matching - S8224541: Better mapping of serial ENUMs - S8224549: Less Blocking Array Queues - S8225603: Enhancement for big integers - S8227542: Manifest improved jar headers - S8231415: Better signatures in XML - S8233250: Better X11 rendering - S8233410: Better Build Scripting - S8234027: Better JCEKS key support - S8234408: Improve TLS session handling - S8234825: Better Headings for HTTP Servers - S8234841: Enhance buffering of byte buffers - S8235274: Enhance typing of methods - S8236201: Better Scanner conversions - S8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap Main issues of note: Simple merge, no HotSpot changes. diffstat for root b/.hgtags | 1 + b/common/autoconf/flags.m4 | 15 +++++++++++++-- b/common/autoconf/generated-configure.sh | 17 ++++++++++++++--- 3 files changed, 28 insertions(+), 5 deletions(-) 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 b/src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java | 6 +-- b/src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java | 6 +-- b/src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java | 16 ++++++++-- 4 files changed, 21 insertions(+), 8 deletions(-) diffstat for jdk b/.hgtags | 1 b/make/CompileLaunchers.gmk | 1 b/src/share/classes/com/sun/crypto/provider/JceKeyStore.java | 28 +++ b/src/share/classes/com/sun/crypto/provider/KeyProtector.java | 9 - b/src/share/classes/com/sun/crypto/provider/SealedObjectForKeyProtector.java | 26 ++- b/src/share/classes/com/sun/net/httpserver/Headers.java | 34 ++++ b/src/share/classes/java/io/ObjectInputStream.java | 4 b/src/share/classes/java/io/ObjectStreamClass.java | 16 +- b/src/share/classes/java/lang/instrument/package.html | 7 b/src/share/classes/java/lang/invoke/MethodType.java | 38 +--- b/src/share/classes/java/math/MutableBigInteger.java | 24 ++- b/src/share/classes/java/nio/ByteBufferAs-X-Buffer.java.template | 1 b/src/share/classes/java/nio/Direct-X-Buffer.java.template | 1 b/src/share/classes/java/nio/Heap-X-Buffer.java.template | 80 ++++++---- b/src/share/classes/java/nio/StringCharBuffer.java | 9 - b/src/share/classes/java/util/Scanner.java | 22 +- b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java | 10 + b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java | 10 + b/src/share/classes/sun/security/rsa/RSAKeyFactory.java | 3 b/src/share/classes/sun/security/ssl/ClientHandshaker.java | 2 b/src/share/classes/sun/security/ssl/SSLEngineImpl.java | 2 b/src/share/classes/sun/security/ssl/SSLSessionImpl.java | 15 - b/src/share/classes/sun/security/ssl/SSLSocketImpl.java | 2 b/src/share/instrument/InvocationAdapter.c | 22 ++ b/src/share/native/sun/awt/splashscreen/splashscreen_gfx_impl.c | 2 b/src/share/native/sun/security/ec/impl/mpi.c | 9 - b/src/solaris/native/sun/awt/multiVis.c | 2 b/src/solaris/native/sun/java2d/x11/X11PMBlitLoops.c | 2 b/src/solaris/native/sun/java2d/x11/X11TextRenderer_md.c | 2 b/src/solaris/native/sun/java2d/x11/XRBackendNative.c | 6 b/test/java/math/BigInteger/ModInvTime.java | 57 +++++++ 31 files changed, 316 insertions(+), 131 deletions(-) diffstat for hotspot b/.hgtags | 1 + 1 file changed, 1 insertion(+) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue Apr 14 20:28:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 22:28:11 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b09 Upstream Sync In-Reply-To: References: Message-ID: On 4/14/20 10:25 PM, Andrew John Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/ > > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/hotspot/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/langtools/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/root/merge.changeset Look good. > Ok to push? Yes. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Apr 14 20:32:13 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 Apr 2020 21:32:13 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u252-b09 Upstream Sync In-Reply-To: References: Message-ID: <724d1017-83cb-3cbe-30eb-b74da0710b12@redhat.com> On 14/04/2020 21:28, Aleksey Shipilev wrote: > On 4/14/20 10:25 PM, Andrew John Hughes wrote: >> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/ >> >> Merge changesets: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jaxws/merge.changeset > > Look trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/jdk/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/hotspot/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/langtools/merge.changeset > > Look trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b09/root/merge.changeset > > Look good. > >> Ok to push? > > Yes. > Thanks, pushed. -- 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 gnu.andrew at redhat.com Tue Apr 14 20:29:55 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 Apr 2020 21:29:55 +0100 Subject: RFR: [11u] jdk-11.0.7+10 / jdk-11.0.7-ga Message-ID: Webrev: https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.7/ Merge changeset: https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.7/11.0.7+10.merge Changes in shenandoah-jdk-11.0.7+10: - S8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation - S8189861: Refactor CacheFind - S8204551: Event descriptions are truncated in logs - S8210459: Add support for generating compile_commands.json - S8214534: Setting of THIS_FILE in the build is broken - S8217728: Speed up incremental rerun of "make hotspot" - S8219597: (bf) Heap buffer state changes could provoke unexpected exceptions - S8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build - S8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC - S8222264: Windows incremental build is broken with JDK-8217728 - S8223678: Add Visual Studio Code workspace generation support (for native code) - S8223898: Forward references to Nashorn - S8223904: Improve Nashorn matching - S8224541: Better mapping of serial ENUMs - S8224549: Less Blocking Array Queues - S8225603: Enhancement for big integers - S8226346: Build better binary builders - S8227467: Better class method invocations - S8227542: Manifest improved jar headers - S8229733: TLS message handling improvements - S8231415: Better signatures in XML - S8231785: Improved socket permissions - S8232424: More constrained algorithms - S8232581: Improve TLS verification - S8233250: Better X11 rendering - S8233383: Various minor fixes - S8233410: Better Build Scripting - S8234027: Better JCEKS key support - S8234408: Improve TLS session handling - S8234825: Better Headings for HTTP Servers - S8234841: Enhance buffering of byte buffers - S8235274: Enhance typing of methods - S8235691: Enhance TLS connectivity - S8236201: Better Scanner conversions - S8237879: make 4.3 breaks build - S8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. (with Shenandoah only built on x86_64 & aarch64 through configure logic) Ok to push? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue Apr 14 20:34:54 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 22:34:54 +0200 Subject: RFR: [11u] jdk-11.0.7+10 / jdk-11.0.7-ga In-Reply-To: References: Message-ID: <0526f954-5d5a-b444-b710-9ddd9a77b6b3@redhat.com> On 4/14/20 10:29 PM, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.7/ > Merge changeset: > https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.7/11.0.7+10.merge Looks good. > Ok to push? Yes. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Apr 14 20:40:43 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 Apr 2020 21:40:43 +0100 Subject: RFR: [11u] jdk-11.0.7+10 / jdk-11.0.7-ga In-Reply-To: <0526f954-5d5a-b444-b710-9ddd9a77b6b3@redhat.com> References: <0526f954-5d5a-b444-b710-9ddd9a77b6b3@redhat.com> Message-ID: <99b8cada-53bf-97c2-36d5-b07dab39bf71@redhat.com> On 14/04/2020 21:34, Aleksey Shipilev wrote: > On 4/14/20 10:29 PM, Andrew John Hughes wrote: >> Webrev: https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.7/ >> Merge changeset: >> https://cr.openjdk.java.net/~andrew/shenandoah-11/11.0.7/11.0.7+10.merge > > Looks good. > >> Ok to push? > > Yes. > Pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Apr 15 09:20:59 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Apr 2020 11:20:59 +0200 Subject: [8] RFC: Pick up 8u252-ga from upstream Message-ID: <0d68734a-d223-30a2-1dbf-e1f148cc8950@redhat.com> Upstream aarch64-port/jdk8u-shenandoah had posted 8u252-ga tag. Let's pick it up to sh/jdk8. Merge is trivial/simple. Changesets are big and not useful for review. Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From zgu at redhat.com Wed Apr 15 12:33:58 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 15 Apr 2020 08:33:58 -0400 Subject: [8] RFC: Pick up 8u252-ga from upstream In-Reply-To: <0d68734a-d223-30a2-1dbf-e1f148cc8950@redhat.com> References: <0d68734a-d223-30a2-1dbf-e1f148cc8950@redhat.com> Message-ID: <4c8d7897-4b50-f231-ec94-18988a096c80@redhat.com> Okay. -Zhengyu On 4/15/20 5:20 AM, Aleksey Shipilev wrote: > Upstream aarch64-port/jdk8u-shenandoah had posted 8u252-ga tag. Let's pick it up to sh/jdk8. > > Merge is trivial/simple. Changesets are big and not useful for review. > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Wed Apr 15 14:25:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Apr 2020 16:25:42 +0200 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200415/webrev.01/ Backport window for sh/jdk11 is about to open. This bulk backports the significant bunch of outstanding work. Don't be scared about the number of them: those are either bulk removals, or a series of simple changes. That said, please review carefully. Changes: [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings [backport] 8240315: Shenandoah: Rename ShLBN::get_barrier_strength() [backport] 8220503: Move ShenandoahTerminatorTerminator::should_exit_termination out of header [backport] 8240749: Shenandoah: refactor ShenandoahUtils [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation [backport] 8240873: Shenandoah: Short-cut arraycopy barriers [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently [backport] 8241534: Shenandoah: region status should include update watermark [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 [backport] 8241351: Shenandoah: fragmentation metrics overhaul [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation [backport] 8241520: Shenandoah: simplify region sequence numbers handling [backport] 8241583: Shenandoah: turn heap lock asserts into macros [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace [backport] 8241673: Shenandoah: refactor anti-false-sharing padding [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods [backport] 8241838: Shenandoah: no need to trash cset during final mark [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() [backport] 8241093: Shenandoah: editorial changes in flag descriptions [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it [backport] 8241985: Shenandoah: simplify collectable garbage logging [backport] 8241983: Shenandoah: simplify FreeSet logging [backport] 8242040: Shenandoah: print allocation failure type [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged [backport] 8242082: Shenandoah: Purge Traversal mode [backport] 8242107: Shenandoah: Fix aarch64 build after JDK-8242082 [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From zgu at redhat.com Wed Apr 15 16:05:17 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 15 Apr 2020 12:05:17 -0400 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 In-Reply-To: References: Message-ID: Good to me. -Zhengyu On 4/15/20 10:25 AM, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200415/webrev.01/ > > Backport window for sh/jdk11 is about to open. This bulk backports the significant bunch of > outstanding work. Don't be scared about the number of them: those are either bulk removals, or a > series of simple changes. That said, please review carefully. > > Changes: > [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings > [backport] 8240315: Shenandoah: Rename ShLBN::get_barrier_strength() > [backport] 8220503: Move ShenandoahTerminatorTerminator::should_exit_termination out of header > [backport] 8240749: Shenandoah: refactor ShenandoahUtils > [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker > [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts > [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles > [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks > [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation > [backport] 8240873: Shenandoah: Short-cut arraycopy barriers > [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently > [backport] 8241534: Shenandoah: region status should include update watermark > [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 > [backport] 8241351: Shenandoah: fragmentation metrics overhaul > [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" > [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation > [backport] 8241520: Shenandoah: simplify region sequence numbers handling > [backport] 8241583: Shenandoah: turn heap lock asserts into macros > [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace > [backport] 8241673: Shenandoah: refactor anti-false-sharing padding > [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved > [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() > [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap > [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods > [backport] 8241838: Shenandoah: no need to trash cset during final mark > [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion > [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number > [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number > [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines > [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() > [backport] 8241093: Shenandoah: editorial changes in flag descriptions > [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it > [backport] 8241985: Shenandoah: simplify collectable garbage logging > [backport] 8241983: Shenandoah: simplify FreeSet logging > [backport] 8242040: Shenandoah: print allocation failure type > [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target > [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold > [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag > [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters > [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged > [backport] 8242082: Shenandoah: Purge Traversal mode > [backport] 8242107: Shenandoah: Fix aarch64 build after JDK-8242082 > [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared > [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses > [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc > [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly > [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset > [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set > [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods > > Testing: hotspot_gc_shenandoah {fastdebug, release} > > From shade at redhat.com Wed Apr 15 17:41:16 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 15 Apr 2020 17:41:16 +0000 Subject: hg: shenandoah/jdk8: 26 new changesets Message-ID: <202004151741.03FHfGtq021624@aojmv0008.oracle.com> Changeset: d479de9aa3cb Author: andrew Date: 2020-01-27 05:42 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/d479de9aa3cb Merge jdk8u252-b01 ! .hgtags ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 9211af620770 Author: andrew Date: 2020-01-27 05:43 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/9211af620770 Added tag aarch64-shenandoah-jdk8u252-b01 for changeset d479de9aa3cb ! .hgtags Changeset: 3c9565d879d6 Author: andrew Date: 2020-02-04 03:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/3c9565d879d6 Merge jdk8u252-b02 ! .hgtags ! THIRD_PARTY_README ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: a3c7aac46ae6 Author: andrew Date: 2020-02-04 03:32 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/a3c7aac46ae6 Added tag aarch64-shenandoah-jdk8u252-b02 for changeset 3c9565d879d6 ! .hgtags Changeset: 1bf9055ae261 Author: andrew Date: 2020-02-18 18:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/1bf9055ae261 Merge jdk8u252-b03 ! .hgtags Changeset: 375a59b815b8 Author: andrew Date: 2020-02-18 18:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/375a59b815b8 Added tag aarch64-shenandoah-jdk8u252-b03 for changeset 1bf9055ae261 ! .hgtags Changeset: 31dd5a9bcd79 Author: andrew Date: 2020-02-23 04:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/31dd5a9bcd79 Merge jdk8u252-b04 ! .hgtags Changeset: 728fcdbd710f Author: andrew Date: 2020-02-23 04:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/728fcdbd710f Added tag aarch64-shenandoah-jdk8u252-b04 for changeset 31dd5a9bcd79 ! .hgtags Changeset: 8f0a4b79e082 Author: andrew Date: 2020-02-28 05:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/8f0a4b79e082 Merge jdk8u252-b05 ! .hgtags Changeset: 0ff25f1e7256 Author: andrew Date: 2020-02-28 05:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/0ff25f1e7256 Added tag aarch64-shenandoah-jdk8u252-b05 for changeset 8f0a4b79e082 ! .hgtags Changeset: 746815de8b5b Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/746815de8b5b Added tag jdk8u252-b06 for changeset bb464170d344 ! .hgtags Changeset: 8cdf46c368ee Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/8cdf46c368ee Merge jdk8u252-b06 ! .hgtags Changeset: 9c4e65dab4c0 Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/9c4e65dab4c0 Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 8cdf46c368ee ! .hgtags Changeset: cd896b195b15 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/cd896b195b15 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 8f0a4b79e082 ! .hgtags Changeset: 72a6d93679e5 Author: andrew Date: 2020-03-20 14:25 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/72a6d93679e5 Added tag jdk8u252-b07 for changeset 746815de8b5b ! .hgtags Changeset: 57a11875546a Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/57a11875546a Merge jdk8u252-b07 ! .hgtags Changeset: 72d8c6c077e1 Author: andrew Date: 2020-03-23 21:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/72d8c6c077e1 Added tag aarch64-shenandoah-jdk8u252-b07 for changeset 57a11875546a ! .hgtags Changeset: e8b56e0eaa7b Author: andrew Date: 2020-03-27 05:14 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/e8b56e0eaa7b Added tag jdk8u252-b08 for changeset 72a6d93679e5 ! .hgtags Changeset: 259807b2eafc Author: andrew Date: 2020-03-27 06:04 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/259807b2eafc Merge jdk8u252-b08 ! .hgtags Changeset: 83b10c54af07 Author: andrew Date: 2020-03-27 06:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/83b10c54af07 Added tag aarch64-shenandoah-jdk8u252-b08 for changeset 259807b2eafc ! .hgtags Changeset: f2715985987e Author: alvdavi Date: 2020-04-06 01:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/f2715985987e 8233410: Better Build Scripting Reviewed-by: andrew ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 343c4ea489d5 Author: alvdavi Date: 2020-02-20 14:05 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/343c4ea489d5 8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap Reviewed-by: andrew ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: acfa27ed408d Author: andrew Date: 2020-04-06 04:05 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/acfa27ed408d Added tag jdk8u252-b09 for changeset 343c4ea489d5 ! .hgtags Changeset: f7a3866daaa4 Author: andrew Date: 2020-04-06 05:09 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/f7a3866daaa4 Merge jdk8u252-b09 ! .hgtags ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh Changeset: 29d438c226b4 Author: andrew Date: 2020-04-06 05:11 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/29d438c226b4 Added tag aarch64-shenandoah-jdk8u252-b09 for changeset f7a3866daaa4 ! .hgtags Changeset: 7b46147869cb Author: shade Date: 2020-04-15 19:01 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/rev/7b46147869cb Merge ! .hgtags ! common/autoconf/generated-configure.sh From shade at redhat.com Wed Apr 15 17:41:20 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 15 Apr 2020 17:41:20 +0000 Subject: hg: shenandoah/jdk8/hotspot: 79 new changesets Message-ID: <202004151741.03FHfLYq021893@aojmv0008.oracle.com> Changeset: 345ee7a80453 Author: andrew Date: 2020-01-27 05:43 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/345ee7a80453 Merge jdk8u252-b01 ! .hgtags ! agent/src/os/linux/ps_core.c ! make/bsd/makefiles/vm.make ! make/linux/makefiles/vm.make ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 485a79ce8f73 Author: andrew Date: 2020-01-27 05:44 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/485a79ce8f73 Added tag aarch64-shenandoah-jdk8u252-b01 for changeset 345ee7a80453 ! .hgtags Changeset: 6e2f328e50c8 Author: andrew Date: 2020-02-04 03:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6e2f328e50c8 Merge jdk8u252-b02 ! .hgtags ! THIRD_PARTY_README ! make/windows/makefiles/compile.make ! make/windows/makefiles/vm.make ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/node.cpp Changeset: d2430fc175c2 Author: andrew Date: 2020-02-04 03:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d2430fc175c2 Added tag aarch64-shenandoah-jdk8u252-b02 for changeset 6e2f328e50c8 ! .hgtags Changeset: 5bd61b59deda Author: andrew Date: 2020-02-18 18:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5bd61b59deda Merge jdk8u252-b03 ! .hgtags - test/compiler/intrinsics/bmi/verifycode/AddnTestI.java - test/compiler/intrinsics/bmi/verifycode/AddnTestL.java Changeset: d9e09b29206a Author: andrew Date: 2020-02-18 18:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d9e09b29206a Added tag aarch64-shenandoah-jdk8u252-b03 for changeset 5bd61b59deda ! .hgtags Changeset: a936c608fe75 Author: andrew Date: 2020-02-23 04:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a936c608fe75 Merge jdk8u252-b04 ! .hgtags ! src/cpu/sparc/vm/c1_FrameMap_sparc.cpp ! src/cpu/sparc/vm/globals_sparc.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/zero/vm/globals_zero.hpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/synchronizer.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b3a6d2c29c63 Author: andrew Date: 2020-02-23 04:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b3a6d2c29c63 Added tag aarch64-shenandoah-jdk8u252-b04 for changeset a936c608fe75 ! .hgtags Changeset: 9606ff9039af Author: andrew Date: 2020-02-28 05:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9606ff9039af Merge jdk8u252-b05 ! .hgtags ! make/bsd/makefiles/gcc.make ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 6ead1e97a4ea Author: andrew Date: 2020-02-28 05:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6ead1e97a4ea Added tag aarch64-shenandoah-jdk8u252-b05 for changeset 9606ff9039af ! .hgtags Changeset: 68559d22b634 Author: roland Date: 2020-01-09 17:26 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/68559d22b634 [backport] 8237007: Shenandoah: assert(_base == Tuple) failure during C2 compilation Reviewed-by: thartmann, rkennke ! src/share/vm/opto/loopnode.cpp + test/gc/shenandoah/compiler/LRBRightAfterMemBar.java Changeset: b1fa7dcb0327 Author: shade Date: 2019-07-05 23:31 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b1fa7dcb0327 [backport] 8227327: Shenandoah: Faster and more parallel tests Reviewed-by: rkennke ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestHeapUncommit.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestRefprocSanity.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/TestStringDedup.java ! test/gc/shenandoah/TestStringDedupStress.java ! test/gc/shenandoah/TestStringInternCleanup.java ! test/gc/shenandoah/TestVerifyJCStress.java ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java Changeset: 0fd338502602 Author: shade Date: 2020-01-21 13:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0fd338502602 [backport] 8237570: Shenandoah: cleanup uses of allocation/free threshold in static heuristics Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/options/TestArgumentRanges.java Changeset: 6f8ac0de653a Author: shade Date: 2020-01-21 20:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6f8ac0de653a [backport] 8237586: Shenandoah: provide option to disable periodic GC Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! test/gc/shenandoah/TestPeriodicGC.java Changeset: 17e8f02e8f57 Author: zgu Date: 2020-01-13 13:53 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/17e8f02e8f57 [backport] 8237038: Shenandoah: Reduce thread pool size in TestEvilSyncBug.java test Reviewed-by: shade ! test/gc/shenandoah/TestEvilSyncBug.java Changeset: 8f1ba54ee8e9 Author: zgu Date: 2019-11-08 11:41 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8f1ba54ee8e9 [backport] 8233850: Shenandoah: Shenandoah thread count ergonomics should be container aware Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp Changeset: 1a1835e9c5ff Author: rkennke Date: 2020-01-10 12:42 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1a1835e9c5ff [backport] 8236851: Shenandoah: More details in Traversal GC event messages Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 0c5ebf7e9b67 Author: rkennke Date: 2019-12-17 18:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0c5ebf7e9b67 [backport] 8236106: [TESTBUG] Shenandoah: Make TestThreadFailure more resilient Reviewed-by: zgu ! test/gc/shenandoah/oom/TestThreadFailure.java Changeset: 79fed43bbfa6 Author: rkennke Date: 2019-12-11 16:43 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/79fed43bbfa6 [backport] 8235729: Shenandoah: Remove useless casting to non-constant Reviewed-by: roland ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 05e54680154b Author: shade Date: 2019-11-04 19:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/05e54680154b [backport] 8233520: Shenandoah: do not sleep when thread is attaching Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: c9c9c3a12557 Author: shade Date: 2019-11-01 16:16 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c9c9c3a12557 [backport] 8233387: Shenandoah: passive mode should disable pacing ergonomically Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp Changeset: 8c190b1b7295 Author: shade Date: 2020-02-10 14:41 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8c190b1b7295 Revert leftover changes in type.{cpp|hpp} ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 378a9e9578df Author: shade Date: 2020-02-10 17:04 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/378a9e9578df Rectify JDK-8191227 workaround for Shenandoah ! src/share/vm/code/debugInfo.cpp ! src/share/vm/code/debugInfo.hpp Changeset: 362e3c9e7c61 Author: zgu Date: 2019-10-15 22:22 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/362e3c9e7c61 [backport] 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms Reviewed-by: rkennke, adinn ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh Changeset: 6c6f387309ef Author: rkennke Date: 2019-04-04 21:29 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6c6f387309ef [backport] 8221848: Shenandoah: ArrayCopy post-barrier improvements Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 59f20d8c67a7 Author: rkennke Date: 2019-09-18 20:56 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/59f20d8c67a7 [backport] 8231086: Shenandoah: Stronger invariant for object-arraycopy Reviewed-by: shade ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.hpp ! src/cpu/aarch64/vm/stubGenerator_aarch64.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: d8f891aedf83 Author: shade Date: 2019-09-25 12:21 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d8f891aedf83 [backport] 8231410: Shenandoah: clone barrier should use base pointer Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp + test/gc/shenandoah/compiler/TestClone.java Changeset: 2f3e38ad18f8 Author: rkennke Date: 2019-09-25 12:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2f3e38ad18f8 [backport] 8231447: Shenandoah: Compilation-time regression after JDK-8231086 Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/prims/jvm.cpp Changeset: b3c034cecfe2 Author: rkennke Date: 2019-09-30 17:00 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b3c034cecfe2 [backport] 8231499: Shenandoah: compiler/arraycopy/TestDefaultMethodArrayCloneDeoptC2 fails Reviewed-by: shade, roland ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp Changeset: 47f730c94ab9 Author: shade Date: 2019-10-22 14:05 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/47f730c94ab9 [backport] 8232778: Shenandoah: SBSA::arraycopy_prologue checks wrong register Reviewed-by: rkennke ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp Changeset: 10f9960b52d6 Author: shade Date: 2019-09-30 22:39 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/10f9960b52d6 [backport] 8222766: Shenandoah: streamline post-LRB CAS barrier (x86) Reviewed-by: rkennke ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.hpp Changeset: af2530043788 Author: roland Date: 2019-12-06 16:21 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/af2530043788 [backport] 8235636: gc/shenandoah/compiler/TestUnsafeOffheapSwap.java fails after JDK-8226411 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: 428fea63a7ae Author: shade Date: 2020-02-25 21:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/428fea63a7ae Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject Reviewed-by: rkennke ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 530550e5df24 Author: rkennke Date: 2020-02-24 13:46 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/530550e5df24 [backport] 8221751: Shenandoah: Improve SATB enqueueing Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp Changeset: 006f1305bbf3 Author: rkennke Date: 2020-02-24 15:54 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/006f1305bbf3 [backport] 8224179: Shenandoah: CTW test failures with traversal GC Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: b0e783f94bab Author: rkennke Date: 2020-02-24 18:01 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b0e783f94bab [backport] 8223951: Shenandoah: Only need to update thread roots during final update refs Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 094c655cc519 Author: rkennke Date: 2020-02-24 17:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/094c655cc519 [backport] 8224495: Shenandoah: Do not rescan code roots in final mark pause if it is not degenerated GC Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 5553af6553c2 Author: rkennke Date: 2020-02-24 18:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5553af6553c2 [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 51d249139313 Author: rkennke Date: 2020-02-27 12:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/51d249139313 [backport] 8225341: Shenandoah: CM::update_thread_roots() needs to handle derived pointers Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 974c2a5397a0 Author: rkennke Date: 2019-08-13 16:05 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/974c2a5397a0 AArch64: Fix LRB use in LIRGenerator::do_UnsafeGetAndSetObject ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp Changeset: c96d8694dd1e Author: zgu Date: 2019-05-22 09:10 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c96d8694dd1e [backport] 8224525: Shenandoah: Eliminate shenandoah verifier's side-effects Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 31b527293b5f Author: rkennke Date: 2019-06-03 21:28 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/31b527293b5f [backport] 8225171: Remove leftovers in shenandoahBarrierSetC1.cpp Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp Changeset: 4b30807ec868 Author: rkennke Date: 2020-02-27 15:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/4b30807ec868 [backport] 8226586: Shenandoah: No need to pre-evacuate roots for degenerated GC Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: d9e2882d3f0a Author: rkennke Date: 2019-07-15 15:27 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d9e2882d3f0a [backport] 8227676: Shenandoah: More consistent naming of LRB entry points Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC2.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: 0056140b1daa Author: rkennke Date: 2019-07-18 13:16 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0056140b1daa [backport] 8228364: Shenandoah: Remove unused code from ShenandoahBarrierSetC1 Reviewed-by: shade ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.hpp Changeset: d845c1213174 Author: shade Date: 2019-08-19 19:58 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d845c1213174 [backport] 8229865: Use explicit #include debug.hpp for STATIC_ASSERT in gc/shenandoah/shenandoahUtils.cpp Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: e09ffdffec03 Author: zgu Date: 2019-09-23 07:45 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e09ffdffec03 [backport] 8231293: Shenandoah: Traversal should not revive dead weak roots Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: 71630756c297 Author: shade Date: 2019-10-15 19:38 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/71630756c297 [backport] 8232205: Shenandoah: missing "Update References" -> "Update Roots" tracing Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 905014d2b2a2 Author: shade Date: 2019-10-24 11:49 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/905014d2b2a2 [backport] 8232908: Shenandoah: compact heuristics has incorrect trigger "Free is lower than allocated recently" Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp Changeset: e5fa0011685a Author: jiefu Date: 2019-11-15 20:39 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e5fa0011685a [backport] 8234232: [TESTBUG] gc/shenandoah/jvmti/TestHeapDump.java fails with -Xcomp Reviewed-by: zgu ! test/gc/shenandoah/jvmti/TestHeapDump.java Changeset: 0d3beb625e5a Author: rkennke Date: 2020-02-28 20:50 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0d3beb625e5a 8233500: Shenandoah: Shenandoah load barrier should save registers before calling keep alive barrier on x86 Reviewed-by: rkennke ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: fc5b978c83e4 Author: rkennke Date: 2020-01-07 21:53 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/fc5b978c83e4 [backport] 8236732: Shenandoah: Stricter placement for oom-evac scopes Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.inline.hpp Changeset: 94480154d35c Author: rkennke Date: 2020-01-07 13:45 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/94480154d35c [backport] 8236181: C2: Remove useless step_over_gc_barrier() in int->bool conversion Reviewed-by: thartmann, roland ! src/share/vm/opto/cfgnode.cpp Changeset: 0f4ab5ec73a7 Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0f4ab5ec73a7 [backport] 8240070: Shenandoah: remove obsolete ShenandoahCommonGCStateLoads Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp - test/gc/shenandoah/compiler/TestCommonGCLoads.java Changeset: 364c0c74df65 Author: shade Date: 2020-02-24 18:30 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/364c0c74df65 [backport] 8239868: Shenandoah: ditch C2 node limit adjustments Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp Changeset: 9652b154d2cd Author: shade Date: 2020-02-25 12:35 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9652b154d2cd [backport] 8239904: Shenandoah: accumulated penalties should not be over 100% of capacity Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: 987a83a9970c Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/987a83a9970c [backport] 8240069: Shenandoah: turn more flags diagnostic Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/options/TestCodeCacheRootStyles.java Changeset: 8a663272a9a7 Author: shade Date: 2020-02-26 19:36 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8a663272a9a7 [backport] 8240076: Shenandoah: pacer should cover reset and preclean phases Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp Changeset: 082658680ab7 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/082658680ab7 [backport] 8240215: Shenandoah: remove ShenandoahAllocationTrace Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 7bed7e10d3ba Author: shade Date: 2020-03-03 08:05 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7bed7e10d3ba Fix tier2_gc_shenandoah group definition ! test/TEST.groups Changeset: a594fe530dd9 Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a594fe530dd9 [backport] 8240216: Shenandoah: remove ShenandoahTerminationTrace Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 8af4d432bf4c Author: shade Date: 2020-02-28 17:59 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8af4d432bf4c [backport] 8240217: Shenandoah: remove ShenandoahEvacAssist Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 5a667d30f1c2 Author: shade Date: 2020-03-04 19:23 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5a667d30f1c2 [backport] 8240534: Shenandoah: ditch debug safepoint timeout adjustment Reviewed-by: rkennke ! src/share/vm/runtime/arguments.cpp Changeset: 9070c58b0774 Author: sgehwolf Date: 2020-02-04 04:42 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9070c58b0774 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 Reviewed-by: aph ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/aarch64/vm/assembler_aarch64.hpp ! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ! src/cpu/aarch64/vm/c1_LIRGenerator_aarch64.cpp ! src/cpu/aarch64/vm/frame_aarch64.cpp ! src/cpu/aarch64/vm/interp_masm_aarch64.hpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/vm_version_aarch64.cpp ! src/os_cpu/linux_aarch64/vm/copy_linux_aarch64.s ! src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp Changeset: d17814ea88e3 Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d17814ea88e3 Added tag jdk8u252-b06 for changeset b4fd7e078c54 ! .hgtags Changeset: 28076b7ca481 Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/28076b7ca481 Merge jdk8u252-b06 ! .hgtags Changeset: 6a9f0a91d70d Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6a9f0a91d70d Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 28076b7ca481 ! .hgtags Changeset: ed3010718a77 Author: andrew Date: 2020-03-17 09:10 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ed3010718a77 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 5a667d30f1c2 ! .hgtags Changeset: 00eaaa430a54 Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/00eaaa430a54 Added tag jdk8u252-b07 for changeset d17814ea88e3 ! .hgtags Changeset: 9f9d7938db16 Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9f9d7938db16 Merge jdk8u252-b07 ! .hgtags Changeset: 032c004c0b23 Author: andrew Date: 2020-03-23 21:35 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/032c004c0b23 Added tag aarch64-shenandoah-jdk8u252-b07 for changeset 9f9d7938db16 ! .hgtags Changeset: 8f2780b3e4fa Author: aph Date: 2020-03-25 03:20 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8f2780b3e4fa 8241296: Segfault in JNIHandleBlock::oops_do() Reviewed-by: andrew ! src/share/vm/runtime/thread.cpp Changeset: 095e60e7fc8c Author: andrew Date: 2020-03-27 05:14 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/095e60e7fc8c Added tag jdk8u252-b08 for changeset 8f2780b3e4fa ! .hgtags Changeset: 2668bab1293c Author: andrew Date: 2020-03-27 06:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2668bab1293c Merge jdk8u252-b08 ! .hgtags ! src/share/vm/runtime/thread.cpp Changeset: ac1d2acb1e7d Author: andrew Date: 2020-03-27 06:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ac1d2acb1e7d Added tag aarch64-shenandoah-jdk8u252-b08 for changeset 2668bab1293c ! .hgtags Changeset: 8915b1e17904 Author: andrew Date: 2020-04-06 04:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8915b1e17904 Added tag jdk8u252-b09 for changeset 095e60e7fc8c ! .hgtags Changeset: e4e81ae21643 Author: andrew Date: 2020-04-06 05:09 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e4e81ae21643 Merge jdk8u252-b09 ! .hgtags Changeset: 6d1cfa6cdbab Author: andrew Date: 2020-04-06 05:11 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6d1cfa6cdbab Added tag aarch64-shenandoah-jdk8u252-b09 for changeset e4e81ae21643 ! .hgtags Changeset: 2db98309823b Author: shade Date: 2020-04-15 19:23 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2db98309823b Merge ! .hgtags ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/code/debugInfo.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp From shade at redhat.com Wed Apr 15 17:41:21 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 15 Apr 2020 17:41:21 +0000 Subject: hg: shenandoah/jdk8/corba: 24 new changesets Message-ID: <202004151741.03FHfLQn021906@aojmv0008.oracle.com> Changeset: 6acc56b989af Author: andrew Date: 2020-01-27 05:42 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/6acc56b989af Merge jdk8u252-b01 ! .hgtags Changeset: 150820ef49b1 Author: andrew Date: 2020-01-27 05:43 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/150820ef49b1 Added tag aarch64-shenandoah-jdk8u252-b01 for changeset 6acc56b989af ! .hgtags Changeset: 871a8b0d5f8b Author: andrew Date: 2020-02-04 03:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/871a8b0d5f8b Merge jdk8u252-b02 ! .hgtags ! THIRD_PARTY_README Changeset: 017a48c6274b Author: andrew Date: 2020-02-04 03:32 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/017a48c6274b Added tag aarch64-shenandoah-jdk8u252-b02 for changeset 871a8b0d5f8b ! .hgtags Changeset: f5224c4ec61c Author: andrew Date: 2020-02-18 18:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/f5224c4ec61c Merge jdk8u252-b03 ! .hgtags Changeset: 2cd14812e508 Author: andrew Date: 2020-02-18 18:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2cd14812e508 Added tag aarch64-shenandoah-jdk8u252-b03 for changeset f5224c4ec61c ! .hgtags Changeset: 47bd9f5e99e5 Author: andrew Date: 2020-02-23 04:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/47bd9f5e99e5 Merge jdk8u252-b04 ! .hgtags Changeset: a63a6da8dc3b Author: andrew Date: 2020-02-23 04:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a63a6da8dc3b Added tag aarch64-shenandoah-jdk8u252-b04 for changeset 47bd9f5e99e5 ! .hgtags Changeset: 82edc7271f6b Author: andrew Date: 2020-02-28 05:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/82edc7271f6b Merge jdk8u252-b05 ! .hgtags Changeset: b2221013f173 Author: andrew Date: 2020-02-28 05:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/b2221013f173 Added tag aarch64-shenandoah-jdk8u252-b05 for changeset 82edc7271f6b ! .hgtags Changeset: ee99eeee44ad Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/ee99eeee44ad Added tag jdk8u252-b06 for changeset ff8c2e73d641 ! .hgtags Changeset: 5dc906baed1d Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/5dc906baed1d Merge jdk8u252-b06 ! .hgtags Changeset: 71af329f3cfb Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/71af329f3cfb Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 5dc906baed1d ! .hgtags Changeset: 72d73e9bee2d Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/72d73e9bee2d Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 82edc7271f6b ! .hgtags Changeset: 63738d15bb7f Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/63738d15bb7f Added tag jdk8u252-b07 for changeset ee99eeee44ad ! .hgtags Changeset: cb7514c874ee Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/cb7514c874ee Merge jdk8u252-b07 ! .hgtags Changeset: 8bb2bcdd74ab Author: andrew Date: 2020-03-23 21:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/8bb2bcdd74ab Added tag aarch64-shenandoah-jdk8u252-b07 for changeset cb7514c874ee ! .hgtags Changeset: 9340b3be1b47 Author: andrew Date: 2020-03-27 05:14 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/9340b3be1b47 Added tag jdk8u252-b08 for changeset 63738d15bb7f ! .hgtags Changeset: 81baca88f8b3 Author: andrew Date: 2020-03-27 06:04 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/81baca88f8b3 Merge jdk8u252-b08 ! .hgtags Changeset: 8fad3e09ebcf Author: andrew Date: 2020-03-27 06:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/8fad3e09ebcf Added tag aarch64-shenandoah-jdk8u252-b08 for changeset 81baca88f8b3 ! .hgtags Changeset: 8dc6b97b3bf4 Author: andrew Date: 2020-04-06 04:05 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/8dc6b97b3bf4 Added tag jdk8u252-b09 for changeset 9340b3be1b47 ! .hgtags Changeset: 32e950c1f4c3 Author: andrew Date: 2020-04-06 05:09 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/32e950c1f4c3 Merge jdk8u252-b09 ! .hgtags Changeset: d435f2d0b558 Author: andrew Date: 2020-04-06 05:11 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/d435f2d0b558 Added tag aarch64-shenandoah-jdk8u252-b09 for changeset 32e950c1f4c3 ! .hgtags Changeset: 53917fbc5224 Author: shade Date: 2020-04-15 19:01 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/53917fbc5224 Merge ! .hgtags From shade at redhat.com Wed Apr 15 17:41:26 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 15 Apr 2020 17:41:26 +0000 Subject: hg: shenandoah/jdk8/nashorn: 26 new changesets Message-ID: <202004151741.03FHfRHL021972@aojmv0008.oracle.com> Changeset: a1111f50cbc9 Author: andrew Date: 2020-01-27 05:43 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/a1111f50cbc9 Merge jdk8u252-b01 ! .hgtags Changeset: 964c19d04c72 Author: andrew Date: 2020-01-27 05:44 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/964c19d04c72 Added tag aarch64-shenandoah-jdk8u252-b01 for changeset a1111f50cbc9 ! .hgtags Changeset: c92d5013f8e2 Author: andrew Date: 2020-02-04 03:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/c92d5013f8e2 Merge jdk8u252-b02 ! .hgtags ! THIRD_PARTY_README Changeset: b555d2a5b9e9 Author: andrew Date: 2020-02-04 03:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/b555d2a5b9e9 Added tag aarch64-shenandoah-jdk8u252-b02 for changeset c92d5013f8e2 ! .hgtags Changeset: edd528894190 Author: andrew Date: 2020-02-18 18:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/edd528894190 Merge jdk8u252-b03 ! .hgtags Changeset: b0efb17664bc Author: andrew Date: 2020-02-18 18:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/b0efb17664bc Added tag aarch64-shenandoah-jdk8u252-b03 for changeset edd528894190 ! .hgtags Changeset: aa702657b100 Author: andrew Date: 2020-02-23 04:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/aa702657b100 Merge jdk8u252-b04 ! .hgtags Changeset: 13ff4a6bc394 Author: andrew Date: 2020-02-23 04:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/13ff4a6bc394 Added tag aarch64-shenandoah-jdk8u252-b04 for changeset aa702657b100 ! .hgtags Changeset: 3d4116b4ed37 Author: andrew Date: 2020-02-28 05:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/3d4116b4ed37 Merge jdk8u252-b05 ! .hgtags Changeset: 584147582329 Author: andrew Date: 2020-02-28 05:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/584147582329 Added tag aarch64-shenandoah-jdk8u252-b05 for changeset 3d4116b4ed37 ! .hgtags Changeset: 0666ec7fe2b4 Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/0666ec7fe2b4 Added tag jdk8u252-b06 for changeset b988f627520c ! .hgtags Changeset: ac6ae7fe2e41 Author: andrew Date: 2020-03-16 02:20 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/ac6ae7fe2e41 Merge jdk8u252-b06 ! .hgtags Changeset: f071e9766167 Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/f071e9766167 Added tag aarch64-shenandoah-jdk8u252-b06 for changeset ac6ae7fe2e41 ! .hgtags Changeset: 0607dc89dbb5 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/0607dc89dbb5 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 3d4116b4ed37 ! .hgtags Changeset: 95d61d0f326b Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/95d61d0f326b Added tag jdk8u252-b07 for changeset 0666ec7fe2b4 ! .hgtags Changeset: cbbbe5b13332 Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/cbbbe5b13332 Merge jdk8u252-b07 ! .hgtags Changeset: 62c5e270b91d Author: andrew Date: 2020-03-23 21:35 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/62c5e270b91d Added tag aarch64-shenandoah-jdk8u252-b07 for changeset cbbbe5b13332 ! .hgtags Changeset: 5fc91c4182b0 Author: andrew Date: 2020-03-27 05:14 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/5fc91c4182b0 Added tag jdk8u252-b08 for changeset 95d61d0f326b ! .hgtags Changeset: d9fdfa71788f Author: andrew Date: 2020-03-27 06:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/d9fdfa71788f Merge jdk8u252-b08 ! .hgtags Changeset: ebb6de4f5fb3 Author: andrew Date: 2020-03-27 06:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/ebb6de4f5fb3 Added tag aarch64-shenandoah-jdk8u252-b08 for changeset d9fdfa71788f ! .hgtags Changeset: 2e03a91e04b9 Author: hannesw Date: 2019-11-06 17:13 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/2e03a91e04b9 8223898: Forward references to Nashorn Reviewed-by: sundar, mschoene, rhalade ! src/jdk/nashorn/internal/runtime/regexp/RegExpScanner.java Changeset: 2f5ad880fd33 Author: hannesw Date: 2019-11-15 19:10 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/2f5ad880fd33 8223904: Improve Nashorn matching Reviewed-by: jlaskey, sundar, mschoene, rhalade ! src/jdk/nashorn/internal/runtime/regexp/joni/Parser.java ! src/jdk/nashorn/internal/runtime/regexp/joni/ast/StringNode.java Changeset: a805f6863c1c Author: andrew Date: 2020-04-06 04:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/a805f6863c1c Added tag jdk8u252-b09 for changeset 2f5ad880fd33 ! .hgtags Changeset: 2167f830e117 Author: andrew Date: 2020-04-06 05:09 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/2167f830e117 Merge jdk8u252-b09 ! .hgtags Changeset: 6d92226e5be1 Author: andrew Date: 2020-04-06 05:11 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/6d92226e5be1 Added tag aarch64-shenandoah-jdk8u252-b09 for changeset 2167f830e117 ! .hgtags Changeset: ef9735fc2b0e Author: shade Date: 2020-04-15 19:01 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/nashorn/rev/ef9735fc2b0e Merge ! .hgtags From shade at redhat.com Wed Apr 15 17:42:25 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 15 Apr 2020 17:42:25 +0000 Subject: hg: shenandoah/jdk8/langtools: 24 new changesets Message-ID: <202004151742.03FHgPjw022389@aojmv0008.oracle.com> Changeset: 32046c7f0ae5 Author: andrew Date: 2020-01-27 05:43 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/32046c7f0ae5 Merge jdk8u252-b01 ! .hgtags Changeset: 4fc05173a76a Author: andrew Date: 2020-01-27 05:44 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/4fc05173a76a Added tag aarch64-shenandoah-jdk8u252-b01 for changeset 32046c7f0ae5 ! .hgtags Changeset: 9d53b819057e Author: andrew Date: 2020-02-04 03:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/9d53b819057e Merge jdk8u252-b02 ! .hgtags ! THIRD_PARTY_README Changeset: 37ae05fd2c96 Author: andrew Date: 2020-02-04 03:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/37ae05fd2c96 Added tag aarch64-shenandoah-jdk8u252-b02 for changeset 9d53b819057e ! .hgtags Changeset: 59758fd1eebe Author: andrew Date: 2020-02-18 18:52 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/59758fd1eebe Merge jdk8u252-b03 ! .hgtags Changeset: ff8fb4e318fc Author: andrew Date: 2020-02-18 18:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/ff8fb4e318fc Added tag aarch64-shenandoah-jdk8u252-b03 for changeset 59758fd1eebe ! .hgtags Changeset: 5610c2ca5b25 Author: andrew Date: 2020-02-23 04:53 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/5610c2ca5b25 Merge jdk8u252-b04 ! .hgtags Changeset: 87d1e7f4bf2e Author: andrew Date: 2020-02-23 04:54 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/87d1e7f4bf2e Added tag aarch64-shenandoah-jdk8u252-b04 for changeset 5610c2ca5b25 ! .hgtags Changeset: 5127eea57961 Author: andrew Date: 2020-02-28 05:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/5127eea57961 Merge jdk8u252-b05 ! .hgtags Changeset: 9d934eb4ed33 Author: andrew Date: 2020-02-28 05:29 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/9d934eb4ed33 Added tag aarch64-shenandoah-jdk8u252-b05 for changeset 5127eea57961 ! .hgtags Changeset: 8ce7c29ca85c Author: andrew Date: 2020-03-16 00:28 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/8ce7c29ca85c Added tag jdk8u252-b06 for changeset 4010269cf496 ! .hgtags Changeset: 5091dabc613a Author: andrew Date: 2020-03-16 02:19 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/5091dabc613a Merge jdk8u252-b06 ! .hgtags Changeset: 722684ae14ba Author: andrew Date: 2020-03-16 02:34 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/722684ae14ba Added tag aarch64-shenandoah-jdk8u252-b06 for changeset 5091dabc613a ! .hgtags Changeset: 43dc4647f6d2 Author: andrew Date: 2020-03-17 09:11 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/43dc4647f6d2 Added tag aarch64-shenandoah-jdk8u252-b05-shenandoah-merge-2020-03-06 for changeset 5127eea57961 ! .hgtags Changeset: c56eceecec71 Author: andrew Date: 2020-03-20 14:26 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/c56eceecec71 Added tag jdk8u252-b07 for changeset 8ce7c29ca85c ! .hgtags Changeset: 3a49c7bb5630 Author: andrew Date: 2020-03-23 21:33 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/3a49c7bb5630 Merge jdk8u252-b07 ! .hgtags Changeset: a7579f73db1d Author: andrew Date: 2020-03-23 21:35 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a7579f73db1d Added tag aarch64-shenandoah-jdk8u252-b07 for changeset 3a49c7bb5630 ! .hgtags Changeset: 01036da3155c Author: andrew Date: 2020-03-27 05:14 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/01036da3155c Added tag jdk8u252-b08 for changeset c56eceecec71 ! .hgtags Changeset: 4cb8441f6bf5 Author: andrew Date: 2020-03-27 06:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/4cb8441f6bf5 Merge jdk8u252-b08 ! .hgtags Changeset: a6ed6d713d38 Author: andrew Date: 2020-03-27 06:05 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/a6ed6d713d38 Added tag aarch64-shenandoah-jdk8u252-b08 for changeset 4cb8441f6bf5 ! .hgtags Changeset: 5177983e7b78 Author: andrew Date: 2020-04-06 04:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/5177983e7b78 Added tag jdk8u252-b09 for changeset 01036da3155c ! .hgtags Changeset: 805c9d0d623f Author: andrew Date: 2020-04-06 05:09 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/805c9d0d623f Merge jdk8u252-b09 ! .hgtags Changeset: 22d2bfae6afe Author: andrew Date: 2020-04-06 05:11 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/22d2bfae6afe Added tag aarch64-shenandoah-jdk8u252-b09 for changeset 805c9d0d623f ! .hgtags Changeset: 826b555ac375 Author: shade Date: 2020-04-15 19:42 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/826b555ac375 Merge ! .hgtags From shade at redhat.com Wed Apr 15 18:07:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Apr 2020 20:07:44 +0200 Subject: shenandoah/jdk11 is open for backports to 11.0.8 Message-ID: <279be990-6f1c-7e75-d088-9b256e5c5b08@redhat.com> $subject, you can RFR stuff to go in there. -- Thanks, -Aleksey P.S. shenandoah/jdk8 is still closed, until we have at least one build and repository metadata updates From zgu at redhat.com Wed Apr 15 20:16:35 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 15 Apr 2020 16:16:35 -0400 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 Message-ID: <0b1e6962-6ea0-0273-3a9b-953ad57c0506@redhat.com> http://cr.openjdk.java.net/~zgu/sh-jdk11u-20200415/webrev.00/ Backport from jdk to shenandoah-jdk11u [backport] 8237396: JvmtiTagMap::weak_oops_do() should not trigger barriers [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR [backport] 8240917: Shenandoah: Avoid scanning thread code roots twice in all root scanner [backport] 8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier [backport] 8241900: Loop unswitching may cause dependence on null check to be lost [backport] 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Wed Apr 15 20:40:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Apr 2020 22:40:08 +0200 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 In-Reply-To: <0b1e6962-6ea0-0273-3a9b-953ad57c0506@redhat.com> References: <0b1e6962-6ea0-0273-3a9b-953ad57c0506@redhat.com> Message-ID: <91d04af7-98bd-e96a-fbd0-a0f81389b1c0@redhat.com> On 4/15/20 10:16 PM, Zhengyu Gu wrote: > http://cr.openjdk.java.net/~zgu/sh-jdk11u-20200415/webrev.00/ > > Backport from jdk to shenandoah-jdk11u > > [backport] 8237396: JvmtiTagMap::weak_oops_do() should not trigger > barriers This one would come through 11.0.8 integration, we should not backport it ourselves. > [backport] 8241900: Loop unswitching may cause dependence on null check > to be lost This one should be backported through upstream 11u, we should not backport it ourselves. Others look fine. -- Thanks, -Aleksey From zgu at redhat.com Wed Apr 15 20:45:43 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 15 Apr 2020 16:45:43 -0400 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 In-Reply-To: <91d04af7-98bd-e96a-fbd0-a0f81389b1c0@redhat.com> References: <0b1e6962-6ea0-0273-3a9b-953ad57c0506@redhat.com> <91d04af7-98bd-e96a-fbd0-a0f81389b1c0@redhat.com> Message-ID: <5e25849b-dab6-a0ec-ddab-77ba5dbfc334@redhat.com> On 4/15/20 4:40 PM, Aleksey Shipilev wrote: > On 4/15/20 10:16 PM, Zhengyu Gu wrote: >> http://cr.openjdk.java.net/~zgu/sh-jdk11u-20200415/webrev.00/ >> >> Backport from jdk to shenandoah-jdk11u >> >> [backport] 8237396: JvmtiTagMap::weak_oops_do() should not trigger >> barriers > > This one would come through 11.0.8 integration, we should not backport it ourselves. > >> [backport] 8241900: Loop unswitching may cause dependence on null check >> to be lost > > This one should be backported through upstream 11u, we should not backport it ourselves. Oh, okay. -Zhengyu > > Others look fine. > From rkennke at redhat.com Thu Apr 16 09:43:45 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 16 Apr 2020 11:43:45 +0200 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 In-Reply-To: References: Message-ID: <3b42fe44-5e47-700d-f897-0463b0fa3f97@redhat.com> Why haven't you included the I-U mode addition? Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200415/webrev.01/ > > Backport window for sh/jdk11 is about to open. This bulk backports the significant bunch of > outstanding work. Don't be scared about the number of them: those are either bulk removals, or a > series of simple changes. That said, please review carefully. > > Changes: > [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings > [backport] 8240315: Shenandoah: Rename ShLBN::get_barrier_strength() > [backport] 8220503: Move ShenandoahTerminatorTerminator::should_exit_termination out of header > [backport] 8240749: Shenandoah: refactor ShenandoahUtils > [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker > [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts > [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles > [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks > [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation > [backport] 8240873: Shenandoah: Short-cut arraycopy barriers > [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently > [backport] 8241534: Shenandoah: region status should include update watermark > [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 > [backport] 8241351: Shenandoah: fragmentation metrics overhaul > [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" > [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation > [backport] 8241520: Shenandoah: simplify region sequence numbers handling > [backport] 8241583: Shenandoah: turn heap lock asserts into macros > [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace > [backport] 8241673: Shenandoah: refactor anti-false-sharing padding > [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved > [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() > [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap > [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods > [backport] 8241838: Shenandoah: no need to trash cset during final mark > [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion > [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number > [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number > [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines > [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() > [backport] 8241093: Shenandoah: editorial changes in flag descriptions > [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it > [backport] 8241985: Shenandoah: simplify collectable garbage logging > [backport] 8241983: Shenandoah: simplify FreeSet logging > [backport] 8242040: Shenandoah: print allocation failure type > [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target > [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold > [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag > [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters > [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged > [backport] 8242082: Shenandoah: Purge Traversal mode > [backport] 8242107: Shenandoah: Fix aarch64 build after JDK-8242082 > [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared > [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses > [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc > [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly > [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset > [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set > [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods > > Testing: hotspot_gc_shenandoah {fastdebug, release} > > From shade at redhat.com Thu Apr 16 09:48:18 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Apr 2020 11:48:18 +0200 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 In-Reply-To: <3b42fe44-5e47-700d-f897-0463b0fa3f97@redhat.com> References: <3b42fe44-5e47-700d-f897-0463b0fa3f97@redhat.com> Message-ID: <6e32746b-eae3-ae3b-32fc-c889a43fd40d@redhat.com> On 4/16/20 11:43 AM, Roman Kennke wrote: > Why haven't you included the I-U mode addition? Because this batch is already quite large and the rest requires fiddling with other arches as well. Left these out: 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry 8242301: Shenandoah: Inline LRB runtime call 8242273: Shenandoah: accept either SATB or IU barriers, but not both 8242271: Shenandoah: add test to verify GC mode unlock 8242054: Shenandoah: New incremental-update mode 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name 8242130: Shenandoah: Simplify arraycopy-barrier dispatching 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 16 09:51:47 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 16 Apr 2020 11:51:47 +0200 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 In-Reply-To: <6e32746b-eae3-ae3b-32fc-c889a43fd40d@redhat.com> References: <3b42fe44-5e47-700d-f897-0463b0fa3f97@redhat.com> <6e32746b-eae3-ae3b-32fc-c889a43fd40d@redhat.com> Message-ID: <375aaffd-994d-9460-04d9-8579ef2e038c@redhat.com> Ok then. The patch that you posted looks good. The remaining ones are for me, I assume? :-) Roman > On 4/16/20 11:43 AM, Roman Kennke wrote: >> Why haven't you included the I-U mode addition? > > Because this batch is already quite large and the rest requires fiddling with other arches as well. > > Left these out: > 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry > 8242301: Shenandoah: Inline LRB runtime call > 8242273: Shenandoah: accept either SATB or IU barriers, but not both > 8242271: Shenandoah: add test to verify GC mode unlock > 8242054: Shenandoah: New incremental-update mode > 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name > 8242130: Shenandoah: Simplify arraycopy-barrier dispatching > 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier > 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with > java/util/Collections/FindSubList.java > From aleksey.shipilev at gmail.com Thu Apr 16 09:57:22 2020 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 16 Apr 2020 11:57:22 +0200 Subject: Used heap metric In-Reply-To: References: Message-ID: <8dfbd4d2-455a-7d64-7893-5cbdf5471798@gmail.com> Hi, (this was stuck somewhere in moderator queue) On 4/16/20 12:55 AM, Kamil Konior wrote: > I would appreciate any confirmation that an issue which i am facing?may be caused by shenandoah. The > problem is that used heap jmx metric, shows twice as much as it should be. > > using jmap -heap > Heap Usage: > Shenandoah Heap: > ? ?regions ? = 2944 > ? ?capacity ?= 49392123904 (47104.0MB) > ? ?used ? ? ?= 38895279960 (37093.429527282715MB) > ? ?committed = 49392123904 (47104.0MB) > > Where jmap -histo , shows?19102819072 (?18217.8679 MB ) and from my calculations it is correct > number. Rarely even used heap metric show?correct numbers, so sometimes It works properly. I don't think this is Shenandoah-specific. "used" = memory taken by Java heap, including everything: both live objects and not-yet-reclaimed garbage. It would be larger than the actual live data available, which I presume what jmap -histo counts. If you do more GCs, especially after ShenandoahGarbageThreshold went down [1], or you enabled "compact", those should eventually match up. Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8242042 [2] -XX:ShenandoahGCHeuristics=compact From shade at redhat.com Thu Apr 16 10:02:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Apr 2020 12:02:48 +0200 Subject: [11] RFR: 2020-04-15, Bulk backports to sh/jdk11 In-Reply-To: <375aaffd-994d-9460-04d9-8579ef2e038c@redhat.com> References: <3b42fe44-5e47-700d-f897-0463b0fa3f97@redhat.com> <6e32746b-eae3-ae3b-32fc-c889a43fd40d@redhat.com> <375aaffd-994d-9460-04d9-8579ef2e038c@redhat.com> Message-ID: <5b254b36-c2ec-5af6-3699-337ab3b4e73d@redhat.com> On 4/16/20 11:51 AM, Roman Kennke wrote: > The patch that you posted looks good. Thanks, pushed. > The remaining ones are for me, I assume? :-) Yes, pretty much ;) -- Thanks, -Aleksey From shade at redhat.com Thu Apr 16 09:59:47 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 16 Apr 2020 09:59:47 +0000 Subject: hg: shenandoah/jdk11: 13 new changesets Message-ID: <202004160959.03G9xnpL006384@aojmv0008.oracle.com> Changeset: efb683bc7cc2 Author: shade Date: 2020-03-06 17:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/efb683bc7cc2 [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahTimingTracker.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: 10ada2bd6441 Author: rkennke Date: 2020-03-06 21:51 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/10ada2bd6441 [backport] 8240315: Shenandoah: Rename ShLBN::get_barrier_strength() Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp Changeset: af07a80e381a Author: rkennke Date: 2020-03-09 12:29 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/af07a80e381a [backport] 8220503: Move ShenandoahTerminatorTerminator::should_exit_termination out of header Reviewed-by: rkennke Contributed-by: adityam at microsoft.com ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp Changeset: cfa4136c6fa7 Author: shade Date: 2020-03-09 22:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/cfa4136c6fa7 [backport] 8240749: Shenandoah: refactor ShenandoahUtils Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: 66f434ad20c0 Author: shade Date: 2020-03-09 22:41 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/66f434ad20c0 [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker Reviewed-by: rkennke - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.cpp - src/hotspot/share/gc/shenandoah/shenandoahAllocTracker.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp Changeset: ec859ee39571 Author: shade Date: 2020-01-24 21:11 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ec859ee39571 [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts [backport] 8237821: Shenandoah: build broken after JDK-8237637 (Remove dubious type conversions from oop) Reviewed-by: shade Contributed-by: Aditya Mandaleeka ! src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegionSet.inline.hpp Changeset: c4ed95936333 Author: shade Date: 2020-03-11 14:17 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c4ed95936333 [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! src/hotspot/share/runtime/vmOperations.hpp ! test/hotspot/jtreg/gc/shenandoah/TestStringDedupStress.java Changeset: ff52f98dc982 Author: zgu Date: 2020-03-12 09:25 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ff52f98dc982 [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: 1ff5e04d534e Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/1ff5e04d534e [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp Changeset: 8745a77db931 Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/8745a77db931 [backport] 8240873: Shenandoah: Short-cut arraycopy barriers Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahTraversalGC.cpp Changeset: 29d7b22c1ee6 Author: rkennke Date: 2020-03-17 11:49 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/29d7b22c1ee6 [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp Changeset: 481ea44f73cf Author: shade Date: 2020-03-24 18:46 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/481ea44f73cf [backport] 8241534: Shenandoah: region status should include update watermark Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp Changeset: 94be5af16101 Author: shade Date: 2020-03-12 18:50 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/94be5af16101 [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp From shade at redhat.com Thu Apr 16 10:00:37 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 16 Apr 2020 10:00:37 +0000 Subject: hg: shenandoah/jdk11: 12 new changesets Message-ID: <202004161000.03GA0cnn006754@aojmv0008.oracle.com> Changeset: 309c92863181 Author: shade Date: 2020-03-31 08:42 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/309c92863181 [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp ! src/hotspot/share/gc/shenandoah/shenandoahPadding.hpp Changeset: 8decb2b10934 Author: shade Date: 2020-04-07 14:32 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/8decb2b10934 [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() Reviewed-by: rkennke, stuefe ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: fdddcf9c27ab Author: shade Date: 2020-03-18 06:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/fdddcf9c27ab [backport] 8241093: Shenandoah: editorial changes in flag descriptions Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 24f8e0894e6e Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/24f8e0894e6e [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 6368b2577e7e Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/6368b2577e7e [backport] 8241985: Shenandoah: simplify collectable garbage logging Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeuristics.cpp Changeset: 96074cfc7ccb Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/96074cfc7ccb [backport] 8241983: Shenandoah: simplify FreeSet logging Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Changeset: 060f420b8aa6 Author: shade Date: 2020-04-02 20:10 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/060f420b8aa6 [backport] 8242040: Shenandoah: print allocation failure type Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahAllocRequest.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 7094c5d46c05 Author: shade Date: 2020-04-02 20:11 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/7094c5d46c05 [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp Changeset: 12cf2a305c04 Author: shade Date: 2020-04-03 11:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/12cf2a305c04 [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 6118c24d8338 Author: shade Date: 2020-04-03 11:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/6118c24d8338 [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp ! test/hotspot/jtreg/gc/TestHumongousReferenceObject.java ! test/hotspot/jtreg/gc/shenandoah/options/TestRegionSizeArgs.java Changeset: 9c797e1f2344 Author: shade Date: 2020-04-03 13:58 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/9c797e1f2344 [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 1aa776b8224b Author: shade Date: 2020-04-03 13:58 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/1aa776b8224b [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp From zgu at redhat.com Thu Apr 16 14:22:31 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 16 Apr 2020 14:22:31 +0000 Subject: hg: shenandoah/jdk11: [backport] 8240917: Shenandoah: Avoid scanning thread code roots twice in all root scanner Message-ID: <202004161422.03GEMWw2008580@aojmv0008.oracle.com> Changeset: be750117a860 Author: zgu Date: 2020-03-12 13:08 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/be750117a860 [backport] 8240917: Shenandoah: Avoid scanning thread code roots twice in all root scanner Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp From zgu at redhat.com Thu Apr 16 14:22:08 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 16 Apr 2020 14:22:08 +0000 Subject: hg: shenandoah/jdk11: [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Message-ID: <202004161422.03GEM9jv007789@aojmv0008.oracle.com> Changeset: 21da10c3ca3b Author: zgu Date: 2020-02-26 15:32 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/21da10c3ca3b [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahForwarding.hpp ! src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp From zgu at redhat.com Thu Apr 16 14:22:53 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 16 Apr 2020 14:22:53 +0000 Subject: hg: shenandoah/jdk11: [backport] 8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier Message-ID: <202004161422.03GEMsSW008821@aojmv0008.oracle.com> Changeset: 6b15a1250350 Author: zgu Date: 2020-03-28 11:00 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/6b15a1250350 [backport] 8241765: Shenandoah: AARCH64 need to save/restore call clobbered registers before calling keepalive barrier Reviewed-by: rkennke, smonteith, aph ! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp From zgu at redhat.com Thu Apr 16 18:11:26 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Apr 2020 14:11:26 -0400 Subject: [15] RFR(T) 8243008: Shenandoah: TestVolatilesShenandoah test failed on aarch64 Message-ID: <3a701e5e-d6f9-0be8-94f8-a0110a26322b@redhat.com> compiler/c2/aarch64/TestVolatilesShenandoah.java test failed on aarch64, because Shenandoah no long has traversal mode, but new incremental-update mode. Bug: https://bugs.openjdk.java.net/browse/JDK-8243008 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243008/webrev.00/ Thanks, -Zhengyu From shade at redhat.com Thu Apr 16 18:16:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Apr 2020 20:16:11 +0200 Subject: [aarch64-port-dev ] [15] RFR(T) 8243008: Shenandoah: TestVolatilesShenandoah test failed on aarch64 In-Reply-To: <3a701e5e-d6f9-0be8-94f8-a0110a26322b@redhat.com> References: <3a701e5e-d6f9-0be8-94f8-a0110a26322b@redhat.com> Message-ID: <386be87e-d971-6bd4-aa36-5cef4aeb5814@redhat.com> On 4/16/20 8:11 PM, Zhengyu Gu wrote: > compiler/c2/aarch64/TestVolatilesShenandoah.java test failed on aarch64, > because Shenandoah no long has traversal mode, but new > incremental-update mode. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243008 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243008/webrev.00/ Right. Looks good. -- Thanks, -Aleksey From shade at redhat.com Mon Apr 20 10:07:13 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Apr 2020 12:07:13 +0200 Subject: [11] RFR, 2020-04-20, Bulk backports to sh/jdk11 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200420/webrev.01/ This backports a few leftovers that passed testing recently: [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods [backport] 8242353: Shenandoah: micro-optimize region liveness handling [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 20 11:09:10 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Apr 2020 13:09:10 +0200 Subject: [11] RFR, 2020-04-20, Bulk backports to sh/jdk11 In-Reply-To: References: Message-ID: <6de09bcb-922a-ee81-8503-56ed90d64347@redhat.com> Looks good, thank you! Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200420/webrev.01/ > > This backports a few leftovers that passed testing recently: > > [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods > [backport] 8242353: Shenandoah: micro-optimize region liveness handling > [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache > [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah > [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread > [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From rkennke at redhat.com Mon Apr 20 13:10:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Apr 2020 15:10:31 +0200 Subject: RFR: Bulk backports to sh/jdk11 2020-04-20 Message-ID: This backports the following changes from jdk/jdk: 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry 8242301: Shenandoah: Inline LRB runtime call 8242273: Shenandoah: accept either SATB or IU barriers, but not both 8242271: Shenandoah: add test to verify GC mode unlock 8242054: Shenandoah: New incremental-update mode 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name 8242130: Shenandoah: Simplify arraycopy-barrier dispatching 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-04-20/webrev.00/ Testing: hotspot_gc_shenandoah Ok? Roman From shade at redhat.com Mon Apr 20 13:19:20 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Apr 2020 15:19:20 +0200 Subject: RFR: Bulk backports to sh/jdk11 2020-04-20 In-Reply-To: References: Message-ID: <1b94ca55-e474-f094-fd63-4d33d52b1f84@redhat.com> On 4/20/20 3:10 PM, Roman Kennke wrote: > This backports the following changes from jdk/jdk: > > 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry > 8242301: Shenandoah: Inline LRB runtime call > 8242273: Shenandoah: accept either SATB or IU barriers, but not both > 8242271: Shenandoah: add test to verify GC mode unlock > 8242054: Shenandoah: New incremental-update mode > 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and > have a name > 8242130: Shenandoah: Simplify arraycopy-barrier dispatching > 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into > ShenandoahSATBBarrier > 8241675: Shenandoah: assert(n->outcnt() > 0) at > shenandoahSupport.cpp:2858 with > java/util/Collections/FindSubList.java > > > http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-04-20/webrev.00/ Looks good! Please make sure to include 8243008. Also, build without PCH and on AArch64? -- Thanks, -Aleksey From shade at redhat.com Mon Apr 20 13:37:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Apr 2020 15:37:52 +0200 Subject: [8] RFR: 2020-04-20, Bulk backports to sh/jdk8 Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200420/webrev.01/ Backport window for sh/jdk8 is still closed, as we are waiting for reseed. Meanwhile, this bulk backports the significant bunch of outstanding work. Don't be scared about the number of them: those are either bulk removals, or a series of simple changes. That said, please review carefully. Changes: [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings [backport] 8240749: Shenandoah: refactor ShenandoahUtils [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation [backport] 8240873: Shenandoah: Short-cut arraycopy barriers [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently [backport] 8241534: Shenandoah: region status should include update watermark [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 [backport] 8241351: Shenandoah: fragmentation metrics overhaul [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation [backport] 8241520: Shenandoah: simplify region sequence numbers handling [backport] 8241583: Shenandoah: turn heap lock asserts into macros [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace [backport] 8241673: Shenandoah: refactor anti-false-sharing padding [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods [backport] 8241838: Shenandoah: no need to trash cset during final mark [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() [backport] 8241093: Shenandoah: editorial changes in flag descriptions [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it [backport] 8241985: Shenandoah: simplify collectable garbage logging [backport] 8241983: Shenandoah: simplify FreeSet logging [backport] 8242040: Shenandoah: print allocation failure type [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged [backport] 8242082: Shenandoah: Purge Traversal mode [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods Testing: hotspot_gc_shenandoah {release, fastdebug} -- Thanks, -Aleksey From rkennke at redhat.com Mon Apr 20 16:51:13 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 20 Apr 2020 18:51:13 +0200 Subject: RFR: Bulk backports to sh/jdk11 2020-04-20 In-Reply-To: <1b94ca55-e474-f094-fd63-4d33d52b1f84@redhat.com> References: <1b94ca55-e474-f094-fd63-4d33d52b1f84@redhat.com> Message-ID: >> This backports the following changes from jdk/jdk: >> >> 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry >> 8242301: Shenandoah: Inline LRB runtime call >> 8242273: Shenandoah: accept either SATB or IU barriers, but not both >> 8242271: Shenandoah: add test to verify GC mode unlock >> 8242054: Shenandoah: New incremental-update mode >> 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and >> have a name >> 8242130: Shenandoah: Simplify arraycopy-barrier dispatching >> 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into >> ShenandoahSATBBarrier >> 8241675: Shenandoah: assert(n->outcnt() > 0) at >> shenandoahSupport.cpp:2858 with >> java/util/Collections/FindSubList.java >> >> >> http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-04-20/webrev.00/ > > Looks good! > > Please make sure to include 8243008. Right. Added here: http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-04-20/webrev.01.diff/ Full webrev: http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-04-20/webrev.01/ > Also, build without PCH and on AArch64? yes. Both are looking fine. Roman From shade at redhat.com Mon Apr 20 16:52:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Apr 2020 18:52:41 +0200 Subject: RFR: Bulk backports to sh/jdk11 2020-04-20 In-Reply-To: References: <1b94ca55-e474-f094-fd63-4d33d52b1f84@redhat.com> Message-ID: <2f14c9f3-f977-84bb-c54c-31365d8b6f64@redhat.com> On 4/20/20 6:51 PM, Roman Kennke wrote: > Right. Added here: > http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-04-20/webrev.01.diff/ > > Full webrev: > http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-04-20/webrev.01/ Looks good! -- Thanks, -Aleksey From zgu at redhat.com Mon Apr 20 18:03:41 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 20 Apr 2020 14:03:41 -0400 Subject: RFR: Bulk backports to sh/jdk11 2020-04-20 In-Reply-To: References: Message-ID: No JDK-8237396? -Zhengyu On 4/20/20 9:10 AM, Roman Kennke wrote: > This backports the following changes from jdk/jdk: > > 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry > 8242301: Shenandoah: Inline LRB runtime call > 8242273: Shenandoah: accept either SATB or IU barriers, but not both > 8242271: Shenandoah: add test to verify GC mode unlock > 8242054: Shenandoah: New incremental-update mode > 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and > have a name > 8242130: Shenandoah: Simplify arraycopy-barrier dispatching > 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into > ShenandoahSATBBarrier > 8241675: Shenandoah: assert(n->outcnt() > 0) at > shenandoahSupport.cpp:2858 with > java/util/Collections/FindSubList.java > > > http://cr.openjdk.java.net/~rkennke/backport-shjdk11-2020-04-20/webrev.00/ > > Testing: hotspot_gc_shenandoah > > Ok? > > Roman > From shade at redhat.com Mon Apr 20 18:24:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Apr 2020 20:24:10 +0200 Subject: RFR: Bulk backports to sh/jdk11 2020-04-20 In-Reply-To: References: Message-ID: <3bc91308-0868-7fc7-956f-7ceb212fdb27@redhat.com> On 4/20/20 8:03 PM, Zhengyu Gu wrote: > No JDK-8237396? It will come with 11.0.8 pickup later: https://bugs.openjdk.java.net/browse/JDK-8240452 -- Thanks, -Aleksey From zgu at redhat.com Mon Apr 20 18:29:14 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 20 Apr 2020 14:29:14 -0400 Subject: RFR: Bulk backports to sh/jdk11 2020-04-20 In-Reply-To: <3bc91308-0868-7fc7-956f-7ceb212fdb27@redhat.com> References: <3bc91308-0868-7fc7-956f-7ceb212fdb27@redhat.com> Message-ID: <66ee3518-6345-e22b-03e3-a9a904220927@redhat.com> Ah, okay. Thanks, -Zhengyu On 4/20/20 2:24 PM, Aleksey Shipilev wrote: > On 4/20/20 8:03 PM, Zhengyu Gu wrote: >> No JDK-8237396? > > It will come with 11.0.8 pickup later: > https://bugs.openjdk.java.net/browse/JDK-8240452 > From shade at redhat.com Mon Apr 20 18:54:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Apr 2020 20:54:46 +0200 Subject: [14] RFR (S) 8230853, 8237821: Shenandoah: replace leftover assert(is_in(...)) with rich asserts Message-ID: <6f579757-7c23-a322-458a-b80de22f35b1@redhat.com> Original change: https://bugs.openjdk.java.net/browse/JDK-8230853 https://hg.openjdk.java.net/jdk/jdk/rev/7e741a3fc650 We need JDK-8237821 change too, which introduced "oop" arguments: https://cr.openjdk.java.net/~shade/8230853/webrev.14u.01/ This is already done in sh/jdk11: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ec859ee39571 Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} -- Thanks, -Aleksey From zgu at redhat.com Mon Apr 20 20:27:29 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 20 Apr 2020 16:27:29 -0400 Subject: [15] RFR 8243200: Shenandoah: Allow concurrent nmethod iteration Message-ID: <8d1d0e47-ca5a-1b69-8385-0a9fb392b88f@redhat.com> Currently, Shenandoah nmethod iterator does not allow concurrent iterations, but there is possibility that heap iteration is performed in the middle of concurrent class unloading, when both want to scan nmethods (scanning roots by heap iterator and nmethod processing by concurrent class unloader). Oddly, we have not seen this problem in tests. But after I tweaked code a bit, I started seeing this issue. There is no reason for the restriction and fix is simple. Bug: https://bugs.openjdk.java.net/browse/JDK-8243200 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243200/webrev.00/ Test: hotspot_gc_shenandoah vmTestbase_nsk_jvmti vmTestbase_nsk_jdi Thanks, -Zhengyu From shade at redhat.com Tue Apr 21 07:26:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Apr 2020 09:26:31 +0200 Subject: RFR (S) 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle Message-ID: <7817681e-3fec-b374-25ed-b654ed18afaa@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8243238 See the discussion in the bug itself. Webrev: https://cr.openjdk.java.net/~shade/8243238/webrev.01/ Testing: hotspot_gc_shenandoah, DirectBufferAllocTest -- Thanks, -Aleksey From shade at redhat.com Tue Apr 21 07:46:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Apr 2020 09:46:33 +0200 Subject: [15] RFR 8243200: Shenandoah: Allow concurrent nmethod iteration In-Reply-To: <8d1d0e47-ca5a-1b69-8385-0a9fb392b88f@redhat.com> References: <8d1d0e47-ca5a-1b69-8385-0a9fb392b88f@redhat.com> Message-ID: On 4/20/20 10:27 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8243200 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243200/webrev.00/ Our code style does not allow spaces before postfix operators: 471 _itr_cnt ++; ... 478 _itr_cnt --; Otherwise looks fine. No need for another webrev. -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 21 08:09:25 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 10:09:25 +0200 Subject: RFR (S) 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle In-Reply-To: <7817681e-3fec-b374-25ed-b654ed18afaa@redhat.com> References: <7817681e-3fec-b374-25ed-b654ed18afaa@redhat.com> Message-ID: <300b1001-6bb9-1b61-3f1e-66f77cb0e4bb@redhat.com> > Bug: > https://bugs.openjdk.java.net/browse/JDK-8243238 > > See the discussion in the bug itself. > > Webrev: > https://cr.openjdk.java.net/~shade/8243238/webrev.01/ > > Testing: hotspot_gc_shenandoah, DirectBufferAllocTest Why do you call reset_gc_id() in the ctor instead of initializing it to 0 in the regular initializer? Don't we have a global GC ID counter already, somewhere? Other than that, the patch looks good, and fixes the problem for me (I could reproduce it almost 100% before). Roman From rkennke at redhat.com Tue Apr 21 08:20:42 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 10:20:42 +0200 Subject: [14] RFR (S) 8230853, 8237821: Shenandoah: replace leftover assert(is_in(...)) with rich asserts In-Reply-To: <6f579757-7c23-a322-458a-b80de22f35b1@redhat.com> References: <6f579757-7c23-a322-458a-b80de22f35b1@redhat.com> Message-ID: Looks good to me. Thanks, Roman > Original change: > https://bugs.openjdk.java.net/browse/JDK-8230853 > https://hg.openjdk.java.net/jdk/jdk/rev/7e741a3fc650 > > We need JDK-8237821 change too, which introduced "oop" arguments: > https://cr.openjdk.java.net/~shade/8230853/webrev.14u.01/ > > This is already done in sh/jdk11: > https://hg.openjdk.java.net/shenandoah/jdk11/rev/ec859ee39571 > > Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} > From shade at redhat.com Tue Apr 21 09:15:38 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Apr 2020 11:15:38 +0200 Subject: RFR (S) 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle In-Reply-To: <300b1001-6bb9-1b61-3f1e-66f77cb0e4bb@redhat.com> References: <7817681e-3fec-b374-25ed-b654ed18afaa@redhat.com> <300b1001-6bb9-1b61-3f1e-66f77cb0e4bb@redhat.com> Message-ID: <4a146a3a-a2b6-f6b0-0c57-4a026133d5d9@redhat.com> On 4/21/20 10:09 AM, Roman Kennke wrote: > Why do you call reset_gc_id() in the ctor instead of initializing it to > 0 in the regular initializer? I prefer to initialize atomic value with atomic op. (ShenandoahSharedFlags do the same.) Don't want to chase initialization bugs on these paths. > Don't we have a global GC ID counter already, somewhere? We do, in shared GCId. But, it is not atomic. Also, it is only available when GC is running, so it would return awkward stuff on out-of-cycle GC requests. Therefore, I thought it is safer to do our own. -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 21 09:14:48 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 11:14:48 +0200 Subject: Class unloading in jdk15 In-Reply-To: References: Message-ID: Hello Vicente, Sometimes, the concurrent roots processing phase appears to become quite long, e.g.: GC(6) Concurrent roots processing 661.442ms During that time, the application keeps allocating while the GC cannot yet reclaim any memory, and eventually runs out of allocation space. At roughly 1GB/s allocation rate, it'll take about 1/3rd of the total heap during that time. The concurrent root time seems very much out of proportion. For example, the corresponding marking phase only took: GC(6) Concurrent marking (unload classes) 75.039ms As a band-aid I suggest to run with more enforced headroom, e.g. -XX:ShenandoahMinFreeThreshold=20 (instead of the default value of 10). You may want to play with even higher values. We (the Shenandoah devs) shall look into what's going on there. I guess that either the concurrent roots work is not parallelized well (and hogs a single thread instead, thus taking longer to complete). We should also make the heuristics take concurrent-roots-time into account when computing trigger thresholds. Roman > Hi, > > I tried shenandoah with JDK15 (latest build from builds.shipilev.net) in > our build, it works better than with G1, without even tuning anything, so > that's great. > > I also tried enabling class unloading (we have it disabled with G1, > we don't really get a lot of memory back, but GC times do increase a little > bit), but it didn't work with shenandoah, GC times become very high. > > These are GC logs of our full build, with and without class unloading: > https://gist.github.com/cocorossello/2c7e774b89f7cb3e3c97ec5758d879ff > > Our application is a web application, using dependency injection and > dynamic proxies. I have tried to make a reproducer but I couldn't, it's not > an easy task... Maybe the problem comes from dependency injection that > creates proxies... > > I have tried reducing the build and enabling class load/unload logs > (-verbose:class), to see if that helps: > > https://gist.github.com/cocorossello/f77049148e694b91e785696b1808fb4e -> > Reduced build, class unloading off, verbose class define > > > https://gist.github.com/cocorossello/52c1c88c782adc1a0537fd8aa92a6c82 -> > Reduced build, class unloading on, verbose class define > > Please let me know if I can do something else, unfortunately I can't share > the code. > > Thank you, > Vicente. > From rkennke at redhat.com Tue Apr 21 09:17:39 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 11:17:39 +0200 Subject: RFR (S) 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle In-Reply-To: <4a146a3a-a2b6-f6b0-0c57-4a026133d5d9@redhat.com> References: <7817681e-3fec-b374-25ed-b654ed18afaa@redhat.com> <300b1001-6bb9-1b61-3f1e-66f77cb0e4bb@redhat.com> <4a146a3a-a2b6-f6b0-0c57-4a026133d5d9@redhat.com> Message-ID: <5a08c457-58a0-df08-f52b-591d559edead@redhat.com> Am 21.04.20 um 11:15 schrieb Aleksey Shipilev: > On 4/21/20 10:09 AM, Roman Kennke wrote: >> Why do you call reset_gc_id() in the ctor instead of initializing it to >> 0 in the regular initializer? > > I prefer to initialize atomic value with atomic op. (ShenandoahSharedFlags do the same.) Don't want > to chase initialization bugs on these paths. > >> Don't we have a global GC ID counter already, somewhere? > > We do, in shared GCId. But, it is not atomic. Also, it is only available when GC is running, so it > would return awkward stuff on out-of-cycle GC requests. Therefore, I thought it is safer to do our own. > Ok, that makes sense. Go! Roman From rkennke at redhat.com Tue Apr 21 09:39:33 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 11:39:33 +0200 Subject: Class unloading in jdk15 In-Reply-To: References: Message-ID: Also, I just learned that we made some changes (I have been away for a week and something). In particular, we re-ordered weak-roots and strong-roots processing and can reclaim memory a little earlier, and we have separate phases for weak and strong roots, which will report separate timings. Would it be possible that you test again with a recent jdk15 build, and send us the logs? https://builds.shipilev.net/openjdk-shenandoah-jdk/ Thanks, Roman > Hello Vicente, > > Sometimes, the concurrent roots processing phase appears to become quite > long, e.g.: > > GC(6) Concurrent roots processing 661.442ms > > During that time, the application keeps allocating while the GC cannot > yet reclaim any memory, and eventually runs out of allocation space. At > roughly 1GB/s allocation rate, it'll take about 1/3rd of the total heap > during that time. > > The concurrent root time seems very much out of proportion. For example, > the corresponding marking phase only took: > > GC(6) Concurrent marking (unload classes) 75.039ms > > As a band-aid I suggest to run with more enforced headroom, e.g. > -XX:ShenandoahMinFreeThreshold=20 (instead of the default value of 10). > You may want to play with even higher values. > > We (the Shenandoah devs) shall look into what's going on there. I guess > that either the concurrent roots work is not parallelized well (and hogs > a single thread instead, thus taking longer to complete). We should also > make the heuristics take concurrent-roots-time into account when > computing trigger thresholds. > > Roman > > >> Hi, >> >> I tried shenandoah with JDK15 (latest build from builds.shipilev.net) in >> our build, it works better than with G1, without even tuning anything, so >> that's great. >> >> I also tried enabling class unloading (we have it disabled with G1, >> we don't really get a lot of memory back, but GC times do increase a little >> bit), but it didn't work with shenandoah, GC times become very high. >> >> These are GC logs of our full build, with and without class unloading: >> https://gist.github.com/cocorossello/2c7e774b89f7cb3e3c97ec5758d879ff >> >> Our application is a web application, using dependency injection and >> dynamic proxies. I have tried to make a reproducer but I couldn't, it's not >> an easy task... Maybe the problem comes from dependency injection that >> creates proxies... >> >> I have tried reducing the build and enabling class load/unload logs >> (-verbose:class), to see if that helps: >> >> https://gist.github.com/cocorossello/f77049148e694b91e785696b1808fb4e -> >> Reduced build, class unloading off, verbose class define >> >> >> https://gist.github.com/cocorossello/52c1c88c782adc1a0537fd8aa92a6c82 -> >> Reduced build, class unloading on, verbose class define >> >> Please let me know if I can do something else, unfortunately I can't share >> the code. >> >> Thank you, >> Vicente. >> > From rkennke at redhat.com Tue Apr 21 10:23:49 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 12:23:49 +0200 Subject: Class unloading in jdk15 In-Reply-To: References: Message-ID: Sorry, that was the wrong link. Please use: https://builds.shipilev.net/openjdk-jdk/ Thanks, Roman > Also, I just learned that we made some changes (I have been away for a > week and something). In particular, we re-ordered weak-roots and > strong-roots processing and can reclaim memory a little earlier, and we > have separate phases for weak and strong roots, which will report > separate timings. Would it be possible that you test again with a recent > jdk15 build, and send us the logs? > > https://builds.shipilev.net/openjdk-shenandoah-jdk/ > > Thanks, > Roman > > >> Hello Vicente, >> >> Sometimes, the concurrent roots processing phase appears to become quite >> long, e.g.: >> >> GC(6) Concurrent roots processing 661.442ms >> >> During that time, the application keeps allocating while the GC cannot >> yet reclaim any memory, and eventually runs out of allocation space. At >> roughly 1GB/s allocation rate, it'll take about 1/3rd of the total heap >> during that time. >> >> The concurrent root time seems very much out of proportion. For example, >> the corresponding marking phase only took: >> >> GC(6) Concurrent marking (unload classes) 75.039ms >> >> As a band-aid I suggest to run with more enforced headroom, e.g. >> -XX:ShenandoahMinFreeThreshold=20 (instead of the default value of 10). >> You may want to play with even higher values. >> >> We (the Shenandoah devs) shall look into what's going on there. I guess >> that either the concurrent roots work is not parallelized well (and hogs >> a single thread instead, thus taking longer to complete). We should also >> make the heuristics take concurrent-roots-time into account when >> computing trigger thresholds. >> >> Roman >> >> >>> Hi, >>> >>> I tried shenandoah with JDK15 (latest build from builds.shipilev.net) in >>> our build, it works better than with G1, without even tuning anything, so >>> that's great. >>> >>> I also tried enabling class unloading (we have it disabled with G1, >>> we don't really get a lot of memory back, but GC times do increase a little >>> bit), but it didn't work with shenandoah, GC times become very high. >>> >>> These are GC logs of our full build, with and without class unloading: >>> https://gist.github.com/cocorossello/2c7e774b89f7cb3e3c97ec5758d879ff >>> >>> Our application is a web application, using dependency injection and >>> dynamic proxies. I have tried to make a reproducer but I couldn't, it's not >>> an easy task... Maybe the problem comes from dependency injection that >>> creates proxies... >>> >>> I have tried reducing the build and enabling class load/unload logs >>> (-verbose:class), to see if that helps: >>> >>> https://gist.github.com/cocorossello/f77049148e694b91e785696b1808fb4e -> >>> Reduced build, class unloading off, verbose class define >>> >>> >>> https://gist.github.com/cocorossello/52c1c88c782adc1a0537fd8aa92a6c82 -> >>> Reduced build, class unloading on, verbose class define >>> >>> Please let me know if I can do something else, unfortunately I can't share >>> the code. >>> >>> Thank you, >>> Vicente. >>> >> > From zgu at redhat.com Tue Apr 21 10:58:43 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 21 Apr 2020 06:58:43 -0400 Subject: [15] RFR 8243200: Shenandoah: Allow concurrent nmethod iteration In-Reply-To: References: <8d1d0e47-ca5a-1b69-8385-0a9fb392b88f@redhat.com> Message-ID: Thanks, Aleksey. I just realize that this are chances to double free old table, so this patch needs additional work. I would like to withdraw this RFR for now. -Zhengyu On 4/21/20 3:46 AM, Aleksey Shipilev wrote: > On 4/20/20 10:27 PM, Zhengyu Gu wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243200 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243200/webrev.00/ > > Our code style does not allow spaces before postfix operators: > 471 _itr_cnt ++; > ... > 478 _itr_cnt --; > > Otherwise looks fine. No need for another webrev. > From cocorossello at gmail.com Tue Apr 21 12:09:30 2020 From: cocorossello at gmail.com (Vicente Rossello) Date: Tue, 21 Apr 2020 14:09:30 +0200 Subject: Class unloading in jdk15 In-Reply-To: References: Message-ID: Hi, I just tested with latest jdk. Setting ShenandoahMinFreeThreshold did help a bit, but still no usable. JVM Version: 15-testing+0-builds.shipilev.net-openjdk-jdk-b1226-20200420 With class unloading, no ShenandoahMinFreeThreshold set https://gist.github.com/cocorossello/fc29a2471fff3cefaae5ef1cda9101d2 JVM Version: 15-testing+0-builds.shipilev.net-openjdk-jdk-b1226-20200420 With class unloading, ShenandoahMinFreeThreshold=20: https://gist.github.com/cocorossello/ae193797899d9e3be040b7ef4a359803 JVM Version: 15-testing+0-builds.shipilev.net-openjdk-jdk-b1226-20200420 Without class unloading: https://gist.github.com/cocorossello/35333cdd9e60b1283455143bfdec1516 Let me know if I can provide something else Thanks, Vicnete. On Tue, Apr 21, 2020 at 12:24 PM Roman Kennke wrote: > Sorry, that was the wrong link. Please use: > > https://builds.shipilev.net/openjdk-jdk/ > > Thanks, > Roman > > > Also, I just learned that we made some changes (I have been away for a > > week and something). In particular, we re-ordered weak-roots and > > strong-roots processing and can reclaim memory a little earlier, and we > > have separate phases for weak and strong roots, which will report > > separate timings. Would it be possible that you test again with a recent > > jdk15 build, and send us the logs? > > > > https://builds.shipilev.net/openjdk-shenandoah-jdk/ > > > > Thanks, > > Roman > > > > > >> Hello Vicente, > >> > >> Sometimes, the concurrent roots processing phase appears to become quite > >> long, e.g.: > >> > >> GC(6) Concurrent roots processing 661.442ms > >> > >> During that time, the application keeps allocating while the GC cannot > >> yet reclaim any memory, and eventually runs out of allocation space. At > >> roughly 1GB/s allocation rate, it'll take about 1/3rd of the total heap > >> during that time. > >> > >> The concurrent root time seems very much out of proportion. For example, > >> the corresponding marking phase only took: > >> > >> GC(6) Concurrent marking (unload classes) 75.039ms > >> > >> As a band-aid I suggest to run with more enforced headroom, e.g. > >> -XX:ShenandoahMinFreeThreshold=20 (instead of the default value of 10). > >> You may want to play with even higher values. > >> > >> We (the Shenandoah devs) shall look into what's going on there. I guess > >> that either the concurrent roots work is not parallelized well (and hogs > >> a single thread instead, thus taking longer to complete). We should also > >> make the heuristics take concurrent-roots-time into account when > >> computing trigger thresholds. > >> > >> Roman > >> > >> > >>> Hi, > >>> > >>> I tried shenandoah with JDK15 (latest build from builds.shipilev.net) > in > >>> our build, it works better than with G1, without even tuning anything, > so > >>> that's great. > >>> > >>> I also tried enabling class unloading (we have it disabled with G1, > >>> we don't really get a lot of memory back, but GC times do increase a > little > >>> bit), but it didn't work with shenandoah, GC times become very high. > >>> > >>> These are GC logs of our full build, with and without class unloading: > >>> https://gist.github.com/cocorossello/2c7e774b89f7cb3e3c97ec5758d879ff > >>> > >>> Our application is a web application, using dependency injection and > >>> dynamic proxies. I have tried to make a reproducer but I couldn't, > it's not > >>> an easy task... Maybe the problem comes from dependency injection that > >>> creates proxies... > >>> > >>> I have tried reducing the build and enabling class load/unload logs > >>> (-verbose:class), to see if that helps: > >>> > >>> https://gist.github.com/cocorossello/f77049148e694b91e785696b1808fb4e > -> > >>> Reduced build, class unloading off, verbose class define > >>> > >>> > >>> https://gist.github.com/cocorossello/52c1c88c782adc1a0537fd8aa92a6c82 > -> > >>> Reduced build, class unloading on, verbose class define > >>> > >>> Please let me know if I can do something else, unfortunately I can't > share > >>> the code. > >>> > >>> Thank you, > >>> Vicente. > >>> > >> > > > > From shade at redhat.com Tue Apr 21 17:48:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Apr 2020 19:48:03 +0200 Subject: RFR (XS) 8243291: Shenandoah: no need to retire TLABs at Init Update Refs Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243291 After JDK-8240872, we update URWM (update reference watermark) at final-mark, where we retire TLABs already. So we don't need to retire TLABs at Init Update Refs, because they are guaranteed to be past URWM. It used to be needed when we were capturing update-refs limit during init-update-refs. This patch saves about 1.5G of waste on 30G heap in a throwaway scenario for me. diff -r 6fd1fbd073e2 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 21 19:04:23 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 21 19:46:05 2020 +0200 @@ -1524,7 +1524,11 @@ assert_pinned_region_status(); } - // Force the threads to reacquire their TLABs outside the collection set. + // Retire the TLABs, which will force threads to reacquire their TLABs after the pause. + // This is needed for two reasons. Strong one: new allocations would be with new freeset, + // which would be outside the collection set, so no cset writes would happen there. + // Weaker one: new allocations would happen past update watermark, and so less work would + // be needed for reference updates (would update the large filler instead). { ShenandoahGCSubPhase phase(ShenandoahPhaseTimings::retire_tlabs); make_parsable(true); @@ -2449,10 +2453,6 @@ { ShenandoahGCSubPhase phase(ShenandoahPhaseTimings::init_update_refs_prepare); - - make_parsable(true); - - // Reset iterator. _update_refs_iterator.reset(); } Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Tue Apr 21 17:56:19 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 19:56:19 +0200 Subject: RFR (XS) 8243291: Shenandoah: no need to retire TLABs at Init Update Refs In-Reply-To: References: Message-ID: <459855e3-3751-5385-1c73-baff6ee0d63b@redhat.com> Nice find! Looks good to me. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243291 > > After JDK-8240872, we update URWM (update reference watermark) at final-mark, where we retire TLABs > already. So we don't need to retire TLABs at Init Update Refs, because they are guaranteed to be > past URWM. It used to be needed when we were capturing update-refs limit during init-update-refs. > This patch saves about 1.5G of waste on 30G heap in a throwaway scenario for me. > > diff -r 6fd1fbd073e2 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 21 19:04:23 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue Apr 21 19:46:05 2020 +0200 > @@ -1524,7 +1524,11 @@ > assert_pinned_region_status(); > } > > - // Force the threads to reacquire their TLABs outside the collection set. > + // Retire the TLABs, which will force threads to reacquire their TLABs after the pause. > + // This is needed for two reasons. Strong one: new allocations would be with new freeset, > + // which would be outside the collection set, so no cset writes would happen there. > + // Weaker one: new allocations would happen past update watermark, and so less work would > + // be needed for reference updates (would update the large filler instead). > { > ShenandoahGCSubPhase phase(ShenandoahPhaseTimings::retire_tlabs); > make_parsable(true); > @@ -2449,10 +2453,6 @@ > > { > ShenandoahGCSubPhase phase(ShenandoahPhaseTimings::init_update_refs_prepare); > - > - make_parsable(true); > - > - // Reset iterator. > _update_refs_iterator.reset(); > } > > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Tue Apr 21 18:31:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Apr 2020 20:31:01 +0200 Subject: RFR (XS) 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243301 Testing discovers this issue that breaks Shenandoah when JDK-8243291 is applied. See the discussion in bug report. I would push this before JDK-8243291 is pushed. Testing: hotspot_gc_shenandoah, failing tests -- Thanks, -Aleksey From shade at redhat.com Tue Apr 21 18:39:07 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Apr 2020 20:39:07 +0200 Subject: RFR (XS) 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs In-Reply-To: References: Message-ID: <3a833a09-2cfe-66a1-6d0f-2a8f4fa4c8ae@redhat.com> On 4/21/20 8:31 PM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243301 > > Testing discovers this issue that breaks Shenandoah when JDK-8243291 is applied. See the discussion > in bug report. I would push this before JDK-8243291 is pushed. Err. Of course, here is the fix: diff -r 4153de8e4dca src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Tue Apr 21 20:00:58 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Tue Apr 21 20:38:55 2020 +0200 @@ -126,16 +126,8 @@ } - // Try to mix the allocation into the mutator view: - if (ShenandoahAllowMixedAllocs) { - for (size_t c = _mutator_rightmost + 1; c > _mutator_leftmost; c--) { - size_t idx = c - 1; - if (is_mutator_free(idx)) { - HeapWord* result = try_allocate_in(_heap->get_region(idx), req, in_new_region); - if (result != NULL) { - return result; - } - } - } - } + // No dice. Do not try to mix mutator and GC allocations, because + // URWM moves due to GC allocations would expose unparsable mutator + // allocations. + break; } diff -r 4153de8e4dca src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Tue Apr 21 20:00:58 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Tue Apr 21 20:38:55 2020 +0200 @@ -212,8 +212,4 @@ "Use Elastic TLABs with Shenandoah") \ \ - diagnostic(bool, ShenandoahAllowMixedAllocs, true, \ - "Allow mixing mutator and collector allocations into a single " \ - "region. Some heuristics enable/disable it for their needs") \ - \ experimental(uintx, ShenandoahEvacReserve, 5, \ "How much of heap to reserve for evacuations. Larger values make "\ -- Thanks, -Aleksey From shade at redhat.com Tue Apr 21 19:10:18 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Apr 2020 21:10:18 +0200 Subject: ATTN: shenandoah/jdk8 was reseeded Message-ID: <406838d9-5889-07bf-b385-3a9edb3be8d7@redhat.com> Our sh/jdk8 repository: https://hg.openjdk.java.net/shenandoah/jdk8/ ...was reseeded from upstream: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ It did not change content-wise, but this reseed eliminated some duplicate changesets that were transplanted to upstream due to a process glitch. If you try to "hg out" from current copy, it would show a bunch of those changesets. Please re-clone sh/jdk8! Pre-built workspace tarball can be found here: https://builds.shipilev.net/workspaces/shenandoah-jdk8.tar.xz -- Thanks, -Aleksey From shade at redhat.com Tue Apr 21 19:22:45 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Apr 2020 21:22:45 +0200 Subject: RFR (XS) 8243307: Shenandoah: remove ShCollectionSet::live_data Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243307 ShCollectionSet::live_data is not used, yet computed on hot path during the pause. We should eliminate it. Fix: diff -r 53c60b2ed2d5 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp Tue Apr 21 21:20:19 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp Tue Apr 21 21:21:56 2020 +0200 @@ -43,3 +43,2 @@ _garbage(0), - _live_data(0), _used(0), @@ -87,5 +86,4 @@ _cset_map[r->index()] = 1; - _region_count ++; + _region_count++; _garbage += r->garbage(); - _live_data += r->get_live_data_bytes(); _used += r->used(); @@ -107,3 +105,2 @@ _garbage = 0; - _live_data = 0; _used = 0; diff -r 53c60b2ed2d5 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 21 21:20:19 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 21 21:21:56 2020 +0200 @@ -45,3 +45,2 @@ size_t _garbage; - size_t _live_data; size_t _used; @@ -80,3 +79,2 @@ size_t used() const { return _used; } - size_t live_data() const { return _live_data; } size_t garbage() const { return _garbage; } Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Tue Apr 21 19:32:04 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 21 Apr 2020 15:32:04 -0400 Subject: [15] RFR 8243200: Shenandoah: Allow concurrent nmethod iteration In-Reply-To: References: <8d1d0e47-ca5a-1b69-8385-0a9fb392b88f@redhat.com> Message-ID: <225b738b-5162-d8a6-e820-869f73423325@redhat.com> Hi, > > I just realize that this are chances to double free old table, so this > patch needs additional work. I would like to withdraw this RFR for now. Abstracting the list for holding Shenandoah NMethod data into a class and reference counting the list. Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243200/webrev.01/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu > > -Zhengyu > > On 4/21/20 3:46 AM, Aleksey Shipilev wrote: >> On 4/20/20 10:27 PM, Zhengyu Gu wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243200 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243200/webrev.00/ >> >> Our code style does not allow spaces before postfix operators: >> ? 471?? _itr_cnt ++; >> ... >> ? 478?? _itr_cnt --; >> >> Otherwise looks fine. No need for another webrev. >> From rkennke at redhat.com Tue Apr 21 19:37:19 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 21:37:19 +0200 Subject: RFR (XS) 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs In-Reply-To: <3a833a09-2cfe-66a1-6d0f-2a8f4fa4c8ae@redhat.com> References: <3a833a09-2cfe-66a1-6d0f-2a8f4fa4c8ae@redhat.com> Message-ID: <0865de23-bea9-a8cf-ab53-76ecbea828c2@redhat.com> Ok. One flag down is also a win :-) Roman > On 4/21/20 8:31 PM, Aleksey Shipilev wrote: >> RFE: >> https://bugs.openjdk.java.net/browse/JDK-8243301 >> >> Testing discovers this issue that breaks Shenandoah when JDK-8243291 is applied. See the discussion >> in bug report. I would push this before JDK-8243291 is pushed. > > Err. Of course, here is the fix: > > diff -r 4153de8e4dca src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Tue Apr 21 20:00:58 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp Tue Apr 21 20:38:55 2020 +0200 > @@ -126,16 +126,8 @@ > } > > - // Try to mix the allocation into the mutator view: > - if (ShenandoahAllowMixedAllocs) { > - for (size_t c = _mutator_rightmost + 1; c > _mutator_leftmost; c--) { > - size_t idx = c - 1; > - if (is_mutator_free(idx)) { > - HeapWord* result = try_allocate_in(_heap->get_region(idx), req, in_new_region); > - if (result != NULL) { > - return result; > - } > - } > - } > - } > + // No dice. Do not try to mix mutator and GC allocations, because > + // URWM moves due to GC allocations would expose unparsable mutator > + // allocations. > + > break; > } > diff -r 4153de8e4dca src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Tue Apr 21 20:00:58 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Tue Apr 21 20:38:55 2020 +0200 > @@ -212,8 +212,4 @@ > "Use Elastic TLABs with Shenandoah") \ > \ > - diagnostic(bool, ShenandoahAllowMixedAllocs, true, \ > - "Allow mixing mutator and collector allocations into a single " \ > - "region. Some heuristics enable/disable it for their needs") \ > - \ > experimental(uintx, ShenandoahEvacReserve, 5, \ > "How much of heap to reserve for evacuations. Larger values make "\ > > From rkennke at redhat.com Tue Apr 21 19:39:52 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 21:39:52 +0200 Subject: RFR (XS) 8243307: Shenandoah: remove ShCollectionSet::live_data In-Reply-To: References: Message-ID: <56043722-4edb-9d54-9bfa-addd6bf146b2@redhat.com> Ok. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243307 > > ShCollectionSet::live_data is not used, yet computed on hot path during the pause. We should > eliminate it. > > Fix: > > diff -r 53c60b2ed2d5 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp Tue Apr 21 21:20:19 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp Tue Apr 21 21:21:56 2020 +0200 > @@ -43,3 +43,2 @@ > _garbage(0), > - _live_data(0), > _used(0), > @@ -87,5 +86,4 @@ > _cset_map[r->index()] = 1; > - _region_count ++; > + _region_count++; > _garbage += r->garbage(); > - _live_data += r->get_live_data_bytes(); > _used += r->used(); > @@ -107,3 +105,2 @@ > _garbage = 0; > - _live_data = 0; > _used = 0; > diff -r 53c60b2ed2d5 src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 21 21:20:19 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Tue Apr 21 21:21:56 2020 +0200 > @@ -45,3 +45,2 @@ > size_t _garbage; > - size_t _live_data; > size_t _used; > @@ -80,3 +79,2 @@ > size_t used() const { return _used; } > - size_t live_data() const { return _live_data; } > size_t garbage() const { return _garbage; } > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Tue Apr 21 19:50:35 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Apr 2020 21:50:35 +0200 Subject: [8] RFR: 2020-04-20, Bulk backports to sh/jdk8 In-Reply-To: References: Message-ID: Looks good to me. Thank you! Roman > http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200420/webrev.01/ > > Backport window for sh/jdk8 is still closed, as we are waiting for reseed. Meanwhile, this bulk > backports the significant bunch of outstanding work. Don't be scared about the number of them: those > are either bulk removals, or a series of simple changes. That said, please review carefully. > > Changes: > [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings > [backport] 8240749: Shenandoah: refactor ShenandoahUtils > [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker > [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts > [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles > [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks > [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation > [backport] 8240873: Shenandoah: Short-cut arraycopy barriers > [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently > [backport] 8241534: Shenandoah: region status should include update watermark > [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 > [backport] 8241351: Shenandoah: fragmentation metrics overhaul > [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" > [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation > [backport] 8241520: Shenandoah: simplify region sequence numbers handling > [backport] 8241583: Shenandoah: turn heap lock asserts into macros > [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace > [backport] 8241673: Shenandoah: refactor anti-false-sharing padding > [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved > [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() > [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap > [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods > [backport] 8241838: Shenandoah: no need to trash cset during final mark > [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion > [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number > [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number > [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines > [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() > [backport] 8241093: Shenandoah: editorial changes in flag descriptions > [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it > [backport] 8241985: Shenandoah: simplify collectable garbage logging > [backport] 8241983: Shenandoah: simplify FreeSet logging > [backport] 8242040: Shenandoah: print allocation failure type > [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target > [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold > [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag > [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters > [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged > [backport] 8242082: Shenandoah: Purge Traversal mode > [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared > [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses > [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc > [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly > [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset > [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set > [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods > > Testing: hotspot_gc_shenandoah {release, fastdebug} > From zgu at redhat.com Wed Apr 22 00:57:38 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 21 Apr 2020 20:57:38 -0400 Subject: [15] RFR 8243323: Shenandoah: Recycle immediate garbage before concurrent class unloading Message-ID: <8f957e1d-3ef5-bb8e-a2a0-a3eb3be79bf5@redhat.com> Please review this patch that allows Shenandoah to recycle immediate garbage before performing concurrent class unloading. Please see bug for details. Bug: https://bugs.openjdk.java.net/browse/JDK-8243323 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.00/index.html Test: hotspot_gc_shenandoah tier1 with ShenandoahGC Thanks, -Zhengyu From shade at redhat.com Wed Apr 22 07:06:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 09:06:43 +0200 Subject: shenandoah/jdk8 is open for backports to 8u262 Message-ID: $subject, you can RFR stuff to go in there. -- Thanks, -Aleksey From shade at redhat.com Wed Apr 22 07:10:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 09:10:50 +0200 Subject: [8] RFR: 2020-04-20, Bulk backports to sh/jdk8 In-Reply-To: References: Message-ID: <2e33532d-2dd8-fdb0-9dda-cc963f5fd5e1@redhat.com> On 4/21/20 9:50 PM, Roman Kennke wrote: > Looks good to me. Thank you! Pushed! You can pile on IU backports now :) -- Thanks, -Aleksey From shade at redhat.com Wed Apr 22 07:06:31 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 22 Apr 2020 07:06:31 +0000 Subject: hg: shenandoah/jdk8/hotspot: 46 new changesets Message-ID: <202004220706.03M76V9R009878@aojmv0008.oracle.com> Changeset: f5c426d7e4bd Author: shade Date: 2020-03-06 17:03 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f5c426d7e4bd [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp Changeset: d888701f7768 Author: shade Date: 2020-03-09 22:40 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d888701f7768 [backport] 8240749: Shenandoah: refactor ShenandoahUtils Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp Changeset: b616c66d4705 Author: shade Date: 2020-03-09 22:41 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b616c66d4705 [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker Reviewed-by: rkennke - src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: 3018d88de54d Author: shade Date: 2020-01-24 21:11 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3018d88de54d [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts [backport] 8237821: Shenandoah: build broken after JDK-8237637 (Remove dubious type conversions from oop) Reviewed-by: shade Contributed-by: Aditya Mandaleeka ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp Changeset: 87f21873fa4c Author: shade Date: 2020-03-11 14:17 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/87f21873fa4c [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/vm_operations.hpp ! test/gc/shenandoah/TestStringDedupStress.java Changeset: f0b8ba0570c6 Author: zgu Date: 2020-03-12 09:25 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f0b8ba0570c6 [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: d4e4d6a6df74 Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d4e4d6a6df74 [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 0bf1ade02c1f Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0bf1ade02c1f [backport] 8240873: Shenandoah: Short-cut arraycopy barriers Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: 2c18c8e5bf02 Author: rkennke Date: 2020-03-17 11:49 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2c18c8e5bf02 [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: f0797ef4bec1 Author: shade Date: 2020-03-24 18:46 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f0797ef4bec1 [backport] 8241534: Shenandoah: region status should include update watermark Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: 658223db05f0 Author: shade Date: 2020-03-12 18:50 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/658223db05f0 [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: ca49b44f5563 Author: shade Date: 2020-03-23 19:14 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ca49b44f5563 [backport] 8241351: Shenandoah: fragmentation metrics overhaul Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.hpp Changeset: 2a5e8bcd0faa Author: shade Date: 2020-03-23 19:14 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2a5e8bcd0faa [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp Changeset: 880e0f80a226 Author: shade Date: 2020-03-23 19:14 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/880e0f80a226 [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp Changeset: ea592ef76c80 Author: shade Date: 2020-03-24 18:46 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ea592ef76c80 [backport] 8241520: Shenandoah: simplify region sequence numbers handling Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: be98ad3bab74 Author: shade Date: 2020-03-25 17:20 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/be98ad3bab74 [backport] 8241583: Shenandoah: turn heap lock asserts into macros Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp Changeset: e0569518bb86 Author: shade Date: 2020-03-26 19:08 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e0569518bb86 [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace Reviewed-by: rkennke ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeapRegion.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: 884ad772f981 Author: shade Date: 2020-03-26 19:09 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/884ad772f981 [backport] 8241673: Shenandoah: refactor anti-false-sharing padding Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahPadding.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp Changeset: 96e4bff82c32 Author: shade Date: 2020-03-27 15:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/96e4bff82c32 [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved Reviewed-by: zgu, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: d9eec907873f Author: shade Date: 2020-03-27 15:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d9eec907873f [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/services/memoryService.cpp Changeset: 31c41ebe76e2 Author: shade Date: 2020-03-27 15:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/31c41ebe76e2 [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 8633642b8b06 Author: shade Date: 2020-03-27 15:33 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8633642b8b06 [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp Changeset: bbc16cd00817 Author: shade Date: 2020-03-30 19:37 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bbc16cd00817 [backport] 8241838: Shenandoah: no need to trash cset during final mark Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: b7573cb9b63f Author: shade Date: 2020-03-30 19:37 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b7573cb9b63f [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 9d021b2d8b61 Author: shade Date: 2020-03-30 19:38 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9d021b2d8b61 [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: 28c2f637f1ea Author: shade Date: 2020-03-30 19:38 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/28c2f637f1ea [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: d642b661ae7f Author: shade Date: 2020-03-31 08:42 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/d642b661ae7f [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPadding.hpp Changeset: ae8ef4c2a966 Author: shade Date: 2020-04-07 14:32 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ae8ef4c2a966 [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() Reviewed-by: rkennke, stuefe ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: c421e23d75ca Author: shade Date: 2020-03-18 06:28 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c421e23d75ca [backport] 8241093: Shenandoah: editorial changes in flag descriptions Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 7e913eee7872 Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7e913eee7872 [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 812520907321 Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/812520907321 [backport] 8241985: Shenandoah: simplify collectable garbage logging Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! test/gc/shenandoah/options/TestVerboseGC.java Changeset: 1e12f73bb1ec Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/1e12f73bb1ec [backport] 8241983: Shenandoah: simplify FreeSet logging Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp Changeset: 927ad3007678 Author: shade Date: 2020-04-02 20:10 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/927ad3007678 [backport] 8242040: Shenandoah: print allocation failure type Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahAllocRequest.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: bcda4294d29f Author: shade Date: 2020-04-02 20:11 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bcda4294d29f [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp Changeset: 167834f91182 Author: shade Date: 2020-04-03 11:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/167834f91182 [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 353b051a0933 Author: shade Date: 2020-04-03 11:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/353b051a0933 [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/options/TestRegionSizeArgs.java Changeset: ced89cdab2fb Author: shade Date: 2020-04-03 13:58 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ced89cdab2fb [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: e461491ccbf6 Author: shade Date: 2020-04-03 13:58 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/e461491ccbf6 [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: b69ee541d07f Author: rkennke Date: 2020-04-03 15:06 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b69ee541d07f [backport] 8242082: Shenandoah: Purge Traversal mode Reviewed-by: shade ! src/cpu/x86/vm/macroAssembler_x86.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.hpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.inline.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/runtime/vm_operations.hpp ! 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/TestPeriodicGC.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/TestWrongArrayMember.java ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestExplicitGC.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: 9aa4806955e3 Author: shade Date: 2020-04-06 10:31 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9aa4806955e3 [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 49eef2be235e Author: shade Date: 2020-04-03 16:13 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/49eef2be235e [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 007f7948edaf Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/007f7948edaf [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: 0e4f9e6c01f1 Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0e4f9e6c01f1 [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: 821efb155848 Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/821efb155848 [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: bb3767ea183a Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bb3767ea183a [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp Changeset: b49cd4f04b3c Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b49cd4f04b3c [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp From shade at redhat.com Wed Apr 22 09:50:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 11:50:05 +0200 Subject: [8] RFR: Fix slowdebug build after JDK-8230853 backport Message-ID: CI reports slowdebug build failure after recent JDK-8230853 backport. It is 8u-specific, because it has the assert that takes in_collection_set(HeapWord*) that is not available anymore. The fix is to ditch the assert and get that code in line with what sh/jdk11 and jdk/jdk are doing: diff -r b49cd4f04b3c src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp --- a/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Mon Apr 06 20:35:43 2020 +0200 +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Wed Apr 22 11:48:28 2020 +0200 @@ -824,13 +824,7 @@ HeapWord* ShenandoahHeap::mem_allocate(size_t size, bool* gc_overhead_limit_was_exceeded) { ShenandoahAllocRequest req = ShenandoahAllocRequest::for_shared(size); - HeapWord* result = allocate_memory(req); - if (result != NULL) { - assert(! in_collection_set(result), "never allocate in targetted region"); - return result; - } else { - return NULL; - } + return allocate_memory(req); } class ShenandoahConcurrentEvacuateRegionObjectClosure : public ObjectClosure { Testing: Linux x86_64 {release,fastdebug,slowdebug} builds -- Thanks, -Aleksey From shade at redhat.com Wed Apr 22 10:37:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 12:37:39 +0200 Subject: [14] RFR 8240873: Shenandoah: Short-cut arraycopy barriers Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8240873 https://hg.openjdk.java.net/jdk/jdk/rev/cc0ffb1d0458 The context is different, because 15 did HeapWord* -> oop conversions on many paths. The whole thing would be followed by other changes that drop volatiles/atomics from update_watermark. 14u webrev: https://cr.openjdk.java.net/~shade/8240873/webrev.14u.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Wed Apr 22 10:40:00 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 22 Apr 2020 12:40:00 +0200 Subject: [8] RFR: Fix slowdebug build after JDK-8230853 backport In-Reply-To: References: Message-ID: Ok. Thanks, Roman > CI reports slowdebug build failure after recent JDK-8230853 backport. > > It is 8u-specific, because it has the assert that takes in_collection_set(HeapWord*) that is not > available anymore. The fix is to ditch the assert and get that code in line with what sh/jdk11 and > jdk/jdk are doing: > > diff -r b49cd4f04b3c src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp > --- a/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Mon Apr 06 20:35:43 2020 +0200 > +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Wed Apr 22 11:48:28 2020 +0200 > @@ -824,13 +824,7 @@ > HeapWord* ShenandoahHeap::mem_allocate(size_t size, > bool* gc_overhead_limit_was_exceeded) { > ShenandoahAllocRequest req = ShenandoahAllocRequest::for_shared(size); > - HeapWord* result = allocate_memory(req); > - if (result != NULL) { > - assert(! in_collection_set(result), "never allocate in targetted region"); > - return result; > - } else { > - return NULL; > - } > + return allocate_memory(req); > } > > class ShenandoahConcurrentEvacuateRegionObjectClosure : public ObjectClosure { > > > Testing: Linux x86_64 {release,fastdebug,slowdebug} builds > From shade at redhat.com Wed Apr 22 10:42:24 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 22 Apr 2020 10:42:24 +0000 Subject: hg: shenandoah/jdk8/hotspot: Fix slowdebug build after JDK-8230853 backport Message-ID: <202004221042.03MAgO3Q010258@aojmv0008.oracle.com> Changeset: ce1281b3e5aa Author: shade Date: 2020-04-22 11:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ce1281b3e5aa Fix slowdebug build after JDK-8230853 backport ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp From shade at redhat.com Wed Apr 22 13:01:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 15:01:27 +0200 Subject: RFR (XS) 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243395 It has the guarantee() block that verifies the per-thread worker times are only added to relevant phases. There is no reason to have it as guarantee and expose it in release bits, and it is exposed on critical path during GC pauses. assert should be enough. Fix: diff -r d380fc43bcbb -r c2d54a087de0 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Wed Apr 22 13:48:28 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Wed Apr 22 13:50:26 2020 +0200 @@ -73,16 +73,17 @@ return; } - guarantee(phase == init_evac || - phase == scan_roots || - phase == update_roots || - phase == final_update_refs_roots || - phase == full_gc_roots || - phase == degen_gc_update_roots || - phase == full_gc_purge_par || - phase == purge_par || - phase == _num_phases, - "only in these phases we can add per-thread phase times"); + assert(phase == init_evac || + phase == scan_roots || + phase == update_roots || + phase == final_update_refs_roots || + phase == full_gc_roots || + phase == degen_gc_update_roots || + phase == full_gc_purge_par || + phase == purge_par || + phase == _num_phases, + "Phase should accept accept per-thread phase times: %s", phase_name(phase)); + if (phase != _num_phases) { double s = 0; for (uint i = 1; i < GCParPhasesSentinel; i++) { Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Wed Apr 22 13:09:33 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 22 Apr 2020 09:09:33 -0400 Subject: RFR (XS) 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end In-Reply-To: References: Message-ID: <987f3955-bead-6d48-6d33-334416f4e28d@redhat.com> Looks good. -Zhengyu On 4/22/20 9:01 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243395 > > It has the guarantee() block that verifies the per-thread worker times are only added to relevant > phases. There is no reason to have it as guarantee and expose it in release bits, and it is exposed > on critical path during GC pauses. assert should be enough. > > Fix: > > diff -r d380fc43bcbb -r c2d54a087de0 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Wed Apr 22 13:48:28 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Wed Apr 22 13:50:26 2020 +0200 > @@ -73,16 +73,17 @@ > return; > } > > - guarantee(phase == init_evac || > - phase == scan_roots || > - phase == update_roots || > - phase == final_update_refs_roots || > - phase == full_gc_roots || > - phase == degen_gc_update_roots || > - phase == full_gc_purge_par || > - phase == purge_par || > - phase == _num_phases, > - "only in these phases we can add per-thread phase times"); > + assert(phase == init_evac || > + phase == scan_roots || > + phase == update_roots || > + phase == final_update_refs_roots || > + phase == full_gc_roots || > + phase == degen_gc_update_roots || > + phase == full_gc_purge_par || > + phase == purge_par || > + phase == _num_phases, > + "Phase should accept accept per-thread phase times: %s", phase_name(phase)); > + > if (phase != _num_phases) { > double s = 0; > for (uint i = 1; i < GCParPhasesSentinel; i++) { > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Wed Apr 22 13:16:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 15:16:51 +0200 Subject: [15] RFR 8243323: Shenandoah: Recycle immediate garbage before concurrent class unloading In-Reply-To: <8f957e1d-3ef5-bb8e-a2a0-a3eb3be79bf5@redhat.com> References: <8f957e1d-3ef5-bb8e-a2a0-a3eb3be79bf5@redhat.com> Message-ID: <491a1c42-f689-db18-8d34-eb690b9f9f48@redhat.com> On 4/22/20 2:57 AM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8243323 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.00/index.html *) This is awkward, why does it piggyback on is_concurrent_weak_root_in_progress? It should probably have its own flag, and that flag should only be set when SCR::should_do_concurrent_class_unloading() is true. Control thread should not drop the flag, it should be done by the relevant entry_*/op_* stage. Also, double new-line at L367-368. 360 // Perform concurrent class unloading 361 if (heap->is_concurrent_weak_root_in_progress()) { 362 if(ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) { 363 heap->entry_class_unloading(); 364 } 365 heap->set_concurrent_weak_root_in_progress(false); 366 } 367 368 It is generally about symmetries. See how SH::op_strong_roots does it? New code should do the same. 1833 void ShenandoahHeap::op_strong_roots() { 1834 assert(is_concurrent_strong_root_in_progress(), "Checked by caller"); ... 1837 set_concurrent_strong_root_in_progress(false); *) Feels like this code belongs in shenandoahNMethods? 1766 if (_concurrent_class_unloading) { 1767 MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); 1768 _nmethod_itr.nmethods_do_begin(); 1769 } ... 1775 if (_concurrent_class_unloading) { 1776 MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); 1777 _nmethod_itr.nmethods_do_end(); 1778 } *) Double new-line here: 2916 try_inject_alloc_failure(); 2917 op_class_unloading(); 2918 } 2919 2920 -- Thanks, -Aleksey From zgu at redhat.com Wed Apr 22 15:07:24 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 22 Apr 2020 11:07:24 -0400 Subject: [15] RFR 8243323: Shenandoah: Recycle immediate garbage before concurrent class unloading In-Reply-To: <491a1c42-f689-db18-8d34-eb690b9f9f48@redhat.com> References: <8f957e1d-3ef5-bb8e-a2a0-a3eb3be79bf5@redhat.com> <491a1c42-f689-db18-8d34-eb690b9f9f48@redhat.com> Message-ID: On 4/22/20 9:16 AM, Aleksey Shipilev wrote: > On 4/22/20 2:57 AM, Zhengyu Gu wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243323 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.00/index.html > > *) This is awkward, why does it piggyback on is_concurrent_weak_root_in_progress? It should probably > have its own flag, and that flag should only be set when SCR::should_do_concurrent_class_unloading() > is true. Control thread should not drop the flag, it should be done by the relevant entry_*/op_* stage. > > Also, double new-line at L367-368. > > 360 // Perform concurrent class unloading > 361 if (heap->is_concurrent_weak_root_in_progress()) { > 362 if(ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) { > 363 heap->entry_class_unloading(); > 364 } > 365 heap->set_concurrent_weak_root_in_progress(false); > 366 } > 367 > 368 > > It is generally about symmetries. See how SH::op_strong_roots does it? New code should do the same. Fixed. > > *) Feels like this code belongs in shenandoahNMethods? > > 1766 if (_concurrent_class_unloading) { > 1767 MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); > 1768 _nmethod_itr.nmethods_do_begin(); > 1769 } > > ... > > 1775 if (_concurrent_class_unloading) { > 1776 MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); > 1777 _nmethod_itr.nmethods_do_end(); > 1778 } > This is the current usage pattern, shenandoahNMethods not taking any locks. If indeed need to be changed, should be a followup CR. > *) Double new-line here: > > 2916 try_inject_alloc_failure(); > 2917 op_class_unloading(); > 2918 } > 2919 > 2920 > Fixed. Updated: http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.01/ Thanks, -Zhengyu > From rkennke at redhat.com Wed Apr 22 16:28:40 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 22 Apr 2020 18:28:40 +0200 Subject: [15] RFR 8243200: Shenandoah: Allow concurrent nmethod iteration In-Reply-To: <225b738b-5162-d8a6-e820-869f73423325@redhat.com> References: <8d1d0e47-ca5a-1b69-8385-0a9fb392b88f@redhat.com> <225b738b-5162-d8a6-e820-869f73423325@redhat.com> Message-ID: <14fd5e65-fad3-8ddb-39f1-953ac1a62728@redhat.com> It looks good to me. Roman > Hi, > >> >> I just realize that this are chances to double free old table, so this >> patch needs additional work. I would like to withdraw this RFR for now. > > Abstracting the list for holding Shenandoah NMethod data into a class > and reference counting the list. > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243200/webrev.01/ > > Test: > ? hotspot_gc_shenandoah > > Thanks, > > -Zhengyu > >> >> -Zhengyu >> >> On 4/21/20 3:46 AM, Aleksey Shipilev wrote: >>> On 4/20/20 10:27 PM, Zhengyu Gu wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243200 >>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243200/webrev.00/ >>> >>> Our code style does not allow spaces before postfix operators: >>> ? 471?? _itr_cnt ++; >>> ... >>> ? 478?? _itr_cnt --; >>> >>> Otherwise looks fine. No need for another webrev. >>> > From shade at redhat.com Wed Apr 22 18:11:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 20:11:56 +0200 Subject: [15] RFR 8243200: Shenandoah: Allow concurrent nmethod iteration In-Reply-To: <225b738b-5162-d8a6-e820-869f73423325@redhat.com> References: <8d1d0e47-ca5a-1b69-8385-0a9fb392b88f@redhat.com> <225b738b-5162-d8a6-e820-869f73423325@redhat.com> Message-ID: <1072aaf9-77a7-6975-edd2-61483ea31ce3@redhat.com> On 4/21/20 9:32 PM, Zhengyu Gu wrote: > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243200/webrev.01/ Looks fine. -- Thanks, -Aleksey From shade at redhat.com Wed Apr 22 18:13:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 20:13:57 +0200 Subject: [15] RFR 8243323: Shenandoah: Recycle immediate garbage before concurrent class unloading In-Reply-To: References: <8f957e1d-3ef5-bb8e-a2a0-a3eb3be79bf5@redhat.com> <491a1c42-f689-db18-8d34-eb690b9f9f48@redhat.com> Message-ID: <7d32779a-bd1a-44e3-10c6-bd2d32580920@redhat.com> On 4/22/20 5:07 PM, Zhengyu Gu wrote: >> *) This is awkward, why does it piggyback on is_concurrent_weak_root_in_progress? It should probably >> have its own flag, and that flag should only be set when SCR::should_do_concurrent_class_unloading() >> is true. ... > http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.01/ Looks better. It still does not answer the question why don't we do the separate flag for concurrent_class_unloading (see above), which AFAIU would eliminate awkwardness like this: 1823 if (!ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) { 1824 set_concurrent_weak_root_in_progress(false); 1825 } -- Thanks, -Aleksey From zgu at redhat.com Wed Apr 22 19:16:01 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 22 Apr 2020 15:16:01 -0400 Subject: [15] RFR 8243323: Shenandoah: Recycle immediate garbage before concurrent class unloading In-Reply-To: <7d32779a-bd1a-44e3-10c6-bd2d32580920@redhat.com> References: <8f957e1d-3ef5-bb8e-a2a0-a3eb3be79bf5@redhat.com> <491a1c42-f689-db18-8d34-eb690b9f9f48@redhat.com> <7d32779a-bd1a-44e3-10c6-bd2d32580920@redhat.com> Message-ID: On 4/22/20 2:13 PM, Aleksey Shipilev wrote: > On 4/22/20 5:07 PM, Zhengyu Gu wrote: >>> *) This is awkward, why does it piggyback on is_concurrent_weak_root_in_progress? It should probably >>> have its own flag, and that flag should only be set when SCR::should_do_concurrent_class_unloading() >>> is true. > > ... > >> http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.01/ > > Looks better. It still does not answer the question why don't we do the separate flag for > concurrent_class_unloading (see above), which AFAIU would eliminate awkwardness like this: > I am thinking about degen entry after weak roots, to avoid trying to evacuate nmethod metadata, which may be fruitless. So, these code will need to further be tweaked ... Let's wait to see if we need another flag, ok? Thanks, -Zhengyu From shade at redhat.com Wed Apr 22 19:17:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 21:17:50 +0200 Subject: [15] RFR 8243323: Shenandoah: Recycle immediate garbage before concurrent class unloading In-Reply-To: References: <8f957e1d-3ef5-bb8e-a2a0-a3eb3be79bf5@redhat.com> <491a1c42-f689-db18-8d34-eb690b9f9f48@redhat.com> <7d32779a-bd1a-44e3-10c6-bd2d32580920@redhat.com> Message-ID: <0b91864d-4bb8-3ecc-589d-1261d34a35f2@redhat.com> On 4/22/20 9:16 PM, Zhengyu Gu wrote: > On 4/22/20 2:13 PM, Aleksey Shipilev wrote: >> On 4/22/20 5:07 PM, Zhengyu Gu wrote: >>>> *) This is awkward, why does it piggyback on is_concurrent_weak_root_in_progress? It should probably >>>> have its own flag, and that flag should only be set when SCR::should_do_concurrent_class_unloading() >>>> is true. >> >> ... >> >>> http://cr.openjdk.java.net/~zgu/JDK-8243323/webrev.01/ >> >> Looks better. It still does not answer the question why don't we do the separate flag for >> concurrent_class_unloading (see above), which AFAIU would eliminate awkwardness like this: >> > > I am thinking about degen entry after weak roots, to avoid trying to > evacuate nmethod metadata, which may be fruitless. So, these code will > need to further be tweaked ... > > Let's wait to see if we need another flag, ok? All right, fine then. -- Thanks, -Aleksey From shade at redhat.com Thu Apr 23 05:50:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 07:50:51 +0200 Subject: RFR (XS) 8243460: Shenandoah: purge init_update_refs_prepare counter Message-ID: <207340c3-e67d-2bf1-9a8d-77618f9d0b98@redhat.com> Simple RFE: https://bugs.openjdk.java.net/browse/JDK-8243460 After JDK-8243291, init_update_refs_prepare counter is effectively zero on most paths and does not carry its weight. Removing it unclutters the logs. Fix: diff -r 4103af83d98e src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Thu Apr 23 12:14:58 2020 +0900 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Thu Apr 23 07:50:01 2020 +0200 @@ -2507,8 +2507,5 @@ set_update_refs_in_progress(true); - { - ShenandoahGCSubPhase phase(ShenandoahPhaseTimings::init_update_refs_prepare); - _update_refs_iterator.reset(); - } + _update_refs_iterator.reset(); if (ShenandoahPacing) { diff -r 4103af83d98e src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 12:14:58 2020 +0900 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 07:50:01 2020 +0200 @@ -91,5 +91,4 @@ f(init_update_refs, "Pause Init Update Refs (N)") \ f(init_update_refs_retire_gclabs, " Retire GCLABs") \ - f(init_update_refs_prepare, " Prepare") \ \ f(final_update_refs_gross, "Pause Final Update Refs (G)") \ -- Thanks, -Aleksey From shade at redhat.com Thu Apr 23 06:31:54 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 08:31:54 +0200 Subject: RFR (XS) 8243463: Shenandoah: ditch total_pause counters Message-ID: <1bd360a3-ea32-2b78-d6e3-d28e39d446da@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8243463 total_pause counters make ShenandoahGCPhase nesting awkward, and also take the timing measurement twice on common path. They are also not very convenient, because they average over completely different pauses. We should consider removing these counters. It would also help future work on per-cycle counters printout, where total-pauses make little sense. Fix: diff -r 6c14c6b234ed src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Thu Apr 23 07:49:52 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Thu Apr 23 08:31:29 2020 +0200 @@ -2693,3 +2693,2 @@ TraceCollectorStats tcs(monitoring_support()->stw_collection_counters()); - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); ShenandoahGCPhase phase(ShenandoahPhaseTimings::init_mark_gross); @@ -2703,3 +2702,2 @@ TraceCollectorStats tcs(monitoring_support()->stw_collection_counters()); - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); ShenandoahGCPhase phase(ShenandoahPhaseTimings::final_mark_gross); @@ -2713,3 +2711,2 @@ TraceCollectorStats tcs(monitoring_support()->stw_collection_counters()); - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); ShenandoahGCPhase phase(ShenandoahPhaseTimings::init_update_refs_gross); @@ -2723,3 +2720,2 @@ TraceCollectorStats tcs(monitoring_support()->stw_collection_counters()); - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); ShenandoahGCPhase phase(ShenandoahPhaseTimings::final_update_refs_gross); @@ -2733,3 +2729,2 @@ TraceCollectorStats tcs(monitoring_support()->full_stw_collection_counters()); - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); ShenandoahGCPhase phase(ShenandoahPhaseTimings::full_gc_gross); @@ -2743,3 +2738,2 @@ TraceCollectorStats tcs(monitoring_support()->full_stw_collection_counters()); - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); ShenandoahGCPhase phase(ShenandoahPhaseTimings::degen_gc_gross); @@ -2755,3 +2749,2 @@ - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); ShenandoahGCPhase phase(ShenandoahPhaseTimings::init_mark); @@ -2770,3 +2763,2 @@ - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); ShenandoahGCPhase phase(ShenandoahPhaseTimings::final_mark); @@ -2785,3 +2777,2 @@ - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); ShenandoahGCPhase phase(ShenandoahPhaseTimings::init_update_refs); @@ -2798,3 +2789,2 @@ - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); ShenandoahGCPhase phase(ShenandoahPhaseTimings::final_update_refs); @@ -2813,3 +2803,2 @@ - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); ShenandoahGCPhase phase(ShenandoahPhaseTimings::full_gc); @@ -2829,3 +2818,2 @@ - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); ShenandoahGCPhase phase(ShenandoahPhaseTimings::degen_gc); diff -r 6c14c6b234ed src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 07:49:52 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 08:31:29 2020 +0200 @@ -59,5 +59,2 @@ #define SHENANDOAH_GC_PHASE_DO(f) \ - f(total_pause_gross, "Total Pauses (G)") \ - f(total_pause, "Total Pauses (N)") \ - \ f(init_mark_gross, "Pause Init Mark (G)") \ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Thu Apr 23 06:48:40 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 08:48:40 +0200 Subject: RFR (S) 8243464: Shenandoah: print statistic counters in time order Message-ID: <85874e7e-d720-c955-0279-f54a63dd4e20@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8243464 Currently, the gc+stats counters table is printed pauses-first, then all concurrent phases. It is inconvenient to track the entire cycle, and should probably be reshuffled to match the time ordering of phases. This would become handy for per-cycle statistics printouts. Fix: https://cr.openjdk.java.net/~shade/8243464/wevrev.01/ Testing: hotspot_gc_shenandoah, eyeballing logs -- Thanks, -Aleksey From shade at redhat.com Thu Apr 23 06:55:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 08:55:24 +0200 Subject: RFR (XS) 8243465: Shenandoah: ditch unused pause_other, conc_other counters Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243465 Spotted another leftover. There are two counters: pause_other, conc_other that are unused. They were there to cater for quick development work, but then every time we just added the temporary counters instead. We should remove these for clarity. Fix: diff -r a829b346e89f src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 08:44:49 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 08:54:34 2020 +0200 @@ -145,8 +145,4 @@ \ f(conc_uncommit, "Concurrent Uncommit") \ - \ - /* Unclassified */ \ - f(pause_other, "Pause Other") \ - f(conc_other, "Concurrent Other") \ // end Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 23 08:30:04 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 10:30:04 +0200 Subject: RFR (XS) 8243460: Shenandoah: purge init_update_refs_prepare counter In-Reply-To: <207340c3-e67d-2bf1-9a8d-77618f9d0b98@redhat.com> References: <207340c3-e67d-2bf1-9a8d-77618f9d0b98@redhat.com> Message-ID: Ok. Roman > Simple RFE: > https://bugs.openjdk.java.net/browse/JDK-8243460 > > After JDK-8243291, init_update_refs_prepare counter is effectively zero on most paths and does not > carry its weight. Removing it unclutters the logs. > > Fix: > > diff -r 4103af83d98e src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Thu Apr 23 12:14:58 2020 +0900 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Thu Apr 23 07:50:01 2020 +0200 > @@ -2507,8 +2507,5 @@ > set_update_refs_in_progress(true); > > - { > - ShenandoahGCSubPhase phase(ShenandoahPhaseTimings::init_update_refs_prepare); > - _update_refs_iterator.reset(); > - } > + _update_refs_iterator.reset(); > > if (ShenandoahPacing) { > diff -r 4103af83d98e src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 12:14:58 2020 +0900 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 07:50:01 2020 +0200 > @@ -91,5 +91,4 @@ > f(init_update_refs, "Pause Init Update Refs (N)") \ > f(init_update_refs_retire_gclabs, " Retire GCLABs") \ > - f(init_update_refs_prepare, " Prepare") \ > \ > f(final_update_refs_gross, "Pause Final Update Refs (G)") \ > From rkennke at redhat.com Thu Apr 23 08:31:44 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 10:31:44 +0200 Subject: RFR (XS) 8243463: Shenandoah: ditch total_pause counters In-Reply-To: <1bd360a3-ea32-2b78-d6e3-d28e39d446da@redhat.com> References: <1bd360a3-ea32-2b78-d6e3-d28e39d446da@redhat.com> Message-ID: <69d569e4-8e83-e5b2-aca4-6f6439ab2b27@redhat.com> Ok. I kinda liked them as a first-glance measure, but they are not *so* useful after all. Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243463 > > total_pause counters make ShenandoahGCPhase nesting awkward, and also take the timing measurement > twice on common path. They are also not very convenient, because they average over completely > different pauses. We should consider removing these counters. It would also help future work on > per-cycle counters printout, where total-pauses make little sense. > > Fix: > > diff -r 6c14c6b234ed src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Thu Apr 23 07:49:52 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Thu Apr 23 08:31:29 2020 +0200 > @@ -2693,3 +2693,2 @@ > TraceCollectorStats tcs(monitoring_support()->stw_collection_counters()); > - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::init_mark_gross); > @@ -2703,3 +2702,2 @@ > TraceCollectorStats tcs(monitoring_support()->stw_collection_counters()); > - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::final_mark_gross); > @@ -2713,3 +2711,2 @@ > TraceCollectorStats tcs(monitoring_support()->stw_collection_counters()); > - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::init_update_refs_gross); > @@ -2723,3 +2720,2 @@ > TraceCollectorStats tcs(monitoring_support()->stw_collection_counters()); > - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::final_update_refs_gross); > @@ -2733,3 +2729,2 @@ > TraceCollectorStats tcs(monitoring_support()->full_stw_collection_counters()); > - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::full_gc_gross); > @@ -2743,3 +2738,2 @@ > TraceCollectorStats tcs(monitoring_support()->full_stw_collection_counters()); > - ShenandoahGCPhase total(ShenandoahPhaseTimings::total_pause_gross); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::degen_gc_gross); > @@ -2755,3 +2749,2 @@ > > - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::init_mark); > @@ -2770,3 +2763,2 @@ > > - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::final_mark); > @@ -2785,3 +2777,2 @@ > > - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::init_update_refs); > @@ -2798,3 +2789,2 @@ > > - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::final_update_refs); > @@ -2813,3 +2803,2 @@ > > - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::full_gc); > @@ -2829,3 +2818,2 @@ > > - ShenandoahGCPhase total_phase(ShenandoahPhaseTimings::total_pause); > ShenandoahGCPhase phase(ShenandoahPhaseTimings::degen_gc); > diff -r 6c14c6b234ed src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 07:49:52 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 08:31:29 2020 +0200 > @@ -59,5 +59,2 @@ > #define SHENANDOAH_GC_PHASE_DO(f) \ > - f(total_pause_gross, "Total Pauses (G)") \ > - f(total_pause, "Total Pauses (N)") \ > - \ > f(init_mark_gross, "Pause Init Mark (G)") \ > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Thu Apr 23 08:32:58 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 10:32:58 +0200 Subject: RFR (S) 8243464: Shenandoah: print statistic counters in time order In-Reply-To: <85874e7e-d720-c955-0279-f54a63dd4e20@redhat.com> References: <85874e7e-d720-c955-0279-f54a63dd4e20@redhat.com> Message-ID: Yes, this is much clearer. Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243464 > > Currently, the gc+stats counters table is printed pauses-first, then all concurrent phases. It is > inconvenient to track the entire cycle, and should probably be reshuffled to match the time ordering > of phases. This would become handy for per-cycle statistics printouts. > > Fix: > https://cr.openjdk.java.net/~shade/8243464/wevrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing logs > From rkennke at redhat.com Thu Apr 23 08:33:24 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 10:33:24 +0200 Subject: RFR (XS) 8243465: Shenandoah: ditch unused pause_other, conc_other counters In-Reply-To: References: Message-ID: <7b7a1d55-ea02-d46a-1cec-d9e70f7915a2@redhat.com> Yes. Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243465 > > Spotted another leftover. There are two counters: pause_other, conc_other that are unused. They were > there to cater for quick development work, but then every time we just added the temporary counters > instead. We should remove these for clarity. > > Fix: > > diff -r a829b346e89f src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 08:44:49 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Thu Apr 23 08:54:34 2020 +0200 > @@ -145,8 +145,4 @@ > \ > f(conc_uncommit, "Concurrent Uncommit") \ > - \ > - /* Unclassified */ \ > - f(pause_other, "Pause Other") \ > - f(conc_other, "Concurrent Other") \ > // end > > Testing: hotspot_gc_shenandoah > From zgu at redhat.com Thu Apr 23 13:52:47 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 23 Apr 2020 09:52:47 -0400 Subject: [15] RFR 8243478: Shenandoah: avoid implicit worker_id = 0 Message-ID: <2f094663-5363-9d74-977a-f3058d5f68f8@redhat.com> Please review this small patch that removes default worker_id parameters. Bug: https://bugs.openjdk.java.net/browse/JDK-8243478 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243478/webrev.00/ Test: hotspot_gc_shenandoah in progress Thanks, -Zhengyu From shade at redhat.com Thu Apr 23 13:54:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 15:54:16 +0200 Subject: RFR (XS) 8243487: Shenandoah: make _num_phases illegal phase type Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243487 This gets into the way, requiring special-casing in many places in future code. Webrev: https://cr.openjdk.java.net/~shade/8243487/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Thu Apr 23 13:58:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 15:58:51 +0200 Subject: [15] RFR 8243478: Shenandoah: avoid implicit worker_id = 0 In-Reply-To: <2f094663-5363-9d74-977a-f3058d5f68f8@redhat.com> References: <2f094663-5363-9d74-977a-f3058d5f68f8@redhat.com> Message-ID: On 4/23/20 3:52 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8243478 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243478/webrev.00/ Looks good! -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 23 14:06:37 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 16:06:37 +0200 Subject: Bulk backports to sh/jdk8 Message-ID: <65bf7a1b-cdf9-83cc-93e9-077367b7f620@redhat.com> This backports I-U and a bunch of related and unrelated fixes to sh/jdk8: Changesets: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-04-23/changesets.txt Full webrev: http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-04-23/webrev.00/ Testing: hotspot_gc_shenandoah (x86, aarch64) Ok? Roman From rkennke at redhat.com Thu Apr 23 14:09:11 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 16:09:11 +0200 Subject: RFR (XS) 8243487: Shenandoah: make _num_phases illegal phase type In-Reply-To: References: Message-ID: <4817d83b-5598-55d5-5735-3b5744082f0b@redhat.com> Looks good. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243487 > > This gets into the way, requiring special-casing in many places in future code. > > Webrev: > https://cr.openjdk.java.net/~shade/8243487/webrev.01/ > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Thu Apr 23 14:19:49 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 16:19:49 +0200 Subject: Bulk backports to sh/jdk8 In-Reply-To: <65bf7a1b-cdf9-83cc-93e9-077367b7f620@redhat.com> References: <65bf7a1b-cdf9-83cc-93e9-077367b7f620@redhat.com> Message-ID: <2ac347cb-d611-eafc-3e23-fe029d72a6d6@redhat.com> On 4/23/20 4:06 PM, Roman Kennke wrote: > Changesets: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-04-23/changesets.txt > > Full webrev: > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-04-23/webrev.00/ > > Testing: hotspot_gc_shenandoah (x86, aarch64) *) Please grep for leftover ShenandoahKeepAliveBarrier in source code? 8u might have some surprises there, for example in x86_32 parts; *) Indent is a bit off in shenandoahConcurrentMark.cpp here: 220 ShenandoahSATBBufferClosure* _satb_cl; 221 OopClosure* const _cl; 222 MarkingCodeBlobClosure* _code_cl; *) Not related to this backport. But looking at for example TestClassLoaderLeak.java, it looks to me IU can use the same bundle of heuristics like normal mode uses. Probably something to fix in upstream and let it trickle? 125 String[][][] modeHeuristics = new String[][][] { 126 {{"normal"}, {"adaptive", "compact", "static", "aggressive"}}, 127 {{"iu"}, {"adaptive", "aggressive"}}, 128 {{"passive"}, {"passive"}} *) In new tests, does it not complain about vm.gc.Shenandoah and vm.graal.enabled flags? IIRC, not all test flags are available in 8u, and that's why test backports remove those lines... Otherwise good! -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 23 14:46:28 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 16:46:28 +0200 Subject: Bulk backports to sh/jdk8 In-Reply-To: <2ac347cb-d611-eafc-3e23-fe029d72a6d6@redhat.com> References: <65bf7a1b-cdf9-83cc-93e9-077367b7f620@redhat.com> <2ac347cb-d611-eafc-3e23-fe029d72a6d6@redhat.com> Message-ID: <1a1d2885-b159-458e-7f26-f0bc15ed40c7@redhat.com> >> Changesets: >> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-04-23/changesets.txt >> >> Full webrev: >> http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-04-23/webrev.00/ >> >> Testing: hotspot_gc_shenandoah (x86, aarch64) > > *) Please grep for leftover ShenandoahKeepAliveBarrier in source code? 8u might have some surprises > there, for example in x86_32 parts; No, nothing. > *) Indent is a bit off in shenandoahConcurrentMark.cpp here: > > 220 ShenandoahSATBBufferClosure* _satb_cl; > 221 OopClosure* const _cl; > 222 MarkingCodeBlobClosure* _code_cl; Right. Fixed. > *) Not related to this backport. But looking at for example TestClassLoaderLeak.java, it looks to me > IU can use the same bundle of heuristics like normal mode uses. Probably something to fix in > upstream and let it trickle? > > 125 String[][][] modeHeuristics = new String[][][] { > 126 {{"normal"}, {"adaptive", "compact", "static", "aggressive"}}, > 127 {{"iu"}, {"adaptive", "aggressive"}}, > 128 {{"passive"}, {"passive"}} Yeah, let's do that separately. > *) In new tests, does it not complain about vm.gc.Shenandoah and vm.graal.enabled flags? IIRC, not > all test flags are available in 8u, and that's why test backports remove those lines... Right. Also, needed to fix the @library tags. http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-04-23/webrev.01/ Good now? Roman From shade at redhat.com Thu Apr 23 15:07:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 17:07:25 +0200 Subject: Bulk backports to sh/jdk8 In-Reply-To: <1a1d2885-b159-458e-7f26-f0bc15ed40c7@redhat.com> References: <65bf7a1b-cdf9-83cc-93e9-077367b7f620@redhat.com> <2ac347cb-d611-eafc-3e23-fe029d72a6d6@redhat.com> <1a1d2885-b159-458e-7f26-f0bc15ed40c7@redhat.com> Message-ID: <8c86b05d-2fcb-719c-8ec7-74c3e25dc568@redhat.com> On 4/23/20 4:46 PM, Roman Kennke wrote: >> *) In new tests, does it not complain about vm.gc.Shenandoah and vm.graal.enabled flags? IIRC, not >> all test flags are available in 8u, and that's why test backports remove those lines... > > Right. Also, needed to fix the @library tags. > > http://cr.openjdk.java.net/~rkennke/backport-shjdk8-2020-04-23/webrev.01/ > > Good now? I believe you also need to fix the imports for testlibrary to, say: import com.oracle.java.testlibrary.*; Otherwise good, no need for another webrev. -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 23 16:20:18 2020 From: rkennke at redhat.com (rkennke at redhat.com) Date: Thu, 23 Apr 2020 16:20:18 +0000 Subject: hg: shenandoah/jdk8/hotspot: 10 new changesets Message-ID: <202004231620.03NGKI0M008437@aojmv0008.oracle.com> Changeset: df62c177841e Author: zgu Date: 2020-02-25 12:01 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/df62c177841e [backport] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata Reviewed-by: rkennke, shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: c30b6a2e27c4 Author: roland Date: 2020-03-24 10:31 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c30b6a2e27c4 [backport] 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: f33666b9f05e Author: rkennke Date: 2020-03-27 12:47 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f33666b9f05e [backport] 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier Reviewed-by: shade ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/jniHandles.cpp ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: fcf19e0cd2c1 Author: rkennke Date: 2020-04-06 13:45 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/fcf19e0cd2c1 [backport] 8242130: Shenandoah: Simplify arraycopy-barrier dispatching Reviewed-by: shade ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/oops/objArrayKlass.cpp Changeset: fb9ff8b01d3a Author: rkennke Date: 2020-04-06 16:29 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/fb9ff8b01d3a [backport] 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.hpp Changeset: a222813e5654 Author: rkennke Date: 2020-04-06 17:08 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a222813e5654 [backport] 8242054: Shenandoah: New incremental-update mode Reviewed-by: shade ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahIUMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahIUMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/prims/jvm.cpp ! 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/TestPeriodicGC.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/TestWrongArrayMember.java ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestExplicitGC.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: 2c1c49f2dc23 Author: shade Date: 2020-04-07 13:18 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2c1c49f2dc23 [backport] 8242271: Shenandoah: add test to verify GC mode unlock Reviewed-by: rkennke + test/gc/shenandoah/options/TestModeUnlock.java Changeset: 3bfbc781e7ab Author: shade Date: 2020-04-07 13:18 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3bfbc781e7ab [backport] 8242273: Shenandoah: accept either SATB or IU barriers, but not both Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahIUMode.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp ! test/gc/shenandoah/options/TestWrongBarrierDisable.java + test/gc/shenandoah/options/TestWrongBarrierEnable.java Changeset: 3705749eb8c2 Author: rkennke Date: 2020-04-07 22:31 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3705749eb8c2 [backport] 8242301: Shenandoah: Inline LRB runtime call Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp Changeset: b78de392a7a4 Author: rkennke Date: 2020-04-08 11:26 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b78de392a7a4 [backport] 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry Reviewed-by: zgu, shade ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp From shade at redhat.com Thu Apr 23 17:19:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 19:19:27 +0200 Subject: RFR (S) 8243494: Shenandoah: set counters once per cycle Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243494 There are several places where we reuse the counters for different purposes, for example full_gc_roots. There are places where we accidentally count things twice, for example conc_mark. It would be hard-checked by JDK-8239786, so we need to fix it before then. Fix: https://cr.openjdk.java.net/~shade/8243494/webrev.01/ Testing: hotspot_gc_shenandoah, eyeballing logs -- Thanks, -Aleksey From zgu at redhat.com Thu Apr 23 18:04:09 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 23 Apr 2020 14:04:09 -0400 Subject: RFR (S) 8243494: Shenandoah: set counters once per cycle In-Reply-To: References: Message-ID: Looks good. -Zhengyu On 4/23/20 1:19 PM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243494 > > There are several places where we reuse the counters for different purposes, for example > full_gc_roots. There are places where we accidentally count things twice, for example conc_mark. It > would be hard-checked by JDK-8239786, so we need to fix it before then. > > Fix: > https://cr.openjdk.java.net/~shade/8243494/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing logs > From shade at redhat.com Thu Apr 23 19:43:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 21:43:56 +0200 Subject: RFR (M) 8239786: Shenandoah: print per-cycle statistics Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8239786 A brief tour: *) ShPhaseTimings now collects worker data and cycle data into the separate counters that are populated once per cycle. ShControlThread is then responsible for merging and printing out that data. *) We still have "global" view that is printed at the end of the run, but we also have "cycle" view that is printed after each cycle. Note that printing is outside of any pause, and so the logging is effectively asynchronous! *) Where possible, "cycle" view shows the per-worker statistics. Webrev: https://cr.openjdk.java.net/~shade/8239786/webrev.01/ Sample piece of GC log: https://cr.openjdk.java.net/~shade/8239786/gc-log-sample.txt Testing: hotspot_gc_shenandoah, eyeballing logs; more aggressive testing is running -- Thanks, -Aleksey From shade at redhat.com Thu Apr 23 19:48:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Apr 2020 21:48:58 +0200 Subject: RFR (S) 8243495: Shenandoah: print root statistics for concurrent weak/strong root phases Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243495 This is a follow up for the base work laid in JDK-8239786. We can now make more verbose concurrent phases logging, at least when roots are concerned. Webrev: https://cr.openjdk.java.net/~shade/8243495/webrev.01/ Sample piece of GC log: https://cr.openjdk.java.net/~shade/8243495/gc-log-sample.txt Testing: hotspot_gc_shenandoah, eyeballing logs; more aggressive testing is running -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 23 20:30:58 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 22:30:58 +0200 Subject: RFR (M) 8239786: Shenandoah: print per-cycle statistics In-Reply-To: References: Message-ID: Do I see it correctly that we get this with -Xlog:gc+stats=info ? I.e. the same that gives us the end-of-run-stats? Might that be too spammy for info? Maybe wire it to 'trace' instead? The output is absolutely nice and very useful! Well done! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8239786 > > A brief tour: > *) ShPhaseTimings now collects worker data and cycle data into the separate counters that are > populated once per cycle. ShControlThread is then responsible for merging and printing out that data. > *) We still have "global" view that is printed at the end of the run, but we also have "cycle" view > that is printed after each cycle. Note that printing is outside of any pause, and so the logging is > effectively asynchronous! > *) Where possible, "cycle" view shows the per-worker statistics. > > Webrev: > https://cr.openjdk.java.net/~shade/8239786/webrev.01/ > > Sample piece of GC log: > https://cr.openjdk.java.net/~shade/8239786/gc-log-sample.txt > > Testing: hotspot_gc_shenandoah, eyeballing logs; more aggressive testing is running > From rkennke at redhat.com Thu Apr 23 20:37:37 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 23 Apr 2020 22:37:37 +0200 Subject: RFR (S) 8243495: Shenandoah: print root statistics for concurrent weak/strong root phases In-Reply-To: References: Message-ID: <0ab667a7-92c3-4aae-b0a4-f1a522c89007@redhat.com> Great!! Do we still need both SINGLE_THREADED *and* CONCURRENT any longer? ShenandoahClassLoaderDataRoots Other than that, looks very good. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243495 > > This is a follow up for the base work laid in JDK-8239786. We can now make more verbose concurrent > phases logging, at least when roots are concerned. > > Webrev: > https://cr.openjdk.java.net/~shade/8243495/webrev.01/ > > Sample piece of GC log: > https://cr.openjdk.java.net/~shade/8243495/gc-log-sample.txt > > Testing: hotspot_gc_shenandoah, eyeballing logs; more aggressive testing is running > From shade at redhat.com Fri Apr 24 05:49:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Apr 2020 07:49:35 +0200 Subject: RFR (S) 8243495: Shenandoah: print root statistics for concurrent weak/strong root phases In-Reply-To: <0ab667a7-92c3-4aae-b0a4-f1a522c89007@redhat.com> References: <0ab667a7-92c3-4aae-b0a4-f1a522c89007@redhat.com> Message-ID: <4e1ec826-bd4d-1b0c-f693-f0b53b8a57f0@redhat.com> On 4/23/20 10:37 PM, Roman Kennke wrote: > Do we still need both SINGLE_THREADED *and* CONCURRENT any longer? > ShenandoahClassLoaderDataRoots Yes, I think so, because CONCURRENT is used for other things, like locking. -- Thanks, -Aleksey From shade at redhat.com Fri Apr 24 09:25:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Apr 2020 11:25:28 +0200 Subject: RFR (M) 8239786: Shenandoah: print per-cycle statistics In-Reply-To: References: Message-ID: On 4/23/20 10:30 PM, Roman Kennke wrote: > Do I see it correctly that we get this with -Xlog:gc+stats=info ? I.e. > the same that gives us the end-of-run-stats? Might that be too spammy > for info? Maybe wire it to 'trace' instead? I would prefer to keep it gc+stats=info, for several reasons: *) gc+stats is not enabled by default, and it is inherently opt-in; *) this logging is asynchronous, so bulk printing does not come with performance overhead; *) "trace" is usually for very fine-grained tracing, and this is rather high level. *) I think ZGC prints out the similar bunch of counters under gc+stats as well; This might change once we reshuffle logging further... I updated webrev a bit (copyrights, excess headers): https://cr.openjdk.java.net/~shade/8239786/webrev.02/ Ok? -- Thanks, -Aleksey From rkennke at redhat.com Fri Apr 24 09:31:56 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Apr 2020 11:31:56 +0200 Subject: RFR (M) 8239786: Shenandoah: print per-cycle statistics In-Reply-To: References: Message-ID: <198603bf-5bcd-7413-b744-7ee5152816b1@redhat.com> >> Do I see it correctly that we get this with -Xlog:gc+stats=info ? I.e. >> the same that gives us the end-of-run-stats? Might that be too spammy >> for info? Maybe wire it to 'trace' instead? > > I would prefer to keep it gc+stats=info, for several reasons: > *) gc+stats is not enabled by default, and it is inherently opt-in; > *) this logging is asynchronous, so bulk printing does not come with performance overhead; > *) "trace" is usually for very fine-grained tracing, and this is rather high level. > *) I think ZGC prints out the similar bunch of counters under gc+stats as well; Ok. > This might change once we reshuffle logging further... > > I updated webrev a bit (copyrights, excess headers): > https://cr.openjdk.java.net/~shade/8239786/webrev.02/ > > Ok? Ok! Thank you, Roman From zgu at redhat.com Fri Apr 24 16:50:07 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 24 Apr 2020 12:50:07 -0400 Subject: [15] RFR 8243564: Shenandoah: Add degen entry after concurrent weak roots Message-ID: When Shenandoah encounters OOM during concurrent weak roots, it is better and cheaper to enter degenerated GC and perform STW class unloading than concurrent class unloading. Bug: https://bugs.openjdk.java.net/browse/JDK-8243564 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243564/webrev.00/index.html Test: hotspot_gc_shenandoah tier1 with Shenandoah GC Thanks, -Zhengyu From shade at redhat.com Fri Apr 24 18:42:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Apr 2020 20:42:33 +0200 Subject: [15] RFR 8243564: Shenandoah: Add degen entry after concurrent weak roots In-Reply-To: References: Message-ID: <60eb1c47-7de1-17b8-d078-51f2b9b5a660@redhat.com> On 4/24/20 6:50 PM, Zhengyu Gu wrote: > When Shenandoah encounters OOM during concurrent weak roots, it is > better and cheaper to enter degenerated GC and perform STW class > unloading than concurrent class unloading. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243564 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243564/webrev.00/index.html This looks good, except a few nits: *) Shouldn't we still drop the flags in ShenandoahMarkCompact::do_it? The code in full_gc_prepare block below makes a point to drop all the flags when going into Full GC. *) In op_degenerated here, shouldn't we check for is_concurrent_unloading_in_progress instead? 1948 if (!has_forwarded_objects() && ShenandoahConcurrentRoots::can_do_concurrent_class_unloading()) { *) In op_degenerated, I think the point was to call op_*(). Why can't we call op_conc_class_unloading() and remove this whole block? 1957 // No fallthrough 1958 if (point == _degenerated_weak_roots) { 1959 // Perform STW class unloading 1960 if (is_concurrent_class_unloading_in_progress()) { 1961 stw_unload_classes(false /* full gc*/); 1962 set_concurrent_class_unloading_in_progress(false); 1963 } 1964 1965 // cleanup flags that may be carried into degenerated GC 1966 set_concurrent_weak_root_in_progress(false); 1967 set_concurrent_strong_root_in_progress(false); 1968 } 1969 -- Thanks, -Aleksey From shade at redhat.com Fri Apr 24 19:13:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Apr 2020 21:13:05 +0200 Subject: RFR (S) 8243573: Shenandoah: rename GCParPhases and related code Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8243573 ShenandoahPhaseTimings::GCParPhases is awkward: it is plural and it carries unnecessary "GC" prefix. Should be just ShenandoahPhaseTimings::ParPhase. This also matches the local variables "par_phase" to be used to store it, in contrast with just "phase" for ShenandoahPhaseTimings::Phase. Webrev: https://cr.openjdk.java.net/~shade/8243573/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Fri Apr 24 19:11:39 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 24 Apr 2020 15:11:39 -0400 Subject: [15] RFR 8243564: Shenandoah: Add degen entry after concurrent weak roots In-Reply-To: <60eb1c47-7de1-17b8-d078-51f2b9b5a660@redhat.com> References: <60eb1c47-7de1-17b8-d078-51f2b9b5a660@redhat.com> Message-ID: <42d9c50e-ad50-0a52-ab49-271782c7f738@redhat.com> On 4/24/20 2:42 PM, Aleksey Shipilev wrote: > On 4/24/20 6:50 PM, Zhengyu Gu wrote: >> When Shenandoah encounters OOM during concurrent weak roots, it is >> better and cheaper to enter degenerated GC and perform STW class >> unloading than concurrent class unloading. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243564 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243564/webrev.00/index.html > > This looks good, except a few nits: > > *) Shouldn't we still drop the flags in ShenandoahMarkCompact::do_it? The code in full_gc_prepare > block below makes a point to drop all the flags when going into Full GC. > _degenerated_weak_roots is the only entry point that carries flags, we cleanup those flags there. > *) In op_degenerated here, shouldn't we check for is_concurrent_unloading_in_progress instead? > 1948 if (!has_forwarded_objects() && > ShenandoahConcurrentRoots::can_do_concurrent_class_unloading()) { We are trying to disarm nmethods that armed for concurrent marking. If we get to here due to degenerated_mark, is_concurrent_unloading_in_progress flag may not be set, but we still need to disarm nmethods here. > > *) In op_degenerated, I think the point was to call op_*(). Why can't we call > op_conc_class_unloading() and remove this whole block? > > 1957 // No fallthrough > 1958 if (point == _degenerated_weak_roots) { > 1959 // Perform STW class unloading > 1960 if (is_concurrent_class_unloading_in_progress()) { > 1961 stw_unload_classes(false /* full gc*/); > 1962 set_concurrent_class_unloading_in_progress(false); > 1963 } > 1964 > 1965 // cleanup flags that may be carried into degenerated GC > 1966 set_concurrent_weak_root_in_progress(false); > 1967 set_concurrent_strong_root_in_progress(false); > 1968 } > 1969 > concurrent version is more expensive than STW version (different implementation) -Zhengyu From rkennke at redhat.com Fri Apr 24 19:47:04 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Apr 2020 21:47:04 +0200 Subject: RFR (S) 8243573: Shenandoah: rename GCParPhases and related code In-Reply-To: References: Message-ID: Looks good. Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8243573 > > ShenandoahPhaseTimings::GCParPhases is awkward: it is plural and it carries unnecessary "GC" prefix. > Should be just ShenandoahPhaseTimings::ParPhase. This also matches the local variables "par_phase" > to be used to store it, in contrast with just "phase" for ShenandoahPhaseTimings::Phase. > > Webrev: > https://cr.openjdk.java.net/~shade/8243573/webrev.01/ > > Testing: hotspot_gc_shenandoah > From zgu at redhat.com Fri Apr 24 20:19:34 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 24 Apr 2020 16:19:34 -0400 Subject: [15] RFR 8243578: Shenandoah: Cleanup ShenandoahStringDedup::parallel_oops_do() Message-ID: <0f3248d9-aedc-1bfa-9d5b-11c80acaa8bc@redhat.com> Please review this small cleanup. It removes a branch that works around the problem for traversal GC. Bug: https://bugs.openjdk.java.net/browse/JDK-8243578 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243578/webrev.00/ Test: hotspot_gc_shenandoah -Zhengyu From shade at redhat.com Fri Apr 24 20:30:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Apr 2020 22:30:57 +0200 Subject: [15] RFR 8243578: Shenandoah: Cleanup ShenandoahStringDedup::parallel_oops_do() In-Reply-To: <0f3248d9-aedc-1bfa-9d5b-11c80acaa8bc@redhat.com> References: <0f3248d9-aedc-1bfa-9d5b-11c80acaa8bc@redhat.com> Message-ID: On 4/24/20 10:19 PM, Zhengyu Gu wrote: > Please review this small cleanup. It removes a branch that works around > the problem for traversal GC. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243578 Please link it to "Purge Traversal mode" issue. > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243578/webrev.00/ Looks good! -- Thanks, -Aleksey From zgu at redhat.com Mon Apr 27 21:42:38 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Apr 2020 17:42:38 -0400 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 Message-ID: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Please review this small patch that fixes build problems (size_t => uint type conversion) on Windows. Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ Test: Built on Windows. Thanks, -Zhengyu From rkennke at redhat.com Tue Apr 28 12:26:04 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Apr 2020 14:26:04 +0200 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Message-ID: Would it be more useful to make _max_workers uint to begin with? Roman > Please review this small patch that fixes build problems (size_t => uint > type conversion) on Windows. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ > > Test: > ? Built on Windows. > > Thanks, > > -Zhengyu > From zgu at redhat.com Tue Apr 28 12:33:52 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Apr 2020 08:33:52 -0400 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Message-ID: <6753c058-f153-2621-032d-bfe6fcdcace5@redhat.com> On 4/28/20 8:26 AM, Roman Kennke wrote: > Would it be more useful to make _max_workers uint to begin with? That will have much wider implication, especially, it is derived from ConcGCThreads and ParallelGCThreads, which are uints. So, you will see conversions in other places. -Zhengyu > > Roman > > >> Please review this small patch that fixes build problems (size_t => uint >> type conversion) on Windows. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ >> >> Test: >> ? Built on Windows. >> >> Thanks, >> >> -Zhengyu >> > From rkennke at redhat.com Tue Apr 28 12:46:29 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Apr 2020 14:46:29 +0200 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: <6753c058-f153-2621-032d-bfe6fcdcace5@redhat.com> References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> <6753c058-f153-2621-032d-bfe6fcdcace5@redhat.com> Message-ID: If ConcGCThread and ParallelGCThread are uint, then making _max_workers uint too seems only consequential. Or what am I missing? Roman > > On 4/28/20 8:26 AM, Roman Kennke wrote: >> Would it be more useful to make _max_workers uint to begin with? > > That will have much wider implication, especially, it is derived from > ConcGCThreads and ParallelGCThreads, which are uints. So, you will see > conversions in other places. > > > -Zhengyu > >> >> Roman >> >> >>> Please review this small patch that fixes build problems (size_t => uint >>> type conversion) on Windows. >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ >>> >>> Test: >>> ?? Built on Windows. >>> >>> Thanks, >>> >>> -Zhengyu >>> >> > From zgu at redhat.com Tue Apr 28 14:02:36 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Apr 2020 10:02:36 -0400 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> <6753c058-f153-2621-032d-bfe6fcdcace5@redhat.com> Message-ID: Yea, need some coffee ... Updated: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.01/index.html -Zhengyu On 4/28/20 8:46 AM, Roman Kennke wrote: > If ConcGCThread and ParallelGCThread are uint, then making _max_workers > uint too seems only consequential. Or what am I missing? > > Roman > > >> >> On 4/28/20 8:26 AM, Roman Kennke wrote: >>> Would it be more useful to make _max_workers uint to begin with? >> >> That will have much wider implication, especially, it is derived from >> ConcGCThreads and ParallelGCThreads, which are uints. So, you will see >> conversions in other places. >> >> >> -Zhengyu >> >>> >>> Roman >>> >>> >>>> Please review this small patch that fixes build problems (size_t => uint >>>> type conversion) on Windows. >>>> >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 >>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ >>>> >>>> Test: >>>> ?? Built on Windows. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>> >> > From thomas.stuefe at gmail.com Tue Apr 28 15:00:24 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 28 Apr 2020 17:00:24 +0200 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Message-ID: Thank you for fixing this, looks good and trivial. ... Thomas On Mon, Apr 27, 2020 at 11:44 PM Zhengyu Gu wrote: > Please review this small patch that fixes build problems (size_t => uint > type conversion) on Windows. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ > > Test: > Built on Windows. > > Thanks, > > -Zhengyu > > From zgu at redhat.com Tue Apr 28 15:07:06 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Apr 2020 11:07:06 -0400 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Message-ID: Hi Thomas, Thanks for reviewing. There is revised version, still OK? http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.01/ -Zhengyu On 4/28/20 11:00 AM, Thomas St?fe wrote: > Thank you for fixing this, looks good and trivial. > > ... > Thomas > > On Mon, Apr 27, 2020 at 11:44 PM Zhengyu Gu > wrote: > > Please review this small patch that fixes build problems (size_t => > uint > type conversion) on Windows. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ > > Test: > ? ?Built on Windows. > > Thanks, > > -Zhengyu > From rkennke at redhat.com Tue Apr 28 15:28:34 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Apr 2020 17:28:34 +0200 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Message-ID: It looks good to me. Thank you, Roman Zhengyu Gu schrieb am Di., 28. Apr. 2020, 17:09: > Hi Thomas, > > Thanks for reviewing. There is revised version, still OK? > > http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.01/ > > -Zhengyu > > On 4/28/20 11:00 AM, Thomas St?fe wrote: > > Thank you for fixing this, looks good and trivial. > > > > ... > > Thomas > > > > On Mon, Apr 27, 2020 at 11:44 PM Zhengyu Gu > > wrote: > > > > Please review this small patch that fixes build problems (size_t => > > uint > > type conversion) on Windows. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ > > > > Test: > > Built on Windows. > > > > Thanks, > > > > -Zhengyu > > > > From thomas.stuefe at gmail.com Tue Apr 28 16:15:54 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 28 Apr 2020 18:15:54 +0200 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Message-ID: Looks still good. ..Thomas On Tue, Apr 28, 2020 at 5:07 PM Zhengyu Gu wrote: > Hi Thomas, > > Thanks for reviewing. There is revised version, still OK? > > http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.01/ > > -Zhengyu > > On 4/28/20 11:00 AM, Thomas St?fe wrote: > > Thank you for fixing this, looks good and trivial. > > > > ... > > Thomas > > > > On Mon, Apr 27, 2020 at 11:44 PM Zhengyu Gu > > wrote: > > > > Please review this small patch that fixes build problems (size_t => > > uint > > type conversion) on Windows. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ > > > > Test: > > Built on Windows. > > > > Thanks, > > > > -Zhengyu > > > > From zgu at redhat.com Tue Apr 28 16:19:01 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Apr 2020 12:19:01 -0400 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Message-ID: <95200e9f-fce1-8c89-c232-1fd7b7f87747@redhat.com> Thanks, -Zhengyu On 4/28/20 12:15 PM, Thomas St?fe wrote: > Looks still good. > > ..Thomas > > On Tue, Apr 28, 2020 at 5:07 PM Zhengyu Gu > wrote: > > Hi Thomas, > > Thanks for reviewing. There is revised version, still OK? > > http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.01/ > > -Zhengyu > > On 4/28/20 11:00 AM, Thomas St?fe wrote: > > Thank you for fixing this, looks good and trivial. > > > > ... > > Thomas > > > > On Mon, Apr 27, 2020 at 11:44 PM Zhengyu Gu > > >> wrote: > > > >? ? ?Please review this small patch that fixes build problems > (size_t => > >? ? ?uint > >? ? ?type conversion) on Windows. > > > > > >? ? ?Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 > >? ? ?Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ > > > >? ? ?Test: > >? ? ? ? ?Built on Windows. > > > >? ? ?Thanks, > > > >? ? ?-Zhengyu > > > From zgu at redhat.com Tue Apr 28 16:19:13 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Apr 2020 12:19:13 -0400 Subject: [15] RFR(T) 8243848: Shenandoah: Windows build fails after JDK-8239786 In-Reply-To: References: <9091b83c-6ae7-081a-2f10-9674e8ea44ff@redhat.com> Message-ID: <6b919a51-4536-d591-225a-46fa2b455c76@redhat.com> Thanks, -Zhengyu On 4/28/20 11:28 AM, Roman Kennke wrote: > It looks good to me. > > Thank you, > Roman > > Zhengyu Gu > schrieb am Di., 28. > Apr. 2020, 17:09: > > Hi Thomas, > > Thanks for reviewing. There is revised version, still OK? > > http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.01/ > > -Zhengyu > > On 4/28/20 11:00 AM, Thomas St?fe wrote: > > Thank you for fixing this, looks good and trivial. > > > > ... > > Thomas > > > > On Mon, Apr 27, 2020 at 11:44 PM Zhengyu Gu > > >> wrote: > > > >? ? ?Please review this small patch that fixes build problems > (size_t => > >? ? ?uint > >? ? ?type conversion) on Windows. > > > > > >? ? ?Bug: https://bugs.openjdk.java.net/browse/JDK-8243848 > >? ? ?Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243848/webrev.00/ > > > >? ? ?Test: > >? ? ? ? ?Built on Windows. > > > >? ? ?Thanks, > > > >? ? ?-Zhengyu > > > From cdvr1993 at gmail.com Tue Apr 28 22:42:04 2020 From: cdvr1993 at gmail.com (Cristian Velazquez) Date: Tue, 28 Apr 2020 15:42:04 -0700 Subject: Shenandoah experimental flags Message-ID: Hi everyone: I'm testing out shenandoah on https://github.com/gaul/java-httpbin. I'm using wrk to send a huge amount of traffic: wrk -d 300 -t 1 -c 32 http://127.0.0.1:8080/gzip. I'm using the default flags with 2G heap. I'm getting pause times from 100-300ms due to the time spent on finish queues. I tried the following (I used as reference this https://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-July/006630.html ): - Reduce ShenandoahSATBBufferFlushInterval to 1 ms. This didn't make any difference. - Reduce ShenandoahSATBBufferSize to 32. This fixed the issue and now see better pause times. I have run it for quite a while and I haven't seen any issue with this configuration. Although, I would like to know what is the recommendation in this scenario? is it safe to decrease the buffer size? what is the impact of doing so? Thanks, regards Cristian Velazquez From zgu at redhat.com Wed Apr 29 19:09:11 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 29 Apr 2020 15:09:11 -0400 Subject: [15] RFR 8241793: Shenandoah: Enable concurrent class unloading for aarch64 Message-ID: <4f453020-1f29-30a4-9e45-33854451bd3d@redhat.com> Concurrent class unloading support for aarch64 [1] has been pushed, let's enable it for Shenandoah GC. Bug: https://bugs.openjdk.java.net/browse/JDK-8241793 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8241793/webrev.00/ Test: hotspot_gc_shenandoah tier1 with Shenandoah GC Thanks, -Zhengyu [1] https://bugs.openjdk.java.net/browse/JDK-8216557 From shade at redhat.com Thu Apr 30 08:16:38 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Apr 2020 10:16:38 +0200 Subject: RFR (M) 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly Message-ID: <37abb233-3638-fe23-6783-56e86ba89a82@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244180 See the rationale in JIRA: it blocks JDK-8243495 (and other counter work, like class unloading). Fix: https://cr.openjdk.java.net/~shade/8244180/webrev.01/ Testing: hotspot_gc_shenandoah, tier{1,2,3} with Shenandoah; tests with JDK-8243495 (where the issue was discovered) -- Thanks, -Aleksey From shade at redhat.com Thu Apr 30 08:37:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Apr 2020 10:37:21 +0200 Subject: Shenandoah experimental flags In-Reply-To: References: Message-ID: <37ebe27d-7b56-66a5-db94-0734b3e3b7e3@redhat.com> Hi Cristian, On 4/29/20 12:42 AM, Cristian Velazquez wrote: > Hi everyone: > > I'm testing out shenandoah on https://github.com/gaul/java-httpbin. I'm > using wrk to send a huge amount of traffic: wrk -d 300 -t 1 -c 32 > http://127.0.0.1:8080/gzip. I'm using the default flags with 2G heap. Does not seem to reproduce on current head. What build/version are you using? > I'm getting pause times from 100-300ms due to the time spent on finish queues. Please show the part of GC log where you see this? > I tried the following (I used as reference this > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-July/006630.html > ): > - Reduce ShenandoahSATBBufferFlushInterval to 1 ms. This didn't make any > difference. > - Reduce ShenandoahSATBBufferSize to 32. This fixed the issue and now see > better pause times. Really! That is odd. The periodic SATB buffer is supposed to flush anything leftover before you hit this problem. > I have run it for quite a while and I haven't seen any issue with this > configuration. Although, I would like to know what is the recommendation in > this scenario? is it safe to decrease the buffer size? what is the impact > of doing so? Mostly throughput performance. SATB buffer is the thing that accumulates the old field values before each store to maintain marking invariants. Without this buffer, every reference store would need to call into VM, which would be costly. So the buffer is deliberately quite large to keep application from calling into VM too often, and do that only for buffer flushes. But, that matters only when marking is running. In my quick tests, your workload seems to be almost fully young: [93.298s][info][gc] Trigger: Free (204M) is below minimum threshold (204M) [93.298s][info][gc] GC(12) Concurrent reset 0.218ms [93.299s][info][gc] GC(12) Pause Init Mark (unload classes) 0.191ms [93.301s][info][gc] GC(12) Concurrent marking (unload classes) 1.918ms [93.301s][info][gc] GC(12) Pause Final Mark (unload classes) 0.221ms [93.301s][info][gc] GC(12) Concurrent weak roots 0.362ms [93.302s][info][gc] GC(12) Concurrent cleanup 1766M->102M(2021M) 0.269ms [93.303s][info][gc] GC(12) Concurrent class unloading 1.403ms ...so marking is way too short for you to notice this. What I suspect is happening in your case is that marking is *so short* that buffer flush never happens until Final Mark, where we discover some work to do. But it is puzzling why that work is >100ms, when the workload does not have a lot of live data. Need more info... -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 30 09:05:09 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Apr 2020 11:05:09 +0200 Subject: Shenandoah experimental flags In-Reply-To: <37ebe27d-7b56-66a5-db94-0734b3e3b7e3@redhat.com> References: <37ebe27d-7b56-66a5-db94-0734b3e3b7e3@redhat.com> Message-ID: I kinda suspect it's running into degen GC, and lowering buffer size slows it down enough to avoid this. Need to see GC logs to confirm it. Roman > Hi Cristian, > > On 4/29/20 12:42 AM, Cristian Velazquez wrote: >> Hi everyone: >> >> I'm testing out shenandoah on https://github.com/gaul/java-httpbin. I'm >> using wrk to send a huge amount of traffic: wrk -d 300 -t 1 -c 32 >> http://127.0.0.1:8080/gzip. I'm using the default flags with 2G heap. > > Does not seem to reproduce on current head. What build/version are you using? > >> I'm getting pause times from 100-300ms due to the time spent on finish queues. > > Please show the part of GC log where you see this? > >> I tried the following (I used as reference this >> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-July/006630.html >> ): >> - Reduce ShenandoahSATBBufferFlushInterval to 1 ms. This didn't make any >> difference. >> - Reduce ShenandoahSATBBufferSize to 32. This fixed the issue and now see >> better pause times. > > Really! That is odd. The periodic SATB buffer is supposed to flush anything leftover before you hit > this problem. > >> I have run it for quite a while and I haven't seen any issue with this >> configuration. Although, I would like to know what is the recommendation in >> this scenario? is it safe to decrease the buffer size? what is the impact >> of doing so? > > Mostly throughput performance. SATB buffer is the thing that accumulates the old field values before > each store to maintain marking invariants. Without this buffer, every reference store would need to > call into VM, which would be costly. So the buffer is deliberately quite large to keep application > from calling into VM too often, and do that only for buffer flushes. > > But, that matters only when marking is running. In my quick tests, your workload seems to be almost > fully young: > > [93.298s][info][gc] Trigger: Free (204M) is below minimum threshold (204M) > [93.298s][info][gc] GC(12) Concurrent reset 0.218ms > [93.299s][info][gc] GC(12) Pause Init Mark (unload classes) 0.191ms > [93.301s][info][gc] GC(12) Concurrent marking (unload classes) 1.918ms > [93.301s][info][gc] GC(12) Pause Final Mark (unload classes) 0.221ms > [93.301s][info][gc] GC(12) Concurrent weak roots 0.362ms > [93.302s][info][gc] GC(12) Concurrent cleanup 1766M->102M(2021M) 0.269ms > [93.303s][info][gc] GC(12) Concurrent class unloading 1.403ms > > ...so marking is way too short for you to notice this. > > What I suspect is happening in your case is that marking is *so short* that buffer flush never > happens until Final Mark, where we discover some work to do. But it is puzzling why that work is >> 100ms, when the workload does not have a lot of live data. > > Need more info... > From zgu at redhat.com Thu Apr 30 15:41:49 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 30 Apr 2020 11:41:49 -0400 Subject: RFR (M) 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly In-Reply-To: <37abb233-3638-fe23-6783-56e86ba89a82@redhat.com> References: <37abb233-3638-fe23-6783-56e86ba89a82@redhat.com> Message-ID: Good to me. -Zhengyu On 4/30/20 4:16 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244180 > > See the rationale in JIRA: it blocks JDK-8243495 (and other counter work, like class unloading). > > Fix: > https://cr.openjdk.java.net/~shade/8244180/webrev.01/ > > Testing: hotspot_gc_shenandoah, tier{1,2,3} with Shenandoah; tests with JDK-8243495 (where the issue > was discovered) > From shade at redhat.com Thu Apr 30 18:38:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Apr 2020 20:38:10 +0200 Subject: [14] RFR (M) 8242082: Shenandoah: Purge Traversal mode Message-ID: <3dd27b04-0039-50ec-9e31-2f5dedfbd332@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8242082 https://hg.openjdk.java.net/jdk/jdk/rev/d8d2145c205c The context is quite different due to missing Traversal-related backports. Otherwise it is pretty straightforward. 14u webrev: https://cr.openjdk.java.net/~shade/8242082/webrev.14u.01/ Testing: hotspot_gc_shenandoah, tier{1,2,3} with Shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 30 20:46:40 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Apr 2020 22:46:40 +0200 Subject: [14] RFR (M) 8242082: Shenandoah: Purge Traversal mode In-Reply-To: <3dd27b04-0039-50ec-9e31-2f5dedfbd332@redhat.com> References: <3dd27b04-0039-50ec-9e31-2f5dedfbd332@redhat.com> Message-ID: <14d2b416-71ca-289d-64c9-22e64906c215@redhat.com> Looks good, thanks! Roman > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8242082 > https://hg.openjdk.java.net/jdk/jdk/rev/d8d2145c205c > > The context is quite different due to missing Traversal-related backports. Otherwise it is pretty > straightforward. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8242082/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah, tier{1,2,3} with Shenandoah > From cdvr1993 at gmail.com Thu Apr 30 21:17:49 2020 From: cdvr1993 at gmail.com (Cristian Velazquez) Date: Thu, 30 Apr 2020 14:17:49 -0700 Subject: Shenandoah experimental flags In-Reply-To: References: <37ebe27d-7b56-66a5-db94-0734b3e3b7e3@redhat.com> Message-ID: Thanks for the prompt response. I'm using the docker jdk8 image (shipilev/openjdk-shenandoah:8). I'll share more details and the gc logs: The first test was (gc-stab1024.log): java -Xms2G -Xmx2G -XX:+AlwaysPreTouch \ -XX:+UseShenandoahGC -XX:+PrintHeapAtGC -XX:+PrintGCDetails \ -XX:+PrintGCDateStamps -XX:+UnlockExperimentalVMOptions \ -Xloggc:./gc-httpbin.log \ -XX:ShenandoahMinFreeThreshold=25 \ -XX:ShenandoahRefProcFrequency=0 \ -XX:ShenandoahSATBBufferSize=1024 \ -jar ./java-httpbin/target/httpbin-1.3.1-SNAPSHOT-jar-with-dependencies.jar The second (gc-stab1024-1ms.log): java -Xms2G -Xmx2G -XX:+AlwaysPreTouch \ -XX:+UseShenandoahGC -XX:+PrintHeapAtGC -XX:+PrintGCDetails \ -XX:+PrintGCDateStamps -XX:+UnlockExperimentalVMOptions \ -Xloggc:./gc-httpbin.log \ -XX:ShenandoahMinFreeThreshold=25 \ -XX:ShenandoahRefProcFrequency=0 \ -XX:ShenandoahSATBBufferSize=1024 \ -XX:ShenandoahSATBBufferFlushInterval=1 \ -jar ./java-httpbin/target/httpbin-1.3.1-SNAPSHOT-jar-with-dependencies.jar The one that has the impact I would expect (gc-stab32.log): java -Xms2G -Xmx2G -XX:+AlwaysPreTouch \ -XX:+UseShenandoahGC -XX:+PrintHeapAtGC -XX:+PrintGCDetails \ -XX:+PrintGCDateStamps -XX:+UnlockExperimentalVMOptions \ -Xloggc:./gc-httpbin.log \ -XX:ShenandoahMinFreeThreshold=25 \ -XX:ShenandoahRefProcFrequency=0 \ -XX:ShenandoahSATBBufferSize=32 \ -jar ./java-httpbin/target/httpbin-1.3.1-SNAPSHOT-jar-with-dependencies.jar Thanks, regards Cristian V On Thu, Apr 30, 2020 at 2:05 AM Roman Kennke wrote: > I kinda suspect it's running into degen GC, and lowering buffer size > slows it down enough to avoid this. Need to see GC logs to confirm it. > > Roman > > > Hi Cristian, > > > > On 4/29/20 12:42 AM, Cristian Velazquez wrote: > >> Hi everyone: > >> > >> I'm testing out shenandoah on https://github.com/gaul/java-httpbin. I'm > >> using wrk to send a huge amount of traffic: wrk -d 300 -t 1 -c 32 > >> http://127.0.0.1:8080/gzip. I'm using the default flags with 2G heap. > > > > Does not seem to reproduce on current head. What build/version are you > using? > > > >> I'm getting pause times from 100-300ms due to the time spent on finish > queues. > > > > Please show the part of GC log where you see this? > > > >> I tried the following (I used as reference this > >> > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2018-July/006630.html > >> ): > >> - Reduce ShenandoahSATBBufferFlushInterval to 1 ms. This didn't make any > >> difference. > >> - Reduce ShenandoahSATBBufferSize to 32. This fixed the issue and now > see > >> better pause times. > > > > Really! That is odd. The periodic SATB buffer is supposed to flush > anything leftover before you hit > > this problem. > > > >> I have run it for quite a while and I haven't seen any issue with this > >> configuration. Although, I would like to know what is the > recommendation in > >> this scenario? is it safe to decrease the buffer size? what is the > impact > >> of doing so? > > > > Mostly throughput performance. SATB buffer is the thing that accumulates > the old field values before > > each store to maintain marking invariants. Without this buffer, every > reference store would need to > > call into VM, which would be costly. So the buffer is deliberately quite > large to keep application > > from calling into VM too often, and do that only for buffer flushes. > > > > But, that matters only when marking is running. In my quick tests, your > workload seems to be almost > > fully young: > > > > [93.298s][info][gc] Trigger: Free (204M) is below minimum threshold > (204M) > > [93.298s][info][gc] GC(12) Concurrent reset 0.218ms > > [93.299s][info][gc] GC(12) Pause Init Mark (unload classes) 0.191ms > > [93.301s][info][gc] GC(12) Concurrent marking (unload classes) 1.918ms > > [93.301s][info][gc] GC(12) Pause Final Mark (unload classes) 0.221ms > > [93.301s][info][gc] GC(12) Concurrent weak roots 0.362ms > > [93.302s][info][gc] GC(12) Concurrent cleanup 1766M->102M(2021M) 0.269ms > > [93.303s][info][gc] GC(12) Concurrent class unloading 1.403ms > > > > ...so marking is way too short for you to notice this. > > > > What I suspect is happening in your case is that marking is *so short* > that buffer flush never > > happens until Final Mark, where we discover some work to do. But it is > puzzling why that work is > >> 100ms, when the workload does not have a lot of live data. > > > > Need more info... > > > > -- Atentamente. Cristian D. Vel?zquez Ram?rez.