From shade at redhat.com Fri May 1 08:27:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 May 2020 10:27:50 +0200 Subject: RFR (S) 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles Message-ID: <549cba29-5c8a-3f06-5266-bfc0e416b851@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8244226 See how it fails in the bug. Fix: https://cr.openjdk.java.net/~shade/8244226/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release}, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Fri May 1 09:39:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 May 2020 11:39:58 +0200 Subject: RFC: Pick up 11.0.8+1 to sh/jdk11 Message-ID: <7cfeae3f-5f7e-629d-cd2b-cb07fe4dec2f@redhat.com> Upstream had published 11.0.8+1, let's pick it up to sh/jdk11. The merge was simple, except one thing. I had to apply the missing Shenandoah hunk from 8231550 to unbreak the tests: https://hg.openjdk.java.net/jdk/jdk/rev/bada0782842a I will tag it shenandoah-jdk-11.8.0+1 after some post-integration testing. Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From rkennke at redhat.com Fri May 1 10:54:53 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 1 May 2020 12:54:53 +0200 Subject: RFR (S) 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles In-Reply-To: <549cba29-5c8a-3f06-5266-bfc0e416b851@redhat.com> References: <549cba29-5c8a-3f06-5266-bfc0e416b851@redhat.com> Message-ID: Looks good, thanks! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8244226 > > See how it fails in the bug. > > Fix: > https://cr.openjdk.java.net/~shade/8244226/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release}, eyeballing gc logs > From rkennke at redhat.com Fri May 1 11:00:29 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 1 May 2020 13:00:29 +0200 Subject: RFC: Pick up 11.0.8+1 to sh/jdk11 In-Reply-To: <7cfeae3f-5f7e-629d-cd2b-cb07fe4dec2f@redhat.com> References: <7cfeae3f-5f7e-629d-cd2b-cb07fe4dec2f@redhat.com> Message-ID: It looks ok to me. Better to have Roland look over it too? Roman > Upstream had published 11.0.8+1, let's pick it up to sh/jdk11. > > The merge was simple, except one thing. I had to apply the missing Shenandoah hunk from 8231550 to > unbreak the tests: > https://hg.openjdk.java.net/jdk/jdk/rev/bada0782842a > > I will tag it shenandoah-jdk-11.8.0+1 after some post-integration testing. > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From shade at redhat.com Fri May 1 11:25:53 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 May 2020 13:25:53 +0200 Subject: RFC: Pick up 11.0.8+1 to sh/jdk11 In-Reply-To: References: <7cfeae3f-5f7e-629d-cd2b-cb07fe4dec2f@redhat.com> Message-ID: <73a66e37-86ba-1a60-4e8e-72781deda1e4@redhat.com> On 5/1/20 1:00 PM, Roman Kennke wrote: > It looks ok to me. Better to have Roland look over it too? Sure. This is the src/hotspot subset of the merge: https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.8%2b1/webrev.01/ >> Upstream had published 11.0.8+1, let's pick it up to sh/jdk11. >> >> The merge was simple, except one thing. I had to apply the missing Shenandoah hunk from 8231550 to >> unbreak the tests: >> https://hg.openjdk.java.net/jdk/jdk/rev/bada0782842a ...for this, I resolved the conflict in src/hotspot/share/opto/loopnode.cpp by accepting the upstream side, and then applied a hunk in src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp cleanly. There were no other conflicts. Without doing the above, gc/shenandoah/compiler/CallMultipleCatchProjs.java fails. -- Thanks, -Aleksey From shade at redhat.com Fri May 1 14:36:30 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 May 2020 16:36:30 +0200 Subject: Shenandoah experimental flags In-Reply-To: References: <37ebe27d-7b56-66a5-db94-0734b3e3b7e3@redhat.com> Message-ID: <070fe709-b32a-00ce-a7cc-38b4dd9ce07d@redhat.com> On 4/30/20 11:17 PM, Cristian Velazquez wrote: > Thanks for the prompt response. I'm using the docker jdk8 image (shipilev/openjdk-shenandoah:8). Aha! I am able to reproduce it with current sh/jdk8. Let me see what is up there. -- Thanks, -Aleksey From shade at redhat.com Fri May 1 15:53:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 May 2020 17:53:03 +0200 Subject: Shenandoah experimental flags In-Reply-To: <070fe709-b32a-00ce-a7cc-38b4dd9ce07d@redhat.com> References: <37ebe27d-7b56-66a5-db94-0734b3e3b7e3@redhat.com> <070fe709-b32a-00ce-a7cc-38b4dd9ce07d@redhat.com> Message-ID: <3868b6d6-8e30-9d9b-3f34-59b92573d547@redhat.com> On 5/1/20 4:36 PM, Aleksey Shipilev wrote: > On 4/30/20 11:17 PM, Cristian Velazquez wrote: >> Thanks for the prompt response. I'm using the docker jdk8 image (shipilev/openjdk-shenandoah:8). > > Aha! I am able to reproduce it with current sh/jdk8. Let me see what is up there. I believe it is what I initially expected: concurrent mark runs into termination very fast, the periodic task that flushes SATB buffers does not have the opportunity to act, then final mark hits and discovers lots of hidden work from the SATB buffers. A new thing I see is, the SATB traffic itself is too low to enqueue SATB buffers naturally. Indeed, reducing SATB buffer sizes is the workaround here. It is interesting that it happens reliably on sh/jdk8, but not on sh/jdk11 and later. Maybe Jetty is using something unusual, like lots of phantom references? Anyhow, another way to dodge this problem is upgrading. As for sh/jdk8, we should probably try and see if we can adjust SATB sizes looking back at traffic we are getting. The nuclear option would be to introduce another pause where we force all threads go give up their SATB buffers, regardless of their capacity. That is something to look at next week. With some instrumentation, good cycle: [Concurrent marking, start] Using 4 of 8 workers for concurrent marking Flushed SATB buffer for thread qtp475266352-44 Flushed SATB buffer for thread qtp475266352-30 Flushed SATB buffer for thread qtp475266352-31 Flushed SATB buffer for thread qtp475266352-48 Flushed SATB buffer for thread qtp475266352-61 Flushed SATB buffer for thread qtp475266352-47 Flushed SATB buffer for thread qtp475266352-63 Flushed SATB buffer for thread qtp475266352-21-selector-ServerConnectorManager at 1c07660a/0 Flushed SATB buffer for thread qtp475266352-20-selector-ServerConnectorManager at 1c07660a/2 Flushed SATB buffer for thread qtp475266352-22-selector-ServerConnectorManager at 1c07660a/3 Flushed SATB buffer for thread qtp475266352-27-selector-ServerConnectorManager at 1c07660a/1 Flushed SATB buffer for thread qtp475266352-26 Flushed SATB buffer for thread qtp475266352-37 [Concurrent marking, 911.426 ms] [Pause Final Mark, start] Using 8 of 8 workers for final marking Adaptive CSet Selection. Target Free: 290M, Actual Free: 316M, Max CSet: 87381K, Min Garbage: 0B Collectable Garbage: 956M (97%), Immediate: 1024K (0%), CSet: 955M (97%) Pacer for Evacuation. Used CSet: 965M, Free: 247M, Non-Taxable: 25368K, Alloc Tax Rate: 9.5x [Pause Final Mark, 0.917 ms] ...and bad cycle: [Concurrent marking, start] Using 4 of 8 workers for concurrent marking [Concurrent marking, 1.937 ms] [Pause Final Mark, start] Using 8 of 8 workers for final marking Adaptive CSet Selection. Target Free: 290M, Actual Free: 456M, Max CSet: 87381K, Min Garbage: 0B Collectable Garbage: 918M (96%), Immediate: 0B (0%), CSet: 918M (96%) Pacer for Evacuation. Used CSet: 926M, Free: 382M, Non-Taxable: 39184K, Alloc Tax Rate: 5.9x [Pause Final Mark, 987.943 ms] -- Thanks, -Aleksey From zgu at redhat.com Fri May 1 17:08:23 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 1 May 2020 13:08:23 -0400 Subject: [15] RFR 8244243: Shenandoah: Cleanup Shenandoah phase timing tracking and JFR event supporting Message-ID: Hi, Please review this patch that intends to cleanup Shenandoah phase timing tacking and JFR event supporting. Currently, there are a few classes involving GC phase timing tracking and JFR event generating, but they are not well defined. For example, ShenandoahGCPhase does not emit JFR event, but ShenandoahGCSubPhase does. The patch draws line: ShenandoahGCPhaseTiming: only tracks Shenandoah specific timing, but does not emit JFR event. ShenandoahPausePhase, ShenandoahConcurrentPhase and ShenandoahGCPhase: track Shenandoah specific timings and also emit JFR events. Due to limited nesting levels of pause events, it has to workaround an issue when a degenerated GC upgrades to full GC, it potential overflows maximum nesting levels. Also, the patch adds missing JFR worker events. Bug: https://bugs.openjdk.java.net/browse/JDK-8244243 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244243/webrev.00/index.html Test: hotspot_gc_shenandoah Eyeball events in jmc Thanks, -Zhengyu From cdvr1993 at gmail.com Fri May 1 17:49:10 2020 From: cdvr1993 at gmail.com (Cristian Velazquez) Date: Fri, 1 May 2020 10:49:10 -0700 Subject: Shenandoah experimental flags In-Reply-To: <3868b6d6-8e30-9d9b-3f34-59b92573d547@redhat.com> References: <37ebe27d-7b56-66a5-db94-0734b3e3b7e3@redhat.com> <070fe709-b32a-00ce-a7cc-38b4dd9ce07d@redhat.com> <3868b6d6-8e30-9d9b-3f34-59b92573d547@redhat.com> Message-ID: Thanks, I can confirm that this doesn't happen in java 11 and above. For now I'll keep a small buffer size. Is there a way I can see the satb traffic from the log? Or a way to determine a proper buffer size for my workloads? If not I can wait for any future fix. For my use case I would prefer concurrent to spend more time just to clean the buffers and let the pause to be as small as possible, but I don't how feasible is that. Thanks for all the help, regards Cristian V On Fri, May 1, 2020 at 8:53 AM Aleksey Shipilev wrote: > On 5/1/20 4:36 PM, Aleksey Shipilev wrote: > > On 4/30/20 11:17 PM, Cristian Velazquez wrote: > >> Thanks for the prompt response. I'm using the docker jdk8 image > (shipilev/openjdk-shenandoah:8). > > > > Aha! I am able to reproduce it with current sh/jdk8. Let me see what is > up there. > > I believe it is what I initially expected: concurrent mark runs into > termination very fast, the > periodic task that flushes SATB buffers does not have the opportunity to > act, then final mark hits > and discovers lots of hidden work from the SATB buffers. > > A new thing I see is, the SATB traffic itself is too low to enqueue SATB > buffers naturally. Indeed, > reducing SATB buffer sizes is the workaround here. > > It is interesting that it happens reliably on sh/jdk8, but not on sh/jdk11 > and later. Maybe Jetty is > using something unusual, like lots of phantom references? Anyhow, another > way to dodge this problem > is upgrading. > > As for sh/jdk8, we should probably try and see if we can adjust SATB sizes > looking back at traffic > we are getting. The nuclear option would be to introduce another pause > where we force all threads go > give up their SATB buffers, regardless of their capacity. > > That is something to look at next week. > > With some instrumentation, good cycle: > > [Concurrent marking, start] > Using 4 of 8 workers for concurrent marking > Flushed SATB buffer for thread qtp475266352-44 > Flushed SATB buffer for thread qtp475266352-30 > Flushed SATB buffer for thread qtp475266352-31 > Flushed SATB buffer for thread qtp475266352-48 > Flushed SATB buffer for thread qtp475266352-61 > Flushed SATB buffer for thread qtp475266352-47 > Flushed SATB buffer for thread qtp475266352-63 > Flushed SATB buffer for thread > qtp475266352-21-selector-ServerConnectorManager at 1c07660a/0 > Flushed SATB buffer for thread > qtp475266352-20-selector-ServerConnectorManager at 1c07660a/2 > Flushed SATB buffer for thread > qtp475266352-22-selector-ServerConnectorManager at 1c07660a/3 > Flushed SATB buffer for thread > qtp475266352-27-selector-ServerConnectorManager at 1c07660a/1 > Flushed SATB buffer for thread qtp475266352-26 > Flushed SATB buffer for thread qtp475266352-37 > [Concurrent marking, 911.426 ms] > [Pause Final Mark, start] > Using 8 of 8 workers for final marking > Adaptive CSet Selection. Target Free: 290M, Actual Free: 316M, Max > CSet: 87381K, Min Garbage: 0B > Collectable Garbage: 956M (97%), Immediate: 1024K (0%), CSet: 955M > (97%) > Pacer for Evacuation. Used CSet: 965M, Free: 247M, Non-Taxable: > 25368K, Alloc Tax Rate: 9.5x > [Pause Final Mark, 0.917 ms] > > ...and bad cycle: > > [Concurrent marking, start] > Using 4 of 8 workers for concurrent marking > [Concurrent marking, 1.937 ms] > [Pause Final Mark, start] > Using 8 of 8 workers for final marking > Adaptive CSet Selection. Target Free: 290M, Actual Free: 456M, Max > CSet: 87381K, Min Garbage: 0B > Collectable Garbage: 918M (96%), Immediate: 0B (0%), CSet: 918M (96%) > Pacer for Evacuation. Used CSet: 926M, Free: 382M, Non-Taxable: > 39184K, Alloc Tax Rate: 5.9x > [Pause Final Mark, 987.943 ms] > > -- > Thanks, > -Aleksey > > -- Atentamente. Cristian D. Vel?zquez Ram?rez. From rwestrel at redhat.com Mon May 4 09:50:40 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 04 May 2020 11:50:40 +0200 Subject: RFC: Pick up 11.0.8+1 to sh/jdk11 In-Reply-To: <73a66e37-86ba-1a60-4e8e-72781deda1e4@redhat.com> References: <7cfeae3f-5f7e-629d-cd2b-cb07fe4dec2f@redhat.com> <73a66e37-86ba-1a60-4e8e-72781deda1e4@redhat.com> Message-ID: <87mu6o6nbj.fsf@redhat.com> > This is the src/hotspot subset of the merge: > https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.8%2b1/webrev.01/ > >>> Upstream had published 11.0.8+1, let's pick it up to sh/jdk11. >>> >>> The merge was simple, except one thing. I had to apply the missing Shenandoah hunk from 8231550 to >>> unbreak the tests: >>> https://hg.openjdk.java.net/jdk/jdk/rev/bada0782842a > > ...for this, I resolved the conflict in src/hotspot/share/opto/loopnode.cpp by accepting the > upstream side, and then applied a hunk in src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp > cleanly. There were no other conflicts. > > Without doing the above, gc/shenandoah/compiler/CallMultipleCatchProjs.java fails. That looks good to me. Roland. From shade at redhat.com Mon May 4 10:01:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 May 2020 12:01:37 +0200 Subject: RFC: Pick up 11.0.8+1 to sh/jdk11 In-Reply-To: <87mu6o6nbj.fsf@redhat.com> References: <7cfeae3f-5f7e-629d-cd2b-cb07fe4dec2f@redhat.com> <73a66e37-86ba-1a60-4e8e-72781deda1e4@redhat.com> <87mu6o6nbj.fsf@redhat.com> Message-ID: <960599ac-38cc-8541-9364-51ae8dcb59a4@redhat.com> On 5/4/20 11:50 AM, Roland Westrelin wrote: > >> This is the src/hotspot subset of the merge: >> https://cr.openjdk.java.net/~shade/shenandoah/merges/jdk11-11.0.8%2b1/webrev.01/ >> >>>> Upstream had published 11.0.8+1, let's pick it up to sh/jdk11. >>>> >>>> The merge was simple, except one thing. I had to apply the missing Shenandoah hunk from 8231550 to >>>> unbreak the tests: >>>> https://hg.openjdk.java.net/jdk/jdk/rev/bada0782842a >> >> ...for this, I resolved the conflict in src/hotspot/share/opto/loopnode.cpp by accepting the >> upstream side, and then applied a hunk in src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp >> cleanly. There were no other conflicts. >> >> Without doing the above, gc/shenandoah/compiler/CallMultipleCatchProjs.java fails. > > That looks good to me. Thanks, pushed the whole merge to sh/jdk11. -- Thanks, -Aleksey From shade at redhat.com Mon May 4 11:32:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 May 2020 13:32:35 +0200 Subject: RFR (S) 8244326: Shenandoah: global statistics should not accept bogus samples Message-ID: <207f5d8e-56a4-9de3-16cc-752f7c16d44e@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8244326 Fix: https://cr.openjdk.java.net/~shade/8244326/webrev.01/ Testing: hotspot_gc_shenandoah, eyeballing the logs -- Thanks, -Aleksey From shade at redhat.com Mon May 4 12:49:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 May 2020 14:49:33 +0200 Subject: RFR (S) 8244200: Shenandoah: build breakages after JDK-8241743 Message-ID: <71575d3c-2323-fd6d-9f17-2c9f824c56c6@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8244200 This looks like a regression from JDK-8241743 that moved ShenandoahHeap::heap() to .inline.hpp. To fix it everywhere, I rolled over every file that references ShenandoahHeap::heap() and added the relevant include. It fixes the reported build failure, and hopefully similar ones in future. Fix: https://cr.openjdk.java.net/~shade/8244200/webrev.01/ Testing: Linux x86_64 {fastdebug, release, slowdebug} no-PCH builds with/without JFR -- Thanks, -Aleksey From rkennke at redhat.com Mon May 4 12:59:53 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 May 2020 14:59:53 +0200 Subject: RFR (S) 8244200: Shenandoah: build breakages after JDK-8241743 In-Reply-To: <71575d3c-2323-fd6d-9f17-2c9f824c56c6@redhat.com> References: <71575d3c-2323-fd6d-9f17-2c9f824c56c6@redhat.com> Message-ID: <63a25d93-6aa4-c116-aee3-6892b99c9fb9@redhat.com> Looks good, thanks! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8244200 > > This looks like a regression from JDK-8241743 that moved ShenandoahHeap::heap() to .inline.hpp. To > fix it everywhere, I rolled over every file that references ShenandoahHeap::heap() and added the > relevant include. It fixes the reported build failure, and hopefully similar ones in future. > > Fix: > https://cr.openjdk.java.net/~shade/8244200/webrev.01/ > > Testing: Linux x86_64 {fastdebug, release, slowdebug} no-PCH builds with/without JFR > From zgu at redhat.com Mon May 4 13:55:22 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 4 May 2020 09:55:22 -0400 Subject: [15] RFR 8244328: Shenandoah: move ShenandoahThreadLocalData::_disarmed_value initialization Message-ID: <42b7a9b8-cf1f-1d3e-630d-c588bbd308cf@redhat.com> Please review this small patch that removes disarmed_value setting from initialize_gclab. The value is independently set vs. ShenandoahCodeRoots::arm_nmethods(), has nothing to do with gclab initialization. Bug: https://bugs.openjdk.java.net/browse/JDK-8244328 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244328/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Mon May 4 14:00:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 May 2020 16:00:04 +0200 Subject: [15] RFR 8244328: Shenandoah: move ShenandoahThreadLocalData::_disarmed_value initialization In-Reply-To: <42b7a9b8-cf1f-1d3e-630d-c588bbd308cf@redhat.com> References: <42b7a9b8-cf1f-1d3e-630d-c588bbd308cf@redhat.com> Message-ID: <1963baab-4e62-4300-92a5-4086ef9f70e6@redhat.com> On 5/4/20 3:55 PM, Zhengyu Gu wrote: > Please review this small patch that removes disarmed_value setting from > initialize_gclab. The value is independently set vs. > ShenandoahCodeRoots::arm_nmethods(), has nothing to do with gclab > initialization. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244328 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244328/webrev.00/ Looks good! -- Thanks, -Aleksey From shade at redhat.com Mon May 4 15:17:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 May 2020 17:17:21 +0200 Subject: RFR (S) 8244327: Shenandoah: GC workers should always get the largest GCLABs Message-ID: <3a9f383b-2c0e-b388-a60f-15202dc809fd@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244327 We have the adaptive GCLAB sizing that starts with min TLAB size and doubles up on every refresh. That is suitable for Java threads that rarely evacuate through the LRB slowpath. GC workers, on the other hand, do the bulk of the GC evacuation work, and should just use the largest GCLABs available for them. Webrev: https://cr.openjdk.java.net/~shade/8244327/webrev.01/ Testing: hotspot_gc_shenandoah, looking through GCLAB issuance logs -- Thanks, -Aleksey From rkennke at redhat.com Mon May 4 15:37:03 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 May 2020 17:37:03 +0200 Subject: RFR (S) 8244327: Shenandoah: GC workers should always get the largest GCLABs In-Reply-To: <3a9f383b-2c0e-b388-a60f-15202dc809fd@redhat.com> References: <3a9f383b-2c0e-b388-a60f-15202dc809fd@redhat.com> Message-ID: <95962e5b-0cd8-9a7d-c988-21b42dc9c25b@redhat.com> I am not so sure. Here on my machine it's using 16 GC workers, which means it would grab 16 regions, 1 region each, (possibly 32MB each region when running large heaps), for GCLAB right away? Would it even nearly fill up all those regions? Maybe this should be put in a heuristic that counts in cset size and num-gc-threads? Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244327 > > We have the adaptive GCLAB sizing that starts with min TLAB size and doubles up on every refresh. > That is suitable for Java threads that rarely evacuate through the LRB slowpath. GC workers, on the > other hand, do the bulk of the GC evacuation work, and should just use the largest GCLABs available > for them. > > Webrev: > https://cr.openjdk.java.net/~shade/8244327/webrev.01/ > > Testing: hotspot_gc_shenandoah, looking through GCLAB issuance logs > From shade at redhat.com Mon May 4 16:03:30 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 May 2020 18:03:30 +0200 Subject: RFR (S) 8244327: Shenandoah: GC workers should always get the largest GCLABs In-Reply-To: <95962e5b-0cd8-9a7d-c988-21b42dc9c25b@redhat.com> References: <3a9f383b-2c0e-b388-a60f-15202dc809fd@redhat.com> <95962e5b-0cd8-9a7d-c988-21b42dc9c25b@redhat.com> Message-ID: On 5/4/20 5:37 PM, Roman Kennke wrote: > I am not so sure. Here on my machine it's using 16 GC workers, which > means it would grab 16 regions, 1 region each, (possibly 32MB each > region when running large heaps), for GCLAB right away? Every GC worker would get a region-size GCLAB, yes. Which in your example would amount to 16*32=512M of space allocated. The tidbit is, in all workloads I tried, that happens anyway. Except that with adaptive sizing we have the awkward phase during the beginning of the evacuation (actually, even in final mark, when roots are pre-evacuated!), where workers come for GCLABs over and over again until GCLAB sizes balloon up. > Would it even nearly fill up all those regions? Maybe this should be put in a heuristic that > counts in cset size and num-gc-threads? Yeah, I can see if we can size it up right after cset selection? -- Thanks, -Aleksey From rkennke at redhat.com Mon May 4 19:29:48 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 4 May 2020 21:29:48 +0200 Subject: RFR (S) 8244327: Shenandoah: GC workers should always get the largest GCLABs In-Reply-To: References: <3a9f383b-2c0e-b388-a60f-15202dc809fd@redhat.com> <95962e5b-0cd8-9a7d-c988-21b42dc9c25b@redhat.com> Message-ID: >> I am not so sure. Here on my machine it's using 16 GC workers, which >> means it would grab 16 regions, 1 region each, (possibly 32MB each >> region when running large heaps), for GCLAB right away? > > Every GC worker would get a region-size GCLAB, yes. Which in your example would amount to 16*32=512M > of space allocated. The tidbit is, in all workloads I tried, that happens anyway. Except that with > adaptive sizing we have the awkward phase during the beginning of the evacuation (actually, even in > final mark, when roots are pre-evacuated!), where workers come for GCLABs over and over again until > GCLAB sizes balloon up. Yes, I have seen that too, and it seems pointless exercise. >> Would it even nearly fill up all those regions? Maybe this should be put in a heuristic that >> counts in cset size and num-gc-threads? > Yeah, I can see if we can size it up right after cset selection? Yeah, that sounds useful. Roman From gnu.andrew at redhat.com Tue May 5 05:39:08 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 5 May 2020 06:39:08 +0100 Subject: [RFR] [8u] 8u262-b01 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b01/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b09: - JDK-4949105: Access Bridge lacks html tags parsing - JDK-8003209: JFR events for network utilization - JDK-8028431: NullPointerException in DerValue.equals(DerValue) - JDK-8030680: 292 cleanup from default method code assessment - JDK-8035633: TEST_BUG: java/net/NetworkInterface/Equals.java and some tests failed on windows intermittently - JDK-8041626: Shutdown tracing event - JDK-8041915: Move 8 awt tests to OpenJDK regression tests tree - JDK-8141056: Erroneous assignment in HeapRegionSet.cpp - JDK-8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates - JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" - JDK-8165675: Trace event for thread park has incorrect unit for timeout - JDK-8176182: 4 security tests are not run - JDK-8178910: Problemlist sample tests - JDK-8183925: [AArch64] Decouple crash protection from watcher thread - JDK-8183925: Decouple crash protection from watcher thread - JDK-8191393: Random crashes during cfree+0x1c - JDK-8195817: JFR.stop should require name of recording - JDK-8195818: JFR.start should increase autogenerated name by one - JDK-8195819: Remove recording=x from jcmd JFR.check output - JDK-8199712: [AArch64] Flight Recorder - JDK-8199712: Flight Recorder - JDK-8202578: Revisit location for class unload events - JDK-8202835: jfr/event/os/TestSystemProcess.java fails on missing events - JDK-8203287: Zero fails to build after JDK-8199712 (Flight Recorder) - JDK-8203346: JFR: Inconsistent signature of jfr_add_string_constant - JDK-8203664: JFR start failure after AppCDS archive created with JFR StartFlightRecording - JDK-8203921: JFR thread sampling is missing fixes from JDK-8194552 - JDK-8203929: Limit amount of data for JFR.dump - JDK-8205516: JFR tool - JDK-8207392: [PPC64] Implement JFR profiling - JDK-8207829: FlightRecorderMXBeanImpl is leaking the first classloader which calls it - JDK-8209960: -Xlog:jfr* doesn't work with the JFR - JDK-8210024: JFR calls virtual is_Java_thread from ~Thread() - JDK-8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 - JDK-8211239: Build fails without JFR: empty JFR events signatures mismatch - JDK-8212232: Wrong metadata for the configuration of the cutoff for old object sample events - JDK-8213015: Inconsistent settings between JFR.configure and -XX:FlightRecorderOptions - JDK-8213421: Line number information for execution samples always 0 - JDK-8213617: JFR should record the PID of the recorded process - JDK-8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. - JDK-8213914: [TESTBUG] Several JFR VM events are not covered by tests - JDK-8213917: [TESTBUG] Shutdown JFR event is not covered by test - JDK-8213966: The ZGC JFR events should be marked as experimental - JDK-8214542: JFR: Old Object Sample event slow on a deep heap in debug builds - JDK-8214750: Unnecessary

tags in jfr classes - JDK-8214896: JFR Tool left files behind - JDK-8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError - JDK-8214925: JFR tool fails to execute - JDK-8215175: Inconsistencies in JFR event metadata - JDK-8215237: jdk.jfr.Recording javadoc does not compile - JDK-8215284: Reduce noise induced by periodic task getFileSize() - JDK-8215355: Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1) - JDK-8215362: JFR GTest JfrTestNetworkUtilization fails - JDK-8215771: The jfr tool should pretty print reference chains - JDK-8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 - JDK-8216064: -XX:StartFlightRecording:settings= doesn't work properly - JDK-8216486: Possibility of integer overflow in JfrThreadSampler::run() - JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp - JDK-8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps - JDK-8216578: Remove unused/obsolete method in JFR code - JDK-8216995: Clean up JFR command line processing - JDK-8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due to process surviving SIGINT - JDK-8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent - JDK-8218935: Make jfr strncpy uses GCC 8.x friendly - JDK-8223147: JFR Backport - JDK-8223689: Add JFR Thread Sampling Support - JDK-8223690: Add JFR BiasedLock Event Support - JDK-8223691: Add JFR G1 Region Type Change Event Support - JDK-8223692: Add JFR G1 Heap Summary Event Support - JDK-8224172: assert(jfr_is_event_enabled(id)) failed: invariant - JDK-8224475: JTextPane does not show images in HTML rendering - JDK-8226253: JAWS reports wrong number of radio buttons when buttons are hidden. - JDK-8226779: [TESTBUG] Test JFR API from Java agent - JDK-8226892: ActionListeners on JRadioButtons don't get notified when selection is changed with arrow keys - JDK-8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory - JDK-8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" - JDK-8229366: JFR backport allows unchecked writing to memory - JDK-8229401: Fix JFR code cache test failures - JDK-8229708: JFR backport code does not initialize - JDK-8229873: 8229401 broke jdk8u-jfr-incubator - JDK-8230448: [test] JFRSecurityTestSuite.java is failing on Windows - JDK-8230707: JFR related tests are failing - JDK-8230782: Robot.createScreenCapture() fails if ?awt.robot.gtk? is set to false - JDK-8230856: Java_java_net_NetworkInterface_getByName0 on unix misses ReleaseStringUTFChars in early return - JDK-8230947: TestLookForUntestedEvents.java is failing after JDK-8230707 - JDK-8231995: two jtreg tests failed after 8229366 is fixed - JDK-8233623: Add classpath exception to copyright in EventHandlerProxyCreator.java file - JDK-8236002: CSR for JFR backport suggests not leaving out the package-info - JDK-8236008: Some backup files were accidentally left in the hotspot tree - JDK-8236074: Missed package-info - JDK-8236174: Should update javadoc since tags - JDK-8238076: Fix OpenJDK 7 Bootstrap Broken by JFR Backport - JDK-8238452: Keytool generates wrong expiration date if validity is set to 2050/01/01 - JDK-8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB - JDK-8238589: Necessary code cleanup in JFR for JDK8u - JDK-8238590: Enable JFR by default during compilation in 8u - JDK-8239055: Wrong implementation of VMState.hasListener - JDK-8239476: JDK-8238589 broke windows build by moving OrderedPair - JDK-8239479: minimal1 and zero builds are failing - JDK-8239867: correct over use of INCLUDE_JFR macro - JDK-8240375: Disable JFR by default for July 2020 release - JDK-8241444: Metaspace::_class_vsm not initialized if compressed class pointers are disabled - JDK-8241902: AIX Build broken after integration of JDK-8223147 (JFR Backport) - JDK-8242788: Non-PCH build is broken after JDK-8191393 Main issues of note: This is the first build promotion to contain JFR. Additional changes had to be backported to make this work on AArch64. It was necessary to get access to an AArch64 machine and build manually there first of all, after initial attempts at tagging and building failed. The following three additional changes were added in the end to get a successful build: - JDK-8183925: [AArch64] Decouple crash protection from watcher thread - JDK-8199712: [AArch64] Flight Recorder - JDK-8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 The 8183925 renaming of os::WatcherThreadCrashProtection -> os::ThreadCrashProtection needed to be applied to src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp. This was a clean backport. vm_version_ext had to be introduced for AArch64 and referenced in src/os/linux/vm/os_perf_linux.cpp. One minor change was necessary, because 8u does not have _features_string(). Instead, we use cpu_features(), which returns the same value. This port-specific function was removed in 11u by 8143072 ("[JVMCI] Port JVMCI to AArch64"), with the same value instead returned by the shared _features_string(). 8215961 is a simple followup fix for this, which prefixes the features output with "AArch64" so the JFR test passes. Most JFR tests passed with the AArch64 build. Those that didn't seemed unrelated to AArch64 specifically. $ cat tests.log |grep -v '^Passed' FAILED: jdk/jfr/api/consumer/TestRecordedFullStackTrace.java FAILED: jdk/jfr/event/io/TestInstrumentation.java FAILED: jdk/jfr/event/oldobject/TestClassLoaderLeak.java Error: jdk/jfr/event/oldobject/TestObjectDescription.java Error: jdk/jfr/event/oldobject/TestSanityDefault.java FAILED: jdk/jfr/event/profiling/TestFullStackTrace.java Error: jdk/jfr/event/sampling/TestNative.java Test results: passed: 422; failed: 4; error: 3 This gets AArch64 to build with JFR, but more support may need to be added. diffstat for root b/.hgignore | 2 + b/.hgtags | 3 + b/THIRD_PARTY_README | 30 ++++++++---------- b/common/autoconf/generated-configure.sh | 51 +++++++++++++++++++++++++++++-- b/common/autoconf/jdk-options.m4 | 26 +++++++++++++++ 5 files changed, 92 insertions(+), 20 deletions(-) diffstat for corba b/.hgtags | 4 ++++ b/THIRD_PARTY_README | 30 ++++++++++++++---------------- 2 files changed, 18 insertions(+), 16 deletions(-) diffstat for jaxp b/.hgtags | 3 + b/THIRD_PARTY_README | 30 ++++------ b/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java | 26 ++++++-- 3 files changed, 36 insertions(+), 23 deletions(-) diffstat for jaxws b/.hgtags | 3 +++ b/THIRD_PARTY_README | 30 ++++++++++++++---------------- 2 files changed, 17 insertions(+), 16 deletions(-) diffstat for langtools b/.hgtags | 3 +++ b/THIRD_PARTY_README | 30 ++++++++++++++---------------- 2 files changed, 17 insertions(+), 16 deletions(-) diffstat for nashorn b/.hgtags | 3 +++ b/THIRD_PARTY_README | 30 ++++++++++++++---------------- 2 files changed, 17 insertions(+), 16 deletions(-) diffstat for jdk a/src/solaris/native/sun/awt/robot_common.c | 101 - a/src/solaris/native/sun/awt/robot_common.h | 39 b/.hgtags | 3 b/THIRD_PARTY_README | 30 b/make/CompileLaunchers.gmk | 4 b/make/CopyFiles.gmk | 11 b/make/CopyIntoClasses.gmk | 6 b/make/CreateJars.gmk | 26 b/make/Images.gmk | 3 b/make/mapfiles/libjava/mapfile-vers | 1 b/src/share/classes/com/sun/tools/jdi/VMState.java | 11 b/src/share/classes/java/lang/Runtime.java | 1 b/src/share/classes/java/lang/Shutdown.java | 6 b/src/share/classes/javax/swing/JList.java | 8 b/src/share/classes/javax/swing/plaf/basic/BasicHTML.java | 31 b/src/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java | 7 b/src/share/classes/javax/swing/text/html/ImageView.java | 32 b/src/share/classes/jdk/jfr/AnnotationElement.java | 420 ++++ b/src/share/classes/jdk/jfr/BooleanFlag.java | 45 b/src/share/classes/jdk/jfr/Category.java | 130 + b/src/share/classes/jdk/jfr/Configuration.java | 197 ++ b/src/share/classes/jdk/jfr/ContentType.java | 45 b/src/share/classes/jdk/jfr/DataAmount.java | 60 b/src/share/classes/jdk/jfr/Description.java | 52 b/src/share/classes/jdk/jfr/Enabled.java | 58 b/src/share/classes/jdk/jfr/Event.java | 171 + b/src/share/classes/jdk/jfr/EventFactory.java | 251 ++ b/src/share/classes/jdk/jfr/EventSettings.java | 141 + b/src/share/classes/jdk/jfr/EventType.java | 237 ++ b/src/share/classes/jdk/jfr/Experimental.java | 59 b/src/share/classes/jdk/jfr/FlightRecorder.java | 353 +++ b/src/share/classes/jdk/jfr/FlightRecorderListener.java | 80 b/src/share/classes/jdk/jfr/FlightRecorderPermission.java | 211 ++ b/src/share/classes/jdk/jfr/Frequency.java | 45 b/src/share/classes/jdk/jfr/Label.java | 55 b/src/share/classes/jdk/jfr/MemoryAddress.java | 45 b/src/share/classes/jdk/jfr/MetadataDefinition.java | 81 b/src/share/classes/jdk/jfr/Name.java | 53 b/src/share/classes/jdk/jfr/Percentage.java | 50 b/src/share/classes/jdk/jfr/Period.java | 72 b/src/share/classes/jdk/jfr/Recording.java | 676 +++++++ b/src/share/classes/jdk/jfr/RecordingState.java | 71 b/src/share/classes/jdk/jfr/Registered.java | 55 b/src/share/classes/jdk/jfr/Relational.java | 43 b/src/share/classes/jdk/jfr/SettingControl.java | 220 ++ b/src/share/classes/jdk/jfr/SettingDefinition.java | 70 b/src/share/classes/jdk/jfr/SettingDescriptor.java | 215 ++ b/src/share/classes/jdk/jfr/StackTrace.java | 57 b/src/share/classes/jdk/jfr/Threshold.java | 69 b/src/share/classes/jdk/jfr/Timespan.java | 75 b/src/share/classes/jdk/jfr/Timestamp.java | 63 b/src/share/classes/jdk/jfr/TransitionFrom.java | 43 b/src/share/classes/jdk/jfr/TransitionTo.java | 43 b/src/share/classes/jdk/jfr/Unsigned.java | 45 b/src/share/classes/jdk/jfr/ValueDescriptor.java | 322 +++ b/src/share/classes/jdk/jfr/conf/default.jfc | 816 ++++++++ b/src/share/classes/jdk/jfr/conf/profile.jfc | 817 ++++++++ b/src/share/classes/jdk/jfr/consumer/ChunkParser.java | 174 + b/src/share/classes/jdk/jfr/consumer/ConstantMap.java | 139 + b/src/share/classes/jdk/jfr/consumer/EventParser.java | 72 b/src/share/classes/jdk/jfr/consumer/LongMap.java | 61 b/src/share/classes/jdk/jfr/consumer/ObjectFactory.java | 85 b/src/share/classes/jdk/jfr/consumer/Parser.java | 45 b/src/share/classes/jdk/jfr/consumer/ParserFactory.java | 303 +++ b/src/share/classes/jdk/jfr/consumer/RecordedClass.java | 103 + b/src/share/classes/jdk/jfr/consumer/RecordedClassLoader.java | 90 b/src/share/classes/jdk/jfr/consumer/RecordedEvent.java | 124 + b/src/share/classes/jdk/jfr/consumer/RecordedFrame.java | 113 + b/src/share/classes/jdk/jfr/consumer/RecordedMethod.java | 120 + b/src/share/classes/jdk/jfr/consumer/RecordedObject.java | 903 +++++++++ b/src/share/classes/jdk/jfr/consumer/RecordedStackTrace.java | 80 b/src/share/classes/jdk/jfr/consumer/RecordedThread.java | 118 + b/src/share/classes/jdk/jfr/consumer/RecordedThreadGroup.java | 70 b/src/share/classes/jdk/jfr/consumer/RecordingFile.java | 269 ++ b/src/share/classes/jdk/jfr/consumer/TimeConverter.java | 72 b/src/share/classes/jdk/jfr/consumer/package-info.java | 82 b/src/share/classes/jdk/jfr/events/AbstractJDKEvent.java | 37 b/src/share/classes/jdk/jfr/events/ActiveRecordingEvent.java | 67 b/src/share/classes/jdk/jfr/events/ActiveSettingEvent.java | 48 b/src/share/classes/jdk/jfr/events/ErrorThrownEvent.java | 44 b/src/share/classes/jdk/jfr/events/ExceptionStatisticsEvent.java | 44 b/src/share/classes/jdk/jfr/events/ExceptionThrownEvent.java | 45 b/src/share/classes/jdk/jfr/events/FileForceEvent.java | 59 b/src/share/classes/jdk/jfr/events/FileReadEvent.java | 66 b/src/share/classes/jdk/jfr/events/FileWriteEvent.java | 61 b/src/share/classes/jdk/jfr/events/SocketReadEvent.java | 79 b/src/share/classes/jdk/jfr/events/SocketWriteEvent.java | 68 b/src/share/classes/jdk/jfr/internal/ASMToolkit.java | 162 + b/src/share/classes/jdk/jfr/internal/AnnotationConstruct.java | 136 + b/src/share/classes/jdk/jfr/internal/Bits.java | 227 ++ b/src/share/classes/jdk/jfr/internal/ChunkInputStream.java | 116 + b/src/share/classes/jdk/jfr/internal/ChunksChannel.java | 145 + b/src/share/classes/jdk/jfr/internal/Control.java | 209 ++ b/src/share/classes/jdk/jfr/internal/Cutoff.java | 75 b/src/share/classes/jdk/jfr/internal/EventClassBuilder.java | 142 + b/src/share/classes/jdk/jfr/internal/EventControl.java | 291 +++ b/src/share/classes/jdk/jfr/internal/EventHandlerCreator.java | 338 +++ b/src/share/classes/jdk/jfr/internal/EventHandlerProxyCreator.java | 126 + b/src/share/classes/jdk/jfr/internal/EventInstrumentation.java | 528 +++++ b/src/share/classes/jdk/jfr/internal/EventWriter.java | 355 +++ b/src/share/classes/jdk/jfr/internal/EventWriterMethod.java | 81 b/src/share/classes/jdk/jfr/internal/JVM.java | 527 +++++ b/src/share/classes/jdk/jfr/internal/JVMSupport.java | 86 b/src/share/classes/jdk/jfr/internal/JVMUpcalls.java | 152 + b/src/share/classes/jdk/jfr/internal/LogLevel.java | 41 b/src/share/classes/jdk/jfr/internal/LogTag.java | 90 b/src/share/classes/jdk/jfr/internal/Logger.java | 69 b/src/share/classes/jdk/jfr/internal/MetadataDescriptor.java | 273 ++ b/src/share/classes/jdk/jfr/internal/MetadataHandler.java | 421 ++++ b/src/share/classes/jdk/jfr/internal/MetadataReader.java | 271 ++ b/src/share/classes/jdk/jfr/internal/MetadataRepository.java | 277 ++ b/src/share/classes/jdk/jfr/internal/MetadataWriter.java | 225 ++ b/src/share/classes/jdk/jfr/internal/OldObjectSample.java | 98 + b/src/share/classes/jdk/jfr/internal/Options.java | 162 + b/src/share/classes/jdk/jfr/internal/PlatformEventType.java | 281 +++ b/src/share/classes/jdk/jfr/internal/PlatformRecorder.java | 554 +++++ b/src/share/classes/jdk/jfr/internal/PlatformRecording.java | 778 ++++++++ b/src/share/classes/jdk/jfr/internal/PrivateAccess.java | 97 + b/src/share/classes/jdk/jfr/internal/Repository.java | 165 + b/src/share/classes/jdk/jfr/internal/RepositoryChunk.java | 210 ++ b/src/share/classes/jdk/jfr/internal/RequestEngine.java | 256 ++ b/src/share/classes/jdk/jfr/internal/SecuritySupport.java | 391 ++++ b/src/share/classes/jdk/jfr/internal/SettingsManager.java | 292 +++ b/src/share/classes/jdk/jfr/internal/ShutdownHook.java | 105 + b/src/share/classes/jdk/jfr/internal/StringPool.java | 135 + b/src/share/classes/jdk/jfr/internal/Type.java | 326 +++ b/src/share/classes/jdk/jfr/internal/TypeLibrary.java | 492 +++++ b/src/share/classes/jdk/jfr/internal/Utils.java | 554 +++++ b/src/share/classes/jdk/jfr/internal/WriteableUserPath.java | 129 + b/src/share/classes/jdk/jfr/internal/consumer/ChunkHeader.java | 184 + b/src/share/classes/jdk/jfr/internal/consumer/RecordingInput.java | 339 +++ b/src/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java | 47 b/src/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java | 201 ++ b/src/share/classes/jdk/jfr/internal/dcmd/DCmdCheck.java | 164 + b/src/share/classes/jdk/jfr/internal/dcmd/DCmdConfigure.java | 217 ++ b/src/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java | 205 ++ b/src/share/classes/jdk/jfr/internal/dcmd/DCmdException.java | 69 b/src/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java | 259 ++ b/src/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java | 87 b/src/share/classes/jdk/jfr/internal/handlers/EventHandler.java | 123 + b/src/share/classes/jdk/jfr/internal/instrument/ConstructorTracerWriter.java | 86 b/src/share/classes/jdk/jfr/internal/instrument/ConstructorWriter.java | 89 b/src/share/classes/jdk/jfr/internal/instrument/FileChannelImplInstrumentor.java | 197 ++ b/src/share/classes/jdk/jfr/internal/instrument/FileInputStreamInstrumentor.java | 115 + b/src/share/classes/jdk/jfr/internal/instrument/FileOutputStreamInstrumentor.java | 99 + b/src/share/classes/jdk/jfr/internal/instrument/JDKEvents.java | 144 + b/src/share/classes/jdk/jfr/internal/instrument/JIClassInstrumentation.java | 140 + b/src/share/classes/jdk/jfr/internal/instrument/JIInliner.java | 113 + b/src/share/classes/jdk/jfr/internal/instrument/JIInstrumentationMethod.java | 36 b/src/share/classes/jdk/jfr/internal/instrument/JIInstrumentationTarget.java | 37 b/src/share/classes/jdk/jfr/internal/instrument/JIMethodCallInliner.java | 149 + b/src/share/classes/jdk/jfr/internal/instrument/JIMethodInliningAdapter.java | 76 b/src/share/classes/jdk/jfr/internal/instrument/JIMethodMergeAdapter.java | 120 + b/src/share/classes/jdk/jfr/internal/instrument/JITypeMapping.java | 35 b/src/share/classes/jdk/jfr/internal/instrument/RandomAccessFileInstrumentor.java | 173 + b/src/share/classes/jdk/jfr/internal/instrument/SocketChannelImplInstrumentor.java | 174 + b/src/share/classes/jdk/jfr/internal/instrument/SocketInputStreamInstrumentor.java | 88 b/src/share/classes/jdk/jfr/internal/instrument/SocketOutputStreamInstrumentor.java | 84 b/src/share/classes/jdk/jfr/internal/instrument/ThrowableTracer.java | 64 b/src/share/classes/jdk/jfr/internal/jfc/JFC.java | 247 ++ b/src/share/classes/jdk/jfr/internal/jfc/JFCParser.java | 85 b/src/share/classes/jdk/jfr/internal/jfc/JFCParserHandler.java | 106 + b/src/share/classes/jdk/jfr/internal/jfc/jfc.xsd | 177 + b/src/share/classes/jdk/jfr/internal/jfc/package-info.java | 31 b/src/share/classes/jdk/jfr/internal/management/ManagementSupport.java | 89 b/src/share/classes/jdk/jfr/internal/settings/BooleanValue.java | 74 b/src/share/classes/jdk/jfr/internal/settings/CutoffSetting.java | 97 + b/src/share/classes/jdk/jfr/internal/settings/EnabledSetting.java | 75 b/src/share/classes/jdk/jfr/internal/settings/PeriodSetting.java | 136 + b/src/share/classes/jdk/jfr/internal/settings/StackTraceSetting.java | 75 b/src/share/classes/jdk/jfr/internal/settings/ThresholdSetting.java | 90 b/src/share/classes/jdk/jfr/internal/test/WhiteBox.java | 48 b/src/share/classes/jdk/jfr/internal/tool/Assemble.java | 127 + b/src/share/classes/jdk/jfr/internal/tool/Command.java | 306 +++ b/src/share/classes/jdk/jfr/internal/tool/Disassemble.java | 250 ++ b/src/share/classes/jdk/jfr/internal/tool/EventPrintWriter.java | 139 + b/src/share/classes/jdk/jfr/internal/tool/Help.java | 76 b/src/share/classes/jdk/jfr/internal/tool/JSONWriter.java | 261 ++ b/src/share/classes/jdk/jfr/internal/tool/Main.java | 110 + b/src/share/classes/jdk/jfr/internal/tool/Metadata.java | 139 + b/src/share/classes/jdk/jfr/internal/tool/PrettyWriter.java | 634 ++++++ b/src/share/classes/jdk/jfr/internal/tool/Print.java | 262 ++ b/src/share/classes/jdk/jfr/internal/tool/StructuredWriter.java | 121 + b/src/share/classes/jdk/jfr/internal/tool/Summary.java | 162 + b/src/share/classes/jdk/jfr/internal/tool/UserDataException.java | 49 b/src/share/classes/jdk/jfr/internal/tool/UserSyntaxException.java | 45 b/src/share/classes/jdk/jfr/internal/tool/Version.java | 51 b/src/share/classes/jdk/jfr/internal/tool/XMLWriter.java | 200 ++ b/src/share/classes/jdk/jfr/package-info.java | 196 ++ b/src/share/classes/jdk/management/jfr/ConfigurationInfo.java | 241 ++ b/src/share/classes/jdk/management/jfr/EventTypeInfo.java | 262 ++ b/src/share/classes/jdk/management/jfr/FlightRecorderMXBean.java | 639 ++++++ b/src/share/classes/jdk/management/jfr/FlightRecorderMXBeanImpl.java | 440 ++++ b/src/share/classes/jdk/management/jfr/MBeanUtils.java | 130 + b/src/share/classes/jdk/management/jfr/RecordingInfo.java | 398 ++++ b/src/share/classes/jdk/management/jfr/SettingDescriptorInfo.java | 232 ++ b/src/share/classes/jdk/management/jfr/Stream.java | 81 b/src/share/classes/jdk/management/jfr/StreamCleanupTask.java | 50 b/src/share/classes/jdk/management/jfr/StreamManager.java | 82 b/src/share/classes/jdk/management/jfr/Stringifier.java | 60 b/src/share/classes/jdk/management/jfr/internal/FlightRecorderMXBeanProvider.java | 113 + b/src/share/classes/sun/java2d/marlin/Renderer.java | 55 b/src/share/classes/sun/management/ExtendedPlatformComponent.java | 27 b/src/share/classes/sun/security/pkcs11/Secmod.java | 4 b/src/share/classes/sun/security/util/DerValue.java | 24 b/src/share/classes/sun/security/x509/CertificateValidity.java | 7 b/src/share/classes/sun/security/x509/X509CRLEntryImpl.java | 5 b/src/share/classes/sun/security/x509/X509CRLImpl.java | 5 b/src/share/javavm/export/jvm.h | 3 b/src/share/lib/security/java.security-aix | 10 b/src/share/lib/security/java.security-linux | 10 b/src/share/lib/security/java.security-macosx | 10 b/src/share/lib/security/java.security-solaris | 11 b/src/share/lib/security/java.security-windows | 10 b/src/share/native/java/lang/Shutdown.c | 7 b/src/solaris/native/java/net/NetworkInterface.c | 1 b/src/solaris/native/sun/awt/awt_Robot.c | 4 b/src/solaris/native/sun/awt/list.c | 107 - b/src/solaris/native/sun/awt/list.h | 61 b/src/solaris/native/sun/awt/multiVis.c | 768 ++++---- b/src/solaris/native/sun/awt/multiVis.h | 48 b/src/solaris/native/sun/awt/wsutils.h | 133 - b/src/windows/classes/com/sun/java/accessibility/AccessBridge.java | 88 b/test/ProblemList.txt | 5 b/test/TEST.ROOT | 2 b/test/TEST.groups | 4 b/test/java/awt/EventQueue/InvocationEventTest/InvocationEventTest.java | 203 ++ b/test/java/awt/Frame/DecoratedExceptions/DecoratedExceptions.java | 81 b/test/java/awt/Window/ShapedAndTranslucentWindows/Common.java | 316 +++ b/test/java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java | 225 ++ b/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java | 69 b/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java | 71 b/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java | 70 b/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java | 68 b/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java | 71 b/test/java/lang/SecurityManager/CheckPackageAccess.java | 3 b/test/java/net/MulticastSocket/TestInterfaces.java | 5 b/test/java/net/NetworkInterface/Equals.java | 5 b/test/java/net/NetworkInterface/IndexTest.java | 5 b/test/java/nio/channels/AsyncCloseAndInterrupt.java | 26 b/test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java | 7 b/test/java/security/cert/X509Certificate/X509BadCertificate.java | 63 b/test/java/security/cert/X509Certificate/bad-cert-1.pem | 21 b/test/javax/accessibility/AccessibleName/GetAccessibleNameTest.java | 137 + b/test/javax/swing/JRadioButton/8033699/bug8033699.java | 46 b/test/javax/swing/JTextPane/TestJTextPaneHTMLRendering.java | 173 + b/test/javax/xml/jaxp/parsers/8213734/SAXParserTest.java | 79 b/test/jdk/jfr/TEST.properties | 2 b/test/jdk/jfr/api/consumer/TEST.properties | 2 b/test/jdk/jfr/api/consumer/TestFieldAccess.java | 151 + b/test/jdk/jfr/api/consumer/TestGetStackTrace.java | 103 + b/test/jdk/jfr/api/consumer/TestHiddenMethod.java | 112 + b/test/jdk/jfr/api/consumer/TestMethodGetModifiers.java | 81 b/test/jdk/jfr/api/consumer/TestReadTwice.java | 85 b/test/jdk/jfr/api/consumer/TestRecordedClassLoader.java | 120 + b/test/jdk/jfr/api/consumer/TestRecordedEvent.java | 110 + b/test/jdk/jfr/api/consumer/TestRecordedEventGetThread.java | 72 b/test/jdk/jfr/api/consumer/TestRecordedEventGetThreadOther.java | 109 + b/test/jdk/jfr/api/consumer/TestRecordedFrame.java | 122 + b/test/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java | 180 + b/test/jdk/jfr/api/consumer/TestRecordedInstantEventTimestamp.java | 60 b/test/jdk/jfr/api/consumer/TestRecordedMethodDescriptor.java | 97 + b/test/jdk/jfr/api/consumer/TestRecordedObject.java | 408 ++++ b/test/jdk/jfr/api/consumer/TestRecordedThreadGroupParent.java | 89 b/test/jdk/jfr/api/consumer/TestRecordingFile.java | 408 ++++ b/test/jdk/jfr/api/consumer/TestRecordingFileReadEventEof.java | 62 b/test/jdk/jfr/api/consumer/TestRecordingInternals.java | 81 b/test/jdk/jfr/api/consumer/TestSingleRecordedEvent.java | 69 b/test/jdk/jfr/api/consumer/TestToString.java | 95 + b/test/jdk/jfr/api/consumer/TestValueDescriptorRecorded.java | 79 b/test/jdk/jfr/api/event/TEST.properties | 2 b/test/jdk/jfr/api/event/TestAbstractEvent.java | 117 + b/test/jdk/jfr/api/event/TestBeginEnd.java | 114 + b/test/jdk/jfr/api/event/TestClinitRegistration.java | 206 ++ b/test/jdk/jfr/api/event/TestClonedEvent.java | 96 + b/test/jdk/jfr/api/event/TestEnableDisable.java | 102 + b/test/jdk/jfr/api/event/TestEventFactory.java | 81 b/test/jdk/jfr/api/event/TestEventFactoryRegisterTwice.java | 75 b/test/jdk/jfr/api/event/TestEventFactoryRegistration.java | 107 + b/test/jdk/jfr/api/event/TestExtends.java | 188 ++ b/test/jdk/jfr/api/event/TestGetDuration.java | 131 + b/test/jdk/jfr/api/event/TestIsEnabled.java | 88 b/test/jdk/jfr/api/event/TestIsEnabledMultiple.java | 128 + b/test/jdk/jfr/api/event/TestOwnCommit.java | 124 + b/test/jdk/jfr/api/event/TestShouldCommit.java | 195 ++ b/test/jdk/jfr/api/event/TestStaticEnable.java | 86 b/test/jdk/jfr/api/event/dynamic/TestDynamicAnnotations.java | 219 ++ b/test/jdk/jfr/api/event/dynamic/TestEventFactory.java | 289 +++ b/test/jdk/jfr/api/flightrecorder/MyListener.java | 48 b/test/jdk/jfr/api/flightrecorder/TestAddListenerTwice.java | 58 b/test/jdk/jfr/api/flightrecorder/TestAddPeriodicEvent.java | 107 + b/test/jdk/jfr/api/flightrecorder/TestFlightRecorderListenerRecorderInitialized.java | 99 + b/test/jdk/jfr/api/flightrecorder/TestGetEventTypes.java | 95 + b/test/jdk/jfr/api/flightrecorder/TestGetPlatformRecorder.java | 46 b/test/jdk/jfr/api/flightrecorder/TestGetRecordings.java | 85 b/test/jdk/jfr/api/flightrecorder/TestGetSettings.java | 132 + b/test/jdk/jfr/api/flightrecorder/TestIsAvailable.java | 47 b/test/jdk/jfr/api/flightrecorder/TestIsInitialized.java | 51 b/test/jdk/jfr/api/flightrecorder/TestListener.java | 66 b/test/jdk/jfr/api/flightrecorder/TestListenerNull.java | 54 b/test/jdk/jfr/api/flightrecorder/TestPeriodicEventsSameHook.java | 62 b/test/jdk/jfr/api/flightrecorder/TestRecorderInitializationCallback.java | 64 b/test/jdk/jfr/api/flightrecorder/TestRegisterUnregisterEvent.java | 82 b/test/jdk/jfr/api/flightrecorder/TestSettingsControl.java | 94 + b/test/jdk/jfr/api/flightrecorder/TestSnapshot.java | 187 ++ b/test/jdk/jfr/api/metadata/annotations/TestCategory.java | 53 b/test/jdk/jfr/api/metadata/annotations/TestContentType.java | 77 b/test/jdk/jfr/api/metadata/annotations/TestDescription.java | 98 + b/test/jdk/jfr/api/metadata/annotations/TestDynamicAnnotation.java | 56 b/test/jdk/jfr/api/metadata/annotations/TestEnabled.java | 72 b/test/jdk/jfr/api/metadata/annotations/TestExperimental.java | 80 b/test/jdk/jfr/api/metadata/annotations/TestFieldAnnotations.java | 110 + b/test/jdk/jfr/api/metadata/annotations/TestFormatMissingValue.java | 124 + b/test/jdk/jfr/api/metadata/annotations/TestHasValue.java | 65 b/test/jdk/jfr/api/metadata/annotations/TestInheritedAnnotations.java | 208 ++ b/test/jdk/jfr/api/metadata/annotations/TestLabel.java | 96 + b/test/jdk/jfr/api/metadata/annotations/TestMetadata.java | 85 b/test/jdk/jfr/api/metadata/annotations/TestName.java | 110 + b/test/jdk/jfr/api/metadata/annotations/TestPeriod.java | 52 b/test/jdk/jfr/api/metadata/annotations/TestRegistered.java | 68 b/test/jdk/jfr/api/metadata/annotations/TestRegisteredFalseAndRunning.java | 53 b/test/jdk/jfr/api/metadata/annotations/TestRelational.java | 72 b/test/jdk/jfr/api/metadata/annotations/TestSimpleMetadataEvent.java | 60 b/test/jdk/jfr/api/metadata/annotations/TestStackTrace.java | 61 b/test/jdk/jfr/api/metadata/annotations/TestThreshold.java | 52 b/test/jdk/jfr/api/metadata/annotations/TestTypesIdentical.java | 95 + b/test/jdk/jfr/api/metadata/eventtype/EventWithCustomSettings.java | 52 b/test/jdk/jfr/api/metadata/eventtype/TestGetAnnotation.java | 82 b/test/jdk/jfr/api/metadata/eventtype/TestGetAnnotationElements.java | 153 + b/test/jdk/jfr/api/metadata/eventtype/TestGetAnnotations.java | 76 b/test/jdk/jfr/api/metadata/eventtype/TestGetCategory.java | 70 b/test/jdk/jfr/api/metadata/eventtype/TestGetDefaultValues.java | 99 + b/test/jdk/jfr/api/metadata/eventtype/TestGetDescription.java | 80 b/test/jdk/jfr/api/metadata/eventtype/TestGetEventType.java | 62 b/test/jdk/jfr/api/metadata/eventtype/TestGetField.java | 77 b/test/jdk/jfr/api/metadata/eventtype/TestGetFields.java | 86 b/test/jdk/jfr/api/metadata/eventtype/TestGetSettings.java | 57 b/test/jdk/jfr/api/metadata/eventtype/TestUnloadingEventClass.java | 180 + b/test/jdk/jfr/api/metadata/settingdescriptor/AnnotatedSetting.java | 60 b/test/jdk/jfr/api/metadata/settingdescriptor/BaseEvent.java | 73 b/test/jdk/jfr/api/metadata/settingdescriptor/CustomEvent.java | 103 + b/test/jdk/jfr/api/metadata/settingdescriptor/PlainSetting.java | 48 b/test/jdk/jfr/api/metadata/settingdescriptor/TestDefaultValue.java | 59 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetAnnotation.java | 70 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetAnnotationElement.java | 87 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetContentType.java | 73 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetDescription.java | 70 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetLabel.java | 70 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetName.java | 65 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetTypeId.java | 73 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetTypeName.java | 68 b/test/jdk/jfr/api/metadata/valuedescriptor/TestClasses.java | 86 b/test/jdk/jfr/api/metadata/valuedescriptor/TestConstructor.java | 70 b/test/jdk/jfr/api/metadata/valuedescriptor/TestGetAnnotations.java | 95 + b/test/jdk/jfr/api/metadata/valuedescriptor/TestGetFields.java | 47 b/test/jdk/jfr/api/metadata/valuedescriptor/TestIsArray.java | 64 b/test/jdk/jfr/api/metadata/valuedescriptor/TestSimpleTypes.java | 132 + b/test/jdk/jfr/api/metadata/valuedescriptor/TestValueDescriptorContentType.java | 90 b/test/jdk/jfr/api/modules/TestModularizedEvent.java | 104 + b/test/jdk/jfr/api/modules/src_mods/test.jfr.annotation/test/jfr/annotation/ModularizedAnnotation.java | 42 b/test/jdk/jfr/api/modules/src_mods/test.jfr.event/test/jfr/event/ModularizedOrdinaryEvent.java | 44 b/test/jdk/jfr/api/modules/src_mods/test.jfr.event/test/jfr/event/ModularizedPeriodicEvent.java | 44 b/test/jdk/jfr/api/modules/src_mods/test.jfr.main/test/jfr/main/MainTest.java | 154 + b/test/jdk/jfr/api/modules/src_mods/test.jfr.setting/test/jfr/setting/ModularizedSetting.java | 62 b/test/jdk/jfr/api/recorder/TestRecorderInitialized.java | 68 b/test/jdk/jfr/api/recorder/TestRecorderListener.java | 106 + b/test/jdk/jfr/api/recorder/TestStartStopRecording.java | 80 b/test/jdk/jfr/api/recording/destination/TestDestFileExist.java | 68 b/test/jdk/jfr/api/recording/destination/TestDestFileReadOnly.java | 65 b/test/jdk/jfr/api/recording/destination/TestDestInvalid.java | 104 + b/test/jdk/jfr/api/recording/destination/TestDestLongPath.java | 66 b/test/jdk/jfr/api/recording/destination/TestDestMultiple.java | 111 + b/test/jdk/jfr/api/recording/destination/TestDestReadOnly.java | 84 b/test/jdk/jfr/api/recording/destination/TestDestState.java | 79 b/test/jdk/jfr/api/recording/destination/TestDestToDiskFalse.java | 80 b/test/jdk/jfr/api/recording/destination/TestDestToDiskTrue.java | 73 b/test/jdk/jfr/api/recording/destination/TestDestWithDuration.java | 76 b/test/jdk/jfr/api/recording/dump/TestDump.java | 61 b/test/jdk/jfr/api/recording/dump/TestDumpInvalid.java | 85 b/test/jdk/jfr/api/recording/dump/TestDumpLongPath.java | 70 b/test/jdk/jfr/api/recording/dump/TestDumpMultiple.java | 105 + b/test/jdk/jfr/api/recording/dump/TestDumpReadOnly.java | 70 b/test/jdk/jfr/api/recording/dump/TestDumpState.java | 107 + b/test/jdk/jfr/api/recording/event/TEST.properties | 2 b/test/jdk/jfr/api/recording/event/TestChunkPeriod.java | 103 + b/test/jdk/jfr/api/recording/event/TestEnableClass.java | 53 b/test/jdk/jfr/api/recording/event/TestEnableName.java | 62 b/test/jdk/jfr/api/recording/event/TestEventTime.java | 184 + b/test/jdk/jfr/api/recording/event/TestLoadEventAfterStart.java | 90 b/test/jdk/jfr/api/recording/event/TestPeriod.java | 127 + b/test/jdk/jfr/api/recording/event/TestReEnableClass.java | 80 b/test/jdk/jfr/api/recording/event/TestReEnableMultiple.java | 147 + b/test/jdk/jfr/api/recording/event/TestReEnableName.java | 97 + b/test/jdk/jfr/api/recording/event/TestRecordingEnableDisable.java | 125 + b/test/jdk/jfr/api/recording/event/TestThreshold.java | 91 b/test/jdk/jfr/api/recording/misc/TestGetId.java | 68 b/test/jdk/jfr/api/recording/misc/TestGetSize.java | 64 b/test/jdk/jfr/api/recording/misc/TestGetSizeToMem.java | 66 b/test/jdk/jfr/api/recording/misc/TestGetStream.java | 154 + b/test/jdk/jfr/api/recording/misc/TestRecordingBase.java | 175 + b/test/jdk/jfr/api/recording/misc/TestRecordingCopy.java | 112 + b/test/jdk/jfr/api/recording/options/TestDuration.java | 66 b/test/jdk/jfr/api/recording/options/TestName.java | 93 + b/test/jdk/jfr/api/recording/settings/TestConfigurationGetContents.java | 70 b/test/jdk/jfr/api/recording/settings/TestCreateConfigFromPath.java | 85 b/test/jdk/jfr/api/recording/settings/TestCreateConfigFromReader.java | 87 b/test/jdk/jfr/api/recording/settings/TestGetConfigurations.java | 80 b/test/jdk/jfr/api/recording/settings/TestSettingsAvailability.java | 123 + b/test/jdk/jfr/api/recording/settings/settings.jfc | 11 b/test/jdk/jfr/api/recording/state/TestOptionState.java | 92 b/test/jdk/jfr/api/recording/state/TestState.java | 56 b/test/jdk/jfr/api/recording/state/TestStateDuration.java | 73 b/test/jdk/jfr/api/recording/state/TestStateIdenticalListeners.java | 73 b/test/jdk/jfr/api/recording/state/TestStateInvalid.java | 70 b/test/jdk/jfr/api/recording/state/TestStateMultiple.java | 86 b/test/jdk/jfr/api/recording/state/TestStateScheduleStart.java | 73 b/test/jdk/jfr/api/recording/time/TestTime.java | 78 b/test/jdk/jfr/api/recording/time/TestTimeDuration.java | 68 b/test/jdk/jfr/api/recording/time/TestTimeMultiple.java | 87 b/test/jdk/jfr/api/recording/time/TestTimeScheduleStart.java | 68 b/test/jdk/jfr/api/settings/RegExpControl.java | 51 b/test/jdk/jfr/api/settings/StringListSetting.java | 105 + b/test/jdk/jfr/api/settings/TestFilterEvents.java | 99 + b/test/jdk/jfr/event/TEST.properties | 2 b/test/jdk/jfr/event/compiler/TestAllocInNewTLAB.java | 127 + b/test/jdk/jfr/event/compiler/TestAllocOutsideTLAB.java | 104 + b/test/jdk/jfr/event/compiler/TestCodeCacheConfig.java | 104 + b/test/jdk/jfr/event/compiler/TestCodeCacheFull.java | 106 + b/test/jdk/jfr/event/compiler/TestCodeCacheStats.java | 65 b/test/jdk/jfr/event/compiler/TestCodeSweeper.java | 224 ++ b/test/jdk/jfr/event/compiler/TestCodeSweeperConfig.java | 61 b/test/jdk/jfr/event/compiler/TestCompilerCompile.java | 141 + b/test/jdk/jfr/event/compiler/TestCompilerConfig.java | 59 b/test/jdk/jfr/event/compiler/TestCompilerInlining.java | 406 ++++ b/test/jdk/jfr/event/compiler/TestCompilerPhase.java | 89 b/test/jdk/jfr/event/compiler/TestCompilerStats.java | 68 b/test/jdk/jfr/event/gc/collection/AppGCProvoker.java | 57 b/test/jdk/jfr/event/gc/collection/GCEventAll.java | 531 +++++ b/test/jdk/jfr/event/gc/collection/GCGarbageCollectionUtil.java | 105 + b/test/jdk/jfr/event/gc/collection/TestGCCauseWithCMSConcurrent.java | 47 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithCMSMarkSweep.java | 48 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithG1ConcurrentMark.java | 49 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithG1FullCollection.java | 48 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithPSMarkSweep.java | 49 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithParallelOld.java | 47 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithSerial.java | 47 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithCMSConcurrent.java | 43 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithCMSMarkSweep.java | 43 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithG1ConcurrentMark.java | 44 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithG1FullCollection.java | 42 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithPSMarkSweep.java | 42 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithParNew.java | 43 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithParallelOld.java | 42 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithSerial.java | 41 b/test/jdk/jfr/event/gc/collection/TestGCGarbageCollectionEvent.java | 68 b/test/jdk/jfr/event/gc/collection/TestGCWithFasttime.java | 66 b/test/jdk/jfr/event/gc/collection/TestYoungGarbageCollectionEventWithDefNew.java | 42 b/test/jdk/jfr/event/gc/collection/TestYoungGarbageCollectionEventWithG1New.java | 42 b/test/jdk/jfr/event/gc/collection/TestYoungGarbageCollectionEventWithParNew.java | 42 b/test/jdk/jfr/event/gc/collection/TestYoungGarbageCollectionEventWithParallelScavenge.java | 42 b/test/jdk/jfr/event/gc/collection/YoungGarbageCollectionEvent.java | 79 b/test/jdk/jfr/event/gc/collection/gc-testsettings.jfc | 32 b/test/jdk/jfr/event/gc/configuration/GCHeapConfigurationEventTester.java | 52 b/test/jdk/jfr/event/gc/configuration/GCHeapConfigurationEventVerifier.java | 68 b/test/jdk/jfr/event/gc/configuration/GCYoungGenerationConfigurationEventTester.java | 51 b/test/jdk/jfr/event/gc/configuration/TestGCConfigurationEvent.java | 112 + b/test/jdk/jfr/event/gc/configuration/TestGCConfigurationEventWithDefaultPauseTarget.java | 67 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java | 64 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.sh | 61 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithHeapBasedOops.java | 59 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithHeapBasedOops.sh | 63 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithZeroBasedOops.java | 60 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithZeroBasedOops.sh | 60 b/test/jdk/jfr/event/gc/configuration/TestGCSurvivorConfigurationEvent.java | 76 b/test/jdk/jfr/event/gc/configuration/TestGCTLABConfigurationEvent.java | 86 b/test/jdk/jfr/event/gc/configuration/TestGCYoungGenerationConfigurationEventWithMinAndMaxSize.java | 88 b/test/jdk/jfr/event/gc/configuration/TestGCYoungGenerationConfigurationEventWithNewRatio.java | 66 b/test/jdk/jfr/event/gc/detailed/ExecuteOOMApp.java | 63 b/test/jdk/jfr/event/gc/detailed/OOMApp.java | 68 b/test/jdk/jfr/event/gc/detailed/PromotionEvent.java | 205 ++ b/test/jdk/jfr/event/gc/detailed/PromotionFailedEvent.java | 63 b/test/jdk/jfr/event/gc/detailed/StressAllocationGCEvents.java | 201 ++ b/test/jdk/jfr/event/gc/detailed/TestCMSConcurrentModeFailureEvent.java | 88 b/test/jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java | 75 b/test/jdk/jfr/event/gc/detailed/TestEvacuationInfoEvent.java | 137 + b/test/jdk/jfr/event/gc/detailed/TestG1ConcurrentModeFailureEvent.java | 88 b/test/jdk/jfr/event/gc/detailed/TestG1EvacMemoryStatsEvent.java | 76 b/test/jdk/jfr/event/gc/detailed/TestG1HeapRegionInformationEvent.java | 74 b/test/jdk/jfr/event/gc/detailed/TestG1HeapRegionTypeChangeEvent.java | 89 b/test/jdk/jfr/event/gc/detailed/TestG1MMUEvent.java | 82 b/test/jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java | 44 b/test/jdk/jfr/event/gc/detailed/TestPromotionEventWithParallelScavenge.java | 42 b/test/jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithDefNew.java | 43 b/test/jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithParNew.java | 45 b/test/jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithParallelScavenge.java | 44 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java | 45 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java | 39 b/test/jdk/jfr/event/gc/detailed/TestTenuringDistributionEvent.java | 87 b/test/jdk/jfr/event/gc/detailed/concurrentmodefailure-testsettings.jfc | 32 b/test/jdk/jfr/event/gc/detailed/evacuationfailed-testsettings.jfc | 32 b/test/jdk/jfr/event/gc/detailed/promotionfailed-testsettings.jfc | 32 b/test/jdk/jfr/event/gc/heapsummary/HeapSummaryEventAllGcs.java | 225 ++ b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryCommittedSize.java | 92 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventConcurrentCMS.java | 94 + b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventDefNewSerial.java | 41 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventG1.java | 41 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSParOld.java | 41 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSSerial.java | 41 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventParNewCMS.java | 41 b/test/jdk/jfr/event/gc/objectcount/ObjectCountAfterGCEvent.java | 98 + b/test/jdk/jfr/event/gc/objectcount/ObjectCountEventVerifier.java | 80 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithCMSConcurrent.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithCMSMarkSweep.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithG1ConcurrentMark.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithG1FullCollection.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithPSMarkSweep.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithParallelOld.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithSerial.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountEvent.java | 86 b/test/jdk/jfr/event/gc/refstat/RefStatEvent.java | 102 + b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithCMSConcurrent.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithCMSMarkSweep.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithDefNew.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithG1ConcurrentMark.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithG1FullCollection.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithG1New.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithPSMarkSweep.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithParallelOld.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithParallelScavenge.java | 41 b/test/jdk/jfr/event/gc/stacktrace/AllocationStackTrace.java | 497 +++++ b/test/jdk/jfr/event/gc/stacktrace/TEST.properties | 2 b/test/jdk/jfr/event/gc/stacktrace/TestConcMarkSweepAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestDefNewAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestG1HumongousAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestG1OldAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestG1YoungAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestMarkSweepCompactAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestMetaspaceConcMarkSweepGCAllocationPendingStackTrace.java | 42 b/test/jdk/jfr/event/gc/stacktrace/TestMetaspaceG1GCAllocationPendingStackTrace.java | 42 b/test/jdk/jfr/event/gc/stacktrace/TestMetaspaceParallelGCAllocationPendingStackTrace.java | 42 b/test/jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java | 42 b/test/jdk/jfr/event/gc/stacktrace/TestParNewAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestParallelMarkSweepAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestParallelScavengeAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/io/EvilInstrument.java | 158 + b/test/jdk/jfr/event/io/IOEvent.java | 210 ++ b/test/jdk/jfr/event/io/IOHelper.java | 129 + b/test/jdk/jfr/event/io/InstrumentationCallback.java | 49 b/test/jdk/jfr/event/io/MakeJAR.sh | 45 b/test/jdk/jfr/event/io/TestDisabledEvents.java | 134 + b/test/jdk/jfr/event/io/TestFileChannelEvents.java | 123 + b/test/jdk/jfr/event/io/TestFileReadOnly.java | 101 + b/test/jdk/jfr/event/io/TestFileStreamEvents.java | 96 + b/test/jdk/jfr/event/io/TestInstrumentation.java | 373 ++++ b/test/jdk/jfr/event/io/TestInstrumentation.mf | 4 b/test/jdk/jfr/event/io/TestRandomAccessFileEvents.java | 116 + b/test/jdk/jfr/event/io/TestRandomAccessFileThread.java | 226 ++ b/test/jdk/jfr/event/io/TestSocketChannelEvents.java | 130 + b/test/jdk/jfr/event/io/TestSocketEvents.java | 121 + b/test/jdk/jfr/event/metadata/TestDefaultConfigurations.java | 204 ++ b/test/jdk/jfr/event/metadata/TestEventMetadata.java | 216 ++ b/test/jdk/jfr/event/metadata/TestLookForUntestedEvents.java | 217 ++ b/test/jdk/jfr/event/oldobject/OldObjects.java | 281 +++ b/test/jdk/jfr/event/oldobject/TestAllocationTime.java | 126 + b/test/jdk/jfr/event/oldobject/TestArrayInformation.java | 125 + b/test/jdk/jfr/event/oldobject/TestCMS.java | 78 b/test/jdk/jfr/event/oldobject/TestCircularReference.java | 86 b/test/jdk/jfr/event/oldobject/TestClassLoader.java | 127 + b/test/jdk/jfr/event/oldobject/TestClassLoaderLeak.java | 82 b/test/jdk/jfr/event/oldobject/TestFieldInformation.java | 121 + b/test/jdk/jfr/event/oldobject/TestG1.java | 78 b/test/jdk/jfr/event/oldobject/TestHeapDeep.java | 87 b/test/jdk/jfr/event/oldobject/TestHeapShallow.java | 83 b/test/jdk/jfr/event/oldobject/TestLargeRootSet.java | 127 + b/test/jdk/jfr/event/oldobject/TestLastKnownHeapUsage.java | 87 b/test/jdk/jfr/event/oldobject/TestListenerLeak.java | 102 + b/test/jdk/jfr/event/oldobject/TestMetadataObject.java | 50 b/test/jdk/jfr/event/oldobject/TestMetadataRetention.java | 189 ++ b/test/jdk/jfr/event/oldobject/TestObjectDescription.java | 216 ++ b/test/jdk/jfr/event/oldobject/TestParallel.java | 78 b/test/jdk/jfr/event/oldobject/TestParallelOld.java | 78 b/test/jdk/jfr/event/oldobject/TestReferenceChainLimit.java | 84 b/test/jdk/jfr/event/oldobject/TestSanityDefault.java | 88 b/test/jdk/jfr/event/oldobject/TestSerial.java | 78 b/test/jdk/jfr/event/oldobject/TestThreadLocalLeak.java | 79 b/test/jdk/jfr/event/os/TestCPUInformation.java | 61 b/test/jdk/jfr/event/os/TestCPULoad.java | 79 b/test/jdk/jfr/event/os/TestCPUTimeStampCounter.java | 60 b/test/jdk/jfr/event/os/TestInitialEnvironmentVariable.java | 65 b/test/jdk/jfr/event/os/TestInitialEnvironmentVariable.sh | 38 b/test/jdk/jfr/event/os/TestOSInfo.java | 57 b/test/jdk/jfr/event/os/TestPhysicalMemoryEvent.java | 58 b/test/jdk/jfr/event/os/TestSystemProcess.java | 57 b/test/jdk/jfr/event/os/TestThreadContextSwitches.java | 56 b/test/jdk/jfr/event/profiling/TestFullStackTrace.java | 171 + b/test/jdk/jfr/event/runtime/TestActiveRecordingEvent.java | 126 + b/test/jdk/jfr/event/runtime/TestActiveSettingEvent.java | 253 ++ b/test/jdk/jfr/event/runtime/TestBiasedLockRevocationEvents.java | 319 +++ b/test/jdk/jfr/event/runtime/TestClassDefineEvent.java | 80 b/test/jdk/jfr/event/runtime/TestClassLoadEvent.java | 86 b/test/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java | 133 + b/test/jdk/jfr/event/runtime/TestClassLoadingStatisticsEvent.java | 142 + b/test/jdk/jfr/event/runtime/TestClassUnloadEvent.java | 93 + b/test/jdk/jfr/event/runtime/TestClasses.java | 83 b/test/jdk/jfr/event/runtime/TestExceptionEvents.java | 200 ++ b/test/jdk/jfr/event/runtime/TestExceptionSubclass.java | 65 b/test/jdk/jfr/event/runtime/TestJavaBlockedEvent.java | 119 + b/test/jdk/jfr/event/runtime/TestJavaMonitorInflateEvent.java | 116 + b/test/jdk/jfr/event/runtime/TestJavaMonitorWaitEvent.java | 107 + b/test/jdk/jfr/event/runtime/TestJavaMonitorWaitTimeOut.java | 126 + b/test/jdk/jfr/event/runtime/TestJavaThreadStatisticsEvent.java | 91 b/test/jdk/jfr/event/runtime/TestJavaThreadStatisticsEventBean.java | 85 b/test/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java | 104 + b/test/jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java | 108 + b/test/jdk/jfr/event/runtime/TestSafepointEvents.java | 117 + b/test/jdk/jfr/event/runtime/TestShutdownEvent.java | 253 ++ b/test/jdk/jfr/event/runtime/TestSizeTFlags.java | 109 + b/test/jdk/jfr/event/runtime/TestSystemPropertyEvent.java | 112 + b/test/jdk/jfr/event/runtime/TestThreadAllocationEvent.java | 210 ++ b/test/jdk/jfr/event/runtime/TestThreadCpuTimeEvent.java | 276 ++ b/test/jdk/jfr/event/runtime/TestThreadDumpEvent.java | 66 b/test/jdk/jfr/event/runtime/TestThreadParkEvent.java | 132 + b/test/jdk/jfr/event/runtime/TestThreadSleepEvent.java | 72 b/test/jdk/jfr/event/runtime/TestThreadStartEndEvents.java | 138 + b/test/jdk/jfr/event/runtime/TestThrowableInstrumentation.java | 61 b/test/jdk/jfr/event/runtime/TestVMInfoEvent.flags | 1 b/test/jdk/jfr/event/runtime/TestVMInfoEvent.java | 80 b/test/jdk/jfr/event/runtime/TestVMInfoEvent.sh | 35 b/test/jdk/jfr/event/runtime/TestVMOperation.java | 72 b/test/jdk/jfr/event/runtime/TestVmFlagChangedEvent.java | 118 + b/test/jdk/jfr/event/runtime/exception.security.policy | 20 b/test/jdk/jfr/event/sampling/TestNative.java | 94 + b/test/jdk/jfr/event/sampling/libTestNative.c | 41 b/test/jdk/jfr/javaagent/EventEmitterAgent.java | 106 + b/test/jdk/jfr/javaagent/JavaAgentBuilder.java | 87 b/test/jdk/jfr/javaagent/TestLoadedAgent.java | 57 b/test/jdk/jfr/javaagent/TestPremainAgent.java | 47 b/test/jdk/jfr/jcmd/JcmdAsserts.java | 190 ++ b/test/jdk/jfr/jcmd/JcmdHelper.java | 123 + b/test/jdk/jfr/jcmd/TEST.properties | 2 b/test/jdk/jfr/jcmd/TestJcmdConfigure.java | 120 + b/test/jdk/jfr/jcmd/TestJcmdDump.java | 172 + b/test/jdk/jfr/jcmd/TestJcmdDumpGeneratedFilename.java | 136 + b/test/jdk/jfr/jcmd/TestJcmdDumpLimited.java | 294 +++ b/test/jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java | 133 + b/test/jdk/jfr/jcmd/TestJcmdLegacy.java | 93 + b/test/jdk/jfr/jcmd/TestJcmdSaveToFile.java | 70 b/test/jdk/jfr/jcmd/TestJcmdStartDirNotExist.java | 54 b/test/jdk/jfr/jcmd/TestJcmdStartInvaldFile.java | 52 b/test/jdk/jfr/jcmd/TestJcmdStartPathToGCRoots.java | 86 b/test/jdk/jfr/jcmd/TestJcmdStartReadOnlyFile.java | 60 b/test/jdk/jfr/jcmd/TestJcmdStartStopDefault.java | 77 b/test/jdk/jfr/jcmd/TestJcmdStartWithOptions.java | 143 + b/test/jdk/jfr/jcmd/TestJcmdStartWithSettings.java | 178 + b/test/jdk/jfr/jcmd/TestJcmdStopInvalidFile.java | 58 b/test/jdk/jfr/jcmd/TestJcmdStopReadOnlyFile.java | 65 b/test/jdk/jfr/jcmd/jcmd-testsettings.2.jfc | 10 b/test/jdk/jfr/jcmd/jcmd-testsettings.jfc | 10 b/test/jdk/jfr/jcmd/jcmd-testsettings3.jfc | 8 b/test/jdk/jfr/jcmd/legacy.jfc | 7 b/test/jdk/jfr/jmx/JmxHelper.java | 281 +++ b/test/jdk/jfr/jmx/TEST.properties | 2 b/test/jdk/jfr/jmx/TestClone.java | 102 + b/test/jdk/jfr/jmx/TestCloneRepeat.java | 84 b/test/jdk/jfr/jmx/TestConfigurationInfo.java | 60 b/test/jdk/jfr/jmx/TestCopyTo.java | 65 b/test/jdk/jfr/jmx/TestCopyToInvalidPath.java | 59 b/test/jdk/jfr/jmx/TestCopyToReadOnlyDir.java | 72 b/test/jdk/jfr/jmx/TestCopyToRunning.java | 83 b/test/jdk/jfr/jmx/TestEventTypes.java | 156 + b/test/jdk/jfr/jmx/TestGetRecordings.java | 50 b/test/jdk/jfr/jmx/TestGetRecordingsMultiple.java | 122 + b/test/jdk/jfr/jmx/TestMultipleRecordings.java | 95 + b/test/jdk/jfr/jmx/TestNotificationListener.java | 65 b/test/jdk/jfr/jmx/TestPredefinedConfiguration.java | 61 b/test/jdk/jfr/jmx/TestPredefinedConfigurationInvalid.java | 75 b/test/jdk/jfr/jmx/TestRecordingOptions.java | 130 + b/test/jdk/jfr/jmx/TestRecordingSettings.java | 76 b/test/jdk/jfr/jmx/TestRecordingSettingsInvalid.java | 81 b/test/jdk/jfr/jmx/TestRecordingSettingsMultiple.java | 87 b/test/jdk/jfr/jmx/TestRecordingState.java | 59 b/test/jdk/jfr/jmx/TestRecordingStateInvalid.java | 97 + b/test/jdk/jfr/jmx/TestSetConfiguration.java | 80 b/test/jdk/jfr/jmx/TestSetConfigurationInvalid.java | 108 + b/test/jdk/jfr/jmx/TestSnapshot.java | 75 b/test/jdk/jfr/jmx/TestStartRecording.java | 66 b/test/jdk/jfr/jmx/TestStream.java | 83 b/test/jdk/jfr/jmx/TestStreamClosed.java | 63 b/test/jdk/jfr/jmx/TestStreamMultiple.java | 81 b/test/jdk/jfr/jmx/TestWrongId.java | 64 b/test/jdk/jfr/jmx/info/TestConfigurationInfo.java | 109 + b/test/jdk/jfr/jmx/info/TestEventTypeInfo.java | 89 b/test/jdk/jfr/jmx/info/TestRecordingInfo.java | 75 b/test/jdk/jfr/jmx/info/TestSettingDescriptorInfo.java | 75 b/test/jdk/jfr/jmx/security/TestEnoughPermission.java | 105 + b/test/jdk/jfr/jmx/security/TestNoControlPermission.java | 73 b/test/jdk/jfr/jmx/security/TestNoMonitorPermission.java | 65 b/test/jdk/jfr/jmx/security/TestNotificationListenerPermission.java | 87 b/test/jdk/jfr/jmx/security/enough.policy | 19 b/test/jdk/jfr/jmx/security/listener.policy | 11 b/test/jdk/jfr/jmx/security/nocontrol.policy | 11 b/test/jdk/jfr/jmx/security/nomonitor.policy | 11 b/test/jdk/jfr/jvm/HelloWorldEvent1.java | 40 b/test/jdk/jfr/jvm/HelloWorldEvent2.java | 40 b/test/jdk/jfr/jvm/TestBeginAndEnd.java | 49 b/test/jdk/jfr/jvm/TestClassId.java | 60 b/test/jdk/jfr/jvm/TestCounterTime.java | 62 b/test/jdk/jfr/jvm/TestCreateNative.java | 76 b/test/jdk/jfr/jvm/TestDumpOnCrash.java | 110 + b/test/jdk/jfr/jvm/TestGetAllEventClasses.java | 125 + b/test/jdk/jfr/jvm/TestGetEventWriter.java | 51 b/test/jdk/jfr/jvm/TestGetStackTraceId.java | 71 b/test/jdk/jfr/jvm/TestJFRIntrinsic.java | 154 + b/test/jdk/jfr/jvm/TestJavaEvent.java | 213 ++ b/test/jdk/jfr/jvm/TestLargeJavaEvent512k.java | 148 + b/test/jdk/jfr/jvm/TestLargeJavaEvent64k.java | 148 + b/test/jdk/jfr/jvm/TestLogImplementation.java | 144 + b/test/jdk/jfr/jvm/TestPid.java | 76 b/test/jdk/jfr/jvm/TestUnloadEventClassCount.java | 111 + b/test/jdk/jfr/jvm/TestUnsupportedVM.java | 228 ++ b/test/jdk/jfr/security/JFRSecurityTestSuite.java | 442 ++++ b/test/jdk/jfr/startupargs/StartupHelper.java | 106 + b/test/jdk/jfr/startupargs/TestBadOptionValues.java | 151 + b/test/jdk/jfr/startupargs/TestDumpOnExit.java | 114 + b/test/jdk/jfr/startupargs/TestMemoryOptions.java | 656 +++++++ b/test/jdk/jfr/startupargs/TestMultipleStartupRecordings.java | 109 + b/test/jdk/jfr/startupargs/TestOldObjectQueueSize.java | 87 b/test/jdk/jfr/startupargs/TestRepositoryPath.java | 53 b/test/jdk/jfr/startupargs/TestRepositoryPathLong.java | 56 b/test/jdk/jfr/startupargs/TestRetransform.java | 74 b/test/jdk/jfr/startupargs/TestRetransformUsingLog.java | 114 + b/test/jdk/jfr/startupargs/TestStartDelay.java | 57 b/test/jdk/jfr/startupargs/TestStartDelayRunning.java | 55 b/test/jdk/jfr/startupargs/TestStartDuration.java | 111 + b/test/jdk/jfr/startupargs/TestStartMaxAgeSize.java | 54 b/test/jdk/jfr/startupargs/TestStartName.java | 72 b/test/jdk/jfr/startupargs/TestStartNoSettings.java | 68 b/test/jdk/jfr/startupargs/TestStartRecording.java | 55 b/test/jdk/jfr/tool/ExecuteHelper.java | 136 + b/test/jdk/jfr/tool/TestAssemble.java | 144 + b/test/jdk/jfr/tool/TestDisassemble.java | 124 + b/test/jdk/jfr/tool/TestHelp.java | 55 b/test/jdk/jfr/tool/TestMetadata.java | 62 b/test/jdk/jfr/tool/TestPrint.java | 60 b/test/jdk/jfr/tool/TestPrintDefault.java | 52 b/test/jdk/jfr/tool/TestPrintJSON.java | 162 + b/test/jdk/jfr/tool/TestPrintXML.java | 259 ++ b/test/jdk/jfr/tool/TestSummary.java | 61 b/test/jdk/jfr/tool/jfr.xsd | 81 b/test/lib/ClassFileInstaller.java | 257 ++ b/test/lib/RedefineClassHelper.java | 79 b/test/lib/jdk/test/lib/Asserts.java | 620 ++++++ b/test/lib/jdk/test/lib/BuildHelper.java | 106 + b/test/lib/jdk/test/lib/ByteCodeLoader.java | 90 b/test/lib/jdk/test/lib/Convert.java | 85 b/test/lib/jdk/test/lib/FileInstaller.java | 106 + b/test/lib/jdk/test/lib/InfiniteLoop.java | 66 b/test/lib/jdk/test/lib/JDKToolFinder.java | 106 + b/test/lib/jdk/test/lib/JDKToolLauncher.java | 132 + b/test/lib/jdk/test/lib/LockFreeLogger.java | 84 b/test/lib/jdk/test/lib/NetworkConfiguration.java | 272 ++ b/test/lib/jdk/test/lib/Platform.java | 363 +++ b/test/lib/jdk/test/lib/RandomFactory.java | 103 + b/test/lib/jdk/test/lib/SecurityTools.java | 131 + b/test/lib/jdk/test/lib/TimeLimitedRunner.java | 86 b/test/lib/jdk/test/lib/Utils.java | 811 ++++++++ b/test/lib/jdk/test/lib/apps/LingeredApp.java | 511 +++++ b/test/lib/jdk/test/lib/apps/LingeredAppWithDeadlock.java | 81 b/test/lib/jdk/test/lib/artifacts/Artifact.java | 39 b/test/lib/jdk/test/lib/artifacts/ArtifactContainer.java | 33 b/test/lib/jdk/test/lib/artifacts/ArtifactManager.java | 31 b/test/lib/jdk/test/lib/artifacts/ArtifactResolver.java | 69 b/test/lib/jdk/test/lib/artifacts/ArtifactResolverException.java | 15 b/test/lib/jdk/test/lib/artifacts/DefaultArtifactManager.java | 46 b/test/lib/jdk/test/lib/artifacts/JibArtifactManager.java | 93 + b/test/lib/jdk/test/lib/cds/CDSOptions.java | 71 b/test/lib/jdk/test/lib/cds/CDSTestUtils.java | 585 ++++++ b/test/lib/jdk/test/lib/classloader/ClassLoadUtils.java | 149 + b/test/lib/jdk/test/lib/classloader/FilterClassLoader.java | 50 b/test/lib/jdk/test/lib/classloader/GeneratingClassLoader.java | 198 ++ b/test/lib/jdk/test/lib/classloader/ParentLastURLClassLoader.java | 51 b/test/lib/jdk/test/lib/cli/CPUSpecificCommandLineOptionTest.java | 65 b/test/lib/jdk/test/lib/cli/CommandLineOptionTest.java | 545 +++++ b/test/lib/jdk/test/lib/cli/predicate/AndPredicate.java | 49 b/test/lib/jdk/test/lib/cli/predicate/CPUSpecificPredicate.java | 71 b/test/lib/jdk/test/lib/cli/predicate/NotPredicate.java | 39 b/test/lib/jdk/test/lib/cli/predicate/OrPredicate.java | 41 b/test/lib/jdk/test/lib/compiler/CompilerUtils.java | 124 + b/test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java | 200 ++ b/test/lib/jdk/test/lib/compiler/ModuleInfoMaker.java | 129 + b/test/lib/jdk/test/lib/containers/cgroup/CPUSetsReader.java | 155 + b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java | 597 ++++++ b/test/lib/jdk/test/lib/containers/docker/Common.java | 89 b/test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java | 77 b/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java | 285 +++ b/test/lib/jdk/test/lib/dcmd/CommandExecutor.java | 75 b/test/lib/jdk/test/lib/dcmd/CommandExecutorException.java | 36 b/test/lib/jdk/test/lib/dcmd/FileJcmdExecutor.java | 81 b/test/lib/jdk/test/lib/dcmd/JMXExecutor.java | 187 ++ b/test/lib/jdk/test/lib/dcmd/JcmdExecutor.java | 58 b/test/lib/jdk/test/lib/dcmd/MainClassJcmdExecutor.java | 57 b/test/lib/jdk/test/lib/dcmd/PidJcmdExecutor.java | 63 b/test/lib/jdk/test/lib/hprof/HprofParser.java | 97 + b/test/lib/jdk/test/lib/hprof/README | 13 b/test/lib/jdk/test/lib/hprof/model/AbstractJavaHeapObjectVisitor.java | 60 b/test/lib/jdk/test/lib/hprof/model/ArrayTypeCodes.java | 50 b/test/lib/jdk/test/lib/hprof/model/HackJavaValue.java | 66 b/test/lib/jdk/test/lib/hprof/model/JavaBoolean.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaByte.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaChar.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaClass.java | 504 +++++ b/test/lib/jdk/test/lib/hprof/model/JavaDouble.java | 53 b/test/lib/jdk/test/lib/hprof/model/JavaField.java | 69 b/test/lib/jdk/test/lib/hprof/model/JavaFloat.java | 53 b/test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java | 207 ++ b/test/lib/jdk/test/lib/hprof/model/JavaHeapObjectVisitor.java | 55 b/test/lib/jdk/test/lib/hprof/model/JavaInt.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaLazyReadObject.java | 168 + b/test/lib/jdk/test/lib/hprof/model/JavaLong.java | 53 b/test/lib/jdk/test/lib/hprof/model/JavaObject.java | 333 +++ b/test/lib/jdk/test/lib/hprof/model/JavaObjectArray.java | 165 + b/test/lib/jdk/test/lib/hprof/model/JavaObjectRef.java | 98 + b/test/lib/jdk/test/lib/hprof/model/JavaShort.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaStatic.java | 79 b/test/lib/jdk/test/lib/hprof/model/JavaThing.java | 99 + b/test/lib/jdk/test/lib/hprof/model/JavaValue.java | 62 b/test/lib/jdk/test/lib/hprof/model/JavaValueArray.java | 354 +++ b/test/lib/jdk/test/lib/hprof/model/ReachableExcludes.java | 50 b/test/lib/jdk/test/lib/hprof/model/ReachableExcludesImpl.java | 103 + b/test/lib/jdk/test/lib/hprof/model/ReachableObjects.java | 148 + b/test/lib/jdk/test/lib/hprof/model/ReferenceChain.java | 69 b/test/lib/jdk/test/lib/hprof/model/Root.java | 174 + b/test/lib/jdk/test/lib/hprof/model/Snapshot.java | 635 ++++++ b/test/lib/jdk/test/lib/hprof/model/StackFrame.java | 101 + b/test/lib/jdk/test/lib/hprof/model/StackTrace.java | 77 b/test/lib/jdk/test/lib/hprof/parser/FileReadBuffer.java | 94 + b/test/lib/jdk/test/lib/hprof/parser/HprofReader.java | 926 ++++++++++ b/test/lib/jdk/test/lib/hprof/parser/MappedReadBuffer.java | 136 + b/test/lib/jdk/test/lib/hprof/parser/PositionDataInputStream.java | 64 b/test/lib/jdk/test/lib/hprof/parser/PositionInputStream.java | 84 b/test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java | 48 b/test/lib/jdk/test/lib/hprof/parser/Reader.java | 135 + b/test/lib/jdk/test/lib/hprof/util/ArraySorter.java | 147 + b/test/lib/jdk/test/lib/hprof/util/Comparer.java | 49 b/test/lib/jdk/test/lib/hprof/util/CompositeEnumeration.java | 63 b/test/lib/jdk/test/lib/hprof/util/Misc.java | 112 + b/test/lib/jdk/test/lib/hprof/util/VectorSorter.java | 148 + b/test/lib/jdk/test/lib/jfr/AppExecutorHelper.java | 80 b/test/lib/jdk/test/lib/jfr/CommonHelper.java | 117 + b/test/lib/jdk/test/lib/jfr/EventField.java | 149 + b/test/lib/jdk/test/lib/jfr/EventNames.java | 183 + b/test/lib/jdk/test/lib/jfr/EventTypePrototype.java | 80 b/test/lib/jdk/test/lib/jfr/EventVerifier.java | 53 b/test/lib/jdk/test/lib/jfr/Events.java | 390 ++++ b/test/lib/jdk/test/lib/jfr/FileHelper.java | 124 + b/test/lib/jdk/test/lib/jfr/GCHelper.java | 468 +++++ b/test/lib/jdk/test/lib/jfr/RecurseThread.java | 93 + b/test/lib/jdk/test/lib/jfr/SimpleEvent.java | 32 b/test/lib/jdk/test/lib/jfr/SimpleEventHelper.java | 107 + b/test/lib/jdk/test/lib/jfr/SimpleSetting.java | 47 b/test/lib/jdk/test/lib/jfr/Stressor.java | 49 b/test/lib/jdk/test/lib/jfr/TestClassLoader.java | 78 b/test/lib/jdk/test/lib/jfr/VoidFunction.java | 31 b/test/lib/jdk/test/lib/management/DynamicVMOption.java | 166 + b/test/lib/jdk/test/lib/management/InputArguments.java | 41 b/test/lib/jdk/test/lib/management/ThreadMXBeanTool.java | 71 b/test/lib/jdk/test/lib/process/ExitCode.java | 40 b/test/lib/jdk/test/lib/process/OutputAnalyzer.java | 557 ++++++ b/test/lib/jdk/test/lib/process/OutputBuffer.java | 59 b/test/lib/jdk/test/lib/process/ProcessTools.java | 596 ++++++ b/test/lib/jdk/test/lib/process/StreamPumper.java | 197 ++ b/test/lib/jdk/test/lib/thread/TestThread.java | 204 ++ b/test/lib/jdk/test/lib/thread/XRun.java | 56 b/test/lib/jdk/test/lib/util/FileUtils.java | 276 ++ b/test/lib/jdk/test/lib/util/JarUtils.java | 175 + b/test/lib/jdk/test/lib/util/Pair.java | 68 b/test/lib/jdk/test/lib/util/SerializationUtils.java | 56 b/test/lib/jdk/test/lib/util/Triple.java | 90 b/test/lib/sun/hotspot/WhiteBox.java | 450 ++++ b/test/lib/sun/hotspot/code/BlobType.java | 69 b/test/lib/sun/hotspot/code/CodeBlob.java | 74 b/test/lib/sun/hotspot/code/Compiler.java | 136 + b/test/lib/sun/hotspot/code/NMethod.java | 58 b/test/lib/sun/hotspot/cpuinfo/CPUInfo.java | 96 + b/test/lib/sun/hotspot/gc/GC.java | 72 b/test/lib/sun/hotspot/parser/DiagnosticCommand.java | 77 b/test/lib/testlibrary/ExtendedRobot.java | 45 b/test/lib/testlibrary/jdk/testlibrary/thread/TestThread.java | 204 ++ b/test/lib/testlibrary/jdk/testlibrary/thread/XRun.java | 56 b/test/sun/java2d/marlin/CrashNaNTest.java | 143 + b/test/sun/java2d/marlin/TextClipErrorTest.java | 22 b/test/sun/security/ec/SignedObjectChain.java | 3 b/test/sun/security/mscapi/SignedObjectChain.java | 3 b/test/sun/security/ssl/rsa/SignedObjectChain.java | 1 b/test/sun/security/x509/X509CertImpl/CertificateValidation.java | 60 b/test/tools/launcher/VersionCheck.java | 1 904 files changed, 102413 insertions(+), 927 deletions(-) diffstat for hotspot a/make/aix/makefiles/trace.make | 120 a/make/bsd/makefiles/trace.make | 121 a/make/linux/makefiles/trace.make | 120 a/make/solaris/makefiles/trace.make | 120 a/make/windows/makefiles/trace.make | 120 a/src/share/vm/runtime/vmStructs_trace.hpp | 35 a/src/share/vm/trace/noTraceBackend.hpp | 44 a/src/share/vm/trace/trace.dtd | 86 a/src/share/vm/trace/trace.xml | 443 -- a/src/share/vm/trace/traceBackend.hpp | 62 a/src/share/vm/trace/traceDataTypes.hpp | 69 a/src/share/vm/trace/traceEvent.hpp | 157 - a/src/share/vm/trace/traceEventClasses.xsl | 251 - a/src/share/vm/trace/traceEventIds.xsl | 72 a/src/share/vm/trace/traceMacros.hpp | 44 a/src/share/vm/trace/traceStream.hpp | 114 a/src/share/vm/trace/traceTime.hpp | 32 a/src/share/vm/trace/traceTypes.xsl | 73 a/src/share/vm/trace/tracetypes.xml | 376 -- a/src/share/vm/trace/tracing.hpp | 31 a/src/share/vm/trace/xinclude.mod | 37 a/src/share/vm/trace/xsl_util.xsl | 78 a/src/share/vm/utilities/ticks.inline.hpp | 97 b/.hgtags | 3 b/THIRD_PARTY_README | 30 b/agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java | 4 b/make/Makefile | 5 b/make/aix/makefiles/buildtree.make | 23 b/make/aix/makefiles/jfr.make | 92 b/make/aix/makefiles/mapfile-vers-debug | 1 b/make/aix/makefiles/mapfile-vers-product | 1 b/make/aix/makefiles/rules.make | 4 b/make/aix/makefiles/top.make | 10 b/make/aix/makefiles/vm.make | 18 b/make/bsd/makefiles/buildtree.make | 19 b/make/bsd/makefiles/jfr.make | 92 b/make/bsd/makefiles/mapfile-vers-debug | 1 b/make/bsd/makefiles/mapfile-vers-product | 1 b/make/bsd/makefiles/rules.make | 4 b/make/bsd/makefiles/top.make | 8 b/make/bsd/makefiles/vm.make | 15 b/make/defs.make | 4 b/make/linux/makefiles/buildtree.make | 22 b/make/linux/makefiles/jfr.make | 92 b/make/linux/makefiles/mapfile-vers-debug | 1 b/make/linux/makefiles/mapfile-vers-product | 1 b/make/linux/makefiles/rules.make | 4 b/make/linux/makefiles/top.make | 8 b/make/linux/makefiles/vm.make | 15 b/make/solaris/makefiles/buildtree.make | 23 b/make/solaris/makefiles/jfr.make | 92 b/make/solaris/makefiles/mapfile-vers | 1 b/make/solaris/makefiles/rules.make | 4 b/make/solaris/makefiles/top.make | 8 b/make/solaris/makefiles/vm.make | 18 b/make/windows/build.make | 1 b/make/windows/create_obj_files.sh | 10 b/make/windows/makefiles/compile.make | 8 b/make/windows/makefiles/defs.make | 3 b/make/windows/makefiles/generated.make | 10 b/make/windows/makefiles/jfr.make | 81 b/make/windows/makefiles/rules.make | 4 b/make/windows/makefiles/vm.make | 85 b/make/windows/projectfiles/common/Makefile | 4 b/src/cpu/ppc/vm/frame_ppc.cpp | 134 b/src/cpu/ppc/vm/vm_version_ext_ppc.cpp | 87 b/src/cpu/ppc/vm/vm_version_ext_ppc.hpp | 62 b/src/cpu/sparc/vm/vm_version_ext_sparc.cpp | 195 + b/src/cpu/sparc/vm/vm_version_ext_sparc.hpp | 69 b/src/cpu/x86/vm/rdtsc_x86.cpp | 225 + b/src/cpu/x86/vm/rdtsc_x86.hpp | 50 b/src/cpu/x86/vm/vm_version_ext_x86.cpp | 966 ++++++ b/src/cpu/x86/vm/vm_version_ext_x86.hpp | 100 b/src/cpu/zero/vm/vm_version_ext_zero.cpp | 82 b/src/cpu/zero/vm/vm_version_ext_zero.hpp | 52 b/src/os/aix/vm/os_aix.cpp | 9 b/src/os/aix/vm/os_perf_aix.cpp | 1053 ++++++ b/src/os/bsd/vm/os_bsd.cpp | 51 b/src/os/bsd/vm/os_perf_bsd.cpp | 491 +++ b/src/os/bsd/vm/semaphore_bsd.cpp | 107 b/src/os/bsd/vm/semaphore_bsd.hpp | 63 b/src/os/linux/vm/os_linux.cpp | 39 b/src/os/linux/vm/os_perf_linux.cpp | 1148 +++++++ b/src/os/posix/vm/os_posix.cpp | 40 b/src/os/posix/vm/os_posix.hpp | 13 b/src/os/posix/vm/semaphore_posix.cpp | 98 b/src/os/posix/vm/semaphore_posix.hpp | 53 b/src/os/solaris/vm/os_perf_solaris.cpp | 851 +++++ b/src/os/solaris/vm/os_solaris.cpp | 46 b/src/os/windows/vm/iphlp_interface.cpp | 104 b/src/os/windows/vm/iphlp_interface.hpp | 51 b/src/os/windows/vm/os_perf_windows.cpp | 1456 +++++++++ b/src/os/windows/vm/os_windows.cpp | 100 b/src/os/windows/vm/os_windows.hpp | 14 b/src/os/windows/vm/pdh_interface.cpp | 165 + b/src/os/windows/vm/pdh_interface.hpp | 64 b/src/os/windows/vm/semaphore_windows.cpp | 60 b/src/os/windows/vm/semaphore_windows.hpp | 52 b/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp | 2 b/src/os_cpu/linux_ppc/vm/thread_linux_ppc.cpp | 57 b/src/os_cpu/linux_ppc/vm/thread_linux_ppc.hpp | 2 b/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp | 2 b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp | 4 b/src/os_cpu/linux_zero/vm/thread_linux_zero.hpp | 8 b/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp | 2 b/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp | 2 b/src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp | 4 b/src/share/vm/c1/c1_GraphBuilder.cpp | 44 b/src/share/vm/c1/c1_LIRGenerator.cpp | 57 b/src/share/vm/c1/c1_LIRGenerator.hpp | 5 b/src/share/vm/c1/c1_Runtime1.cpp | 5 b/src/share/vm/ci/ciEnv.cpp | 1 b/src/share/vm/ci/ciMethod.hpp | 11 b/src/share/vm/classfile/classFileParser.cpp | 40 b/src/share/vm/classfile/classFileParser.hpp | 8 b/src/share/vm/classfile/classFileStream.cpp | 32 b/src/share/vm/classfile/classFileStream.hpp | 20 b/src/share/vm/classfile/classLoader.cpp | 9 b/src/share/vm/classfile/classLoaderData.cpp | 53 b/src/share/vm/classfile/classLoaderData.hpp | 26 b/src/share/vm/classfile/javaClasses.cpp | 3 b/src/share/vm/classfile/systemDictionary.cpp | 108 b/src/share/vm/classfile/systemDictionary.hpp | 4 b/src/share/vm/classfile/vmSymbols.cpp | 2 b/src/share/vm/classfile/vmSymbols.hpp | 11 b/src/share/vm/code/codeBlob.cpp | 2 b/src/share/vm/code/codeBlob.hpp | 11 b/src/share/vm/code/codeCache.cpp | 10 b/src/share/vm/compiler/compileBroker.cpp | 34 b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp | 24 b/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp | 6 b/src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp | 8 b/src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp | 4 b/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp | 5 b/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp | 2 b/src/share/vm/gc_implementation/g1/g1HeapRegionEventSender.cpp | 49 b/src/share/vm/gc_implementation/g1/g1HeapRegionEventSender.hpp | 35 b/src/share/vm/gc_implementation/g1/g1HeapRegionTraceType.hpp | 56 b/src/share/vm/gc_implementation/g1/g1MMUTracker.cpp | 4 b/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp | 4 b/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp | 19 b/src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp | 4 b/src/share/vm/gc_implementation/g1/heapRegion.cpp | 36 b/src/share/vm/gc_implementation/g1/heapRegion.hpp | 14 b/src/share/vm/gc_implementation/g1/heapRegionSet.cpp | 2 b/src/share/vm/gc_implementation/g1/heapRegionTracer.cpp | 43 b/src/share/vm/gc_implementation/g1/heapRegionTracer.hpp | 40 b/src/share/vm/gc_implementation/g1/heapRegionType.cpp | 15 b/src/share/vm/gc_implementation/g1/heapRegionType.hpp | 2 b/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp | 2 b/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp | 4 b/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp | 4 b/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp | 4 b/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp | 39 b/src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp | 1 b/src/share/vm/gc_implementation/shared/ageTable.cpp | 6 b/src/share/vm/gc_implementation/shared/ageTable.hpp | 3 b/src/share/vm/gc_implementation/shared/ageTableTracer.cpp | 43 b/src/share/vm/gc_implementation/shared/ageTableTracer.hpp | 37 b/src/share/vm/gc_implementation/shared/gcConfiguration.cpp | 159 + b/src/share/vm/gc_implementation/shared/gcConfiguration.hpp | 80 b/src/share/vm/gc_implementation/shared/gcHeapSummary.hpp | 20 b/src/share/vm/gc_implementation/shared/gcTimer.cpp | 6 b/src/share/vm/gc_implementation/shared/gcTrace.cpp | 32 b/src/share/vm/gc_implementation/shared/gcTrace.hpp | 36 b/src/share/vm/gc_implementation/shared/gcTraceSend.cpp | 136 b/src/share/vm/gc_implementation/shared/gcTraceTime.cpp | 4 b/src/share/vm/gc_implementation/shared/objectCountEventSender.cpp | 59 b/src/share/vm/gc_implementation/shared/objectCountEventSender.hpp | 9 b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp | 4 b/src/share/vm/gc_interface/allocTracer.cpp | 19 b/src/share/vm/gc_interface/allocTracer.hpp | 4 b/src/share/vm/gc_interface/collectedHeap.cpp | 2 b/src/share/vm/gc_interface/collectedHeap.inline.hpp | 2 b/src/share/vm/jfr/GenerateJfrFiles.java | 756 ++++ b/src/share/vm/jfr/dcmd/jfrDcmds.cpp | 675 ++++ b/src/share/vm/jfr/dcmd/jfrDcmds.hpp | 194 + b/src/share/vm/jfr/instrumentation/jfrEventClassTransformer.cpp | 1551 ++++++++++ b/src/share/vm/jfr/instrumentation/jfrEventClassTransformer.hpp | 45 b/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp | 278 + b/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.hpp | 41 b/src/share/vm/jfr/jfr.cpp | 106 b/src/share/vm/jfr/jfr.hpp | 60 b/src/share/vm/jfr/jfrEvents.hpp | 35 b/src/share/vm/jfr/jni/jfrGetAllEventClasses.cpp | 190 + b/src/share/vm/jfr/jni/jfrGetAllEventClasses.hpp | 41 b/src/share/vm/jfr/jni/jfrJavaCall.cpp | 380 ++ b/src/share/vm/jfr/jni/jfrJavaCall.hpp | 134 b/src/share/vm/jfr/jni/jfrJavaSupport.cpp | 583 +++ b/src/share/vm/jfr/jni/jfrJavaSupport.hpp | 111 b/src/share/vm/jfr/jni/jfrJniMethod.cpp | 312 ++ b/src/share/vm/jfr/jni/jfrJniMethod.hpp | 139 b/src/share/vm/jfr/jni/jfrJniMethodRegistration.cpp | 95 b/src/share/vm/jfr/jni/jfrJniMethodRegistration.hpp | 39 b/src/share/vm/jfr/jni/jfrUpcalls.cpp | 190 + b/src/share/vm/jfr/jni/jfrUpcalls.hpp | 60 b/src/share/vm/jfr/leakprofiler/chains/bfsClosure.cpp | 234 + b/src/share/vm/jfr/leakprofiler/chains/bfsClosure.hpp | 73 b/src/share/vm/jfr/leakprofiler/chains/bitset.cpp | 58 b/src/share/vm/jfr/leakprofiler/chains/bitset.hpp | 79 b/src/share/vm/jfr/leakprofiler/chains/dfsClosure.cpp | 183 + b/src/share/vm/jfr/leakprofiler/chains/dfsClosure.hpp | 65 b/src/share/vm/jfr/leakprofiler/chains/edge.cpp | 65 b/src/share/vm/jfr/leakprofiler/chains/edge.hpp | 59 b/src/share/vm/jfr/leakprofiler/chains/edgeQueue.cpp | 100 b/src/share/vm/jfr/leakprofiler/chains/edgeQueue.hpp | 60 b/src/share/vm/jfr/leakprofiler/chains/edgeStore.cpp | 319 ++ b/src/share/vm/jfr/leakprofiler/chains/edgeStore.hpp | 107 b/src/share/vm/jfr/leakprofiler/chains/edgeUtils.cpp | 151 b/src/share/vm/jfr/leakprofiler/chains/edgeUtils.hpp | 51 b/src/share/vm/jfr/leakprofiler/chains/objectSampleMarker.hpp | 81 b/src/share/vm/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp | 131 b/src/share/vm/jfr/leakprofiler/chains/pathToGcRootsOperation.hpp | 46 b/src/share/vm/jfr/leakprofiler/chains/rootSetClosure.cpp | 95 b/src/share/vm/jfr/leakprofiler/chains/rootSetClosure.hpp | 42 b/src/share/vm/jfr/leakprofiler/checkpoint/eventEmitter.cpp | 147 b/src/share/vm/jfr/leakprofiler/checkpoint/eventEmitter.hpp | 58 b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp | 293 + b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp | 52 b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp | 216 + b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleDescription.hpp | 74 b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp | 602 +++ b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleWriter.hpp | 46 b/src/share/vm/jfr/leakprofiler/checkpoint/rootResolver.cpp | 436 ++ b/src/share/vm/jfr/leakprofiler/checkpoint/rootResolver.hpp | 52 b/src/share/vm/jfr/leakprofiler/leakProfiler.cpp | 110 b/src/share/vm/jfr/leakprofiler/leakProfiler.hpp | 46 b/src/share/vm/jfr/leakprofiler/sampling/objectSample.hpp | 249 + b/src/share/vm/jfr/leakprofiler/sampling/objectSampler.cpp | 285 + b/src/share/vm/jfr/leakprofiler/sampling/objectSampler.hpp | 97 b/src/share/vm/jfr/leakprofiler/sampling/sampleList.cpp | 146 b/src/share/vm/jfr/leakprofiler/sampling/sampleList.hpp | 64 b/src/share/vm/jfr/leakprofiler/sampling/samplePriorityQueue.cpp | 150 b/src/share/vm/jfr/leakprofiler/sampling/samplePriorityQueue.hpp | 58 b/src/share/vm/jfr/leakprofiler/startOperation.hpp | 42 b/src/share/vm/jfr/leakprofiler/stopOperation.hpp | 39 b/src/share/vm/jfr/leakprofiler/utilities/granularTimer.cpp | 75 b/src/share/vm/jfr/leakprofiler/utilities/granularTimer.hpp | 46 b/src/share/vm/jfr/leakprofiler/utilities/rootType.hpp | 109 b/src/share/vm/jfr/leakprofiler/utilities/saveRestore.cpp | 111 b/src/share/vm/jfr/leakprofiler/utilities/saveRestore.hpp | 128 b/src/share/vm/jfr/leakprofiler/utilities/unifiedOop.hpp | 55 b/src/share/vm/jfr/leakprofiler/utilities/vmOperation.hpp | 41 b/src/share/vm/jfr/metadata/jfrSerializer.hpp | 100 b/src/share/vm/jfr/metadata/metadata.xml | 1143 +++++++ b/src/share/vm/jfr/metadata/metadata.xsd | 122 b/src/share/vm/jfr/periodic/jfrNetworkUtilization.cpp | 190 + b/src/share/vm/jfr/periodic/jfrNetworkUtilization.hpp | 38 b/src/share/vm/jfr/periodic/jfrOSInterface.cpp | 254 + b/src/share/vm/jfr/periodic/jfrOSInterface.hpp | 61 b/src/share/vm/jfr/periodic/jfrPeriodic.cpp | 560 +++ b/src/share/vm/jfr/periodic/jfrThreadCPULoadEvent.cpp | 147 b/src/share/vm/jfr/periodic/jfrThreadCPULoadEvent.hpp | 45 b/src/share/vm/jfr/periodic/jfrThreadDumpEvent.cpp | 63 b/src/share/vm/jfr/periodic/jfrThreadDumpEvent.hpp | 39 b/src/share/vm/jfr/periodic/sampling/jfrCallTrace.cpp | 117 b/src/share/vm/jfr/periodic/sampling/jfrCallTrace.hpp | 45 b/src/share/vm/jfr/periodic/sampling/jfrThreadSampler.cpp | 674 ++++ b/src/share/vm/jfr/periodic/sampling/jfrThreadSampler.hpp | 56 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp | 93 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp | 59 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointManager.cpp | 379 ++ b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointManager.hpp | 108 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp | 185 + b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp | 88 b/src/share/vm/jfr/recorder/checkpoint/jfrMetadataEvent.cpp | 89 b/src/share/vm/jfr/recorder/checkpoint/jfrMetadataEvent.hpp | 46 b/src/share/vm/jfr/recorder/checkpoint/types/jfrThreadGroup.cpp | 413 ++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrThreadGroup.hpp | 65 b/src/share/vm/jfr/recorder/checkpoint/types/jfrThreadState.cpp | 82 b/src/share/vm/jfr/recorder/checkpoint/types/jfrThreadState.hpp | 37 b/src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp | 351 ++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrType.hpp | 138 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp | 249 + b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.hpp | 44 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.cpp | 901 +++++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.hpp | 68 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp | 271 + b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp | 381 ++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp | 108 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp | 215 + b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp | 124 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp | 148 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp | 108 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp | 39 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.hpp | 103 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp | 187 + b/src/share/vm/jfr/recorder/jfrEventSetting.cpp | 63 b/src/share/vm/jfr/recorder/jfrEventSetting.hpp | 52 b/src/share/vm/jfr/recorder/jfrEventSetting.inline.hpp | 51 b/src/share/vm/jfr/recorder/jfrRecorder.cpp | 405 ++ b/src/share/vm/jfr/recorder/jfrRecorder.hpp | 73 b/src/share/vm/jfr/recorder/repository/jfrChunkRotation.cpp | 81 b/src/share/vm/jfr/recorder/repository/jfrChunkRotation.hpp | 44 b/src/share/vm/jfr/recorder/repository/jfrChunkState.cpp | 119 b/src/share/vm/jfr/recorder/repository/jfrChunkState.hpp | 60 b/src/share/vm/jfr/recorder/repository/jfrChunkWriter.cpp | 123 b/src/share/vm/jfr/recorder/repository/jfrChunkWriter.hpp | 57 b/src/share/vm/jfr/recorder/repository/jfrEmergencyDump.cpp | 164 + b/src/share/vm/jfr/recorder/repository/jfrEmergencyDump.hpp | 40 b/src/share/vm/jfr/recorder/repository/jfrRepository.cpp | 473 +++ b/src/share/vm/jfr/recorder/repository/jfrRepository.hpp | 73 b/src/share/vm/jfr/recorder/service/jfrEvent.cpp | 63 b/src/share/vm/jfr/recorder/service/jfrEvent.hpp | 214 + b/src/share/vm/jfr/recorder/service/jfrMemorySizer.cpp | 433 ++ b/src/share/vm/jfr/recorder/service/jfrMemorySizer.hpp | 56 b/src/share/vm/jfr/recorder/service/jfrOptionSet.cpp | 729 ++++ b/src/share/vm/jfr/recorder/service/jfrOptionSet.hpp | 87 b/src/share/vm/jfr/recorder/service/jfrPostBox.cpp | 173 + b/src/share/vm/jfr/recorder/service/jfrPostBox.hpp | 97 b/src/share/vm/jfr/recorder/service/jfrRecorderService.cpp | 551 +++ b/src/share/vm/jfr/recorder/service/jfrRecorderService.hpp | 77 b/src/share/vm/jfr/recorder/service/jfrRecorderThread.cpp | 117 b/src/share/vm/jfr/recorder/service/jfrRecorderThread.hpp | 45 b/src/share/vm/jfr/recorder/service/jfrRecorderThreadLoop.cpp | 94 b/src/share/vm/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp | 445 ++ b/src/share/vm/jfr/recorder/stacktrace/jfrStackTraceRepository.hpp | 157 + b/src/share/vm/jfr/recorder/storage/jfrBuffer.cpp | 249 + b/src/share/vm/jfr/recorder/storage/jfrBuffer.hpp | 187 + b/src/share/vm/jfr/recorder/storage/jfrMemorySpace.hpp | 168 + b/src/share/vm/jfr/recorder/storage/jfrMemorySpace.inline.hpp | 385 ++ b/src/share/vm/jfr/recorder/storage/jfrMemorySpaceRetrieval.hpp | 113 b/src/share/vm/jfr/recorder/storage/jfrStorage.cpp | 761 ++++ b/src/share/vm/jfr/recorder/storage/jfrStorage.hpp | 98 b/src/share/vm/jfr/recorder/storage/jfrStorageControl.cpp | 141 b/src/share/vm/jfr/recorder/storage/jfrStorageControl.hpp | 68 b/src/share/vm/jfr/recorder/storage/jfrStorageUtils.hpp | 124 b/src/share/vm/jfr/recorder/storage/jfrStorageUtils.inline.hpp | 98 b/src/share/vm/jfr/recorder/storage/jfrVirtualMemory.cpp | 534 +++ b/src/share/vm/jfr/recorder/storage/jfrVirtualMemory.hpp | 66 b/src/share/vm/jfr/recorder/stringpool/jfrStringPool.cpp | 245 + b/src/share/vm/jfr/recorder/stringpool/jfrStringPool.hpp | 83 b/src/share/vm/jfr/recorder/stringpool/jfrStringPoolBuffer.cpp | 67 b/src/share/vm/jfr/recorder/stringpool/jfrStringPoolBuffer.hpp | 46 b/src/share/vm/jfr/recorder/stringpool/jfrStringPoolWriter.cpp | 50 b/src/share/vm/jfr/recorder/stringpool/jfrStringPoolWriter.hpp | 58 b/src/share/vm/jfr/support/jfrAllocationTracer.cpp | 43 b/src/share/vm/jfr/support/jfrAllocationTracer.hpp | 40 b/src/share/vm/jfr/support/jfrEventClass.cpp | 87 b/src/share/vm/jfr/support/jfrEventClass.hpp | 64 b/src/share/vm/jfr/support/jfrFlush.cpp | 84 b/src/share/vm/jfr/support/jfrFlush.hpp | 79 b/src/share/vm/jfr/support/jfrIntrinsics.hpp | 56 b/src/share/vm/jfr/support/jfrKlassExtension.hpp | 42 b/src/share/vm/jfr/support/jfrStackTraceMark.cpp | 82 b/src/share/vm/jfr/support/jfrStackTraceMark.hpp | 47 b/src/share/vm/jfr/support/jfrThreadExtension.hpp | 56 b/src/share/vm/jfr/support/jfrThreadId.hpp | 41 b/src/share/vm/jfr/support/jfrThreadLocal.cpp | 167 + b/src/share/vm/jfr/support/jfrThreadLocal.hpp | 222 + b/src/share/vm/jfr/support/jfrTraceIdExtension.hpp | 81 b/src/share/vm/jfr/utilities/jfrAllocation.cpp | 146 b/src/share/vm/jfr/utilities/jfrAllocation.hpp | 74 b/src/share/vm/jfr/utilities/jfrBigEndian.hpp | 150 b/src/share/vm/jfr/utilities/jfrDoublyLinkedList.hpp | 218 + b/src/share/vm/jfr/utilities/jfrHashtable.hpp | 283 + b/src/share/vm/jfr/utilities/jfrIterator.hpp | 107 b/src/share/vm/jfr/utilities/jfrJavaLog.cpp | 141 b/src/share/vm/jfr/utilities/jfrJavaLog.hpp | 48 b/src/share/vm/jfr/utilities/jfrRefCountPointer.hpp | 154 b/src/share/vm/jfr/utilities/jfrResourceManager.hpp | 60 b/src/share/vm/jfr/utilities/jfrSpinlockHelper.hpp | 50 b/src/share/vm/jfr/utilities/jfrTime.cpp | 71 b/src/share/vm/jfr/utilities/jfrTime.hpp | 44 b/src/share/vm/jfr/utilities/jfrTimeConverter.cpp | 89 b/src/share/vm/jfr/utilities/jfrTimeConverter.hpp | 53 b/src/share/vm/jfr/utilities/jfrTryLock.hpp | 74 b/src/share/vm/jfr/utilities/jfrTypes.hpp | 44 b/src/share/vm/jfr/writers/jfrBigEndianWriter.hpp | 42 b/src/share/vm/jfr/writers/jfrEncoders.hpp | 312 ++ b/src/share/vm/jfr/writers/jfrEncoding.hpp | 117 b/src/share/vm/jfr/writers/jfrEventWriterHost.hpp | 51 b/src/share/vm/jfr/writers/jfrEventWriterHost.inline.hpp | 97 b/src/share/vm/jfr/writers/jfrJavaEventWriter.cpp | 249 + b/src/share/vm/jfr/writers/jfrJavaEventWriter.hpp | 51 b/src/share/vm/jfr/writers/jfrMemoryWriterHost.hpp | 72 b/src/share/vm/jfr/writers/jfrMemoryWriterHost.inline.hpp | 99 b/src/share/vm/jfr/writers/jfrNativeEventWriter.hpp | 38 b/src/share/vm/jfr/writers/jfrPosition.hpp | 57 b/src/share/vm/jfr/writers/jfrPosition.inline.hpp | 102 b/src/share/vm/jfr/writers/jfrStorageAdapter.hpp | 243 + b/src/share/vm/jfr/writers/jfrStorageHost.hpp | 59 b/src/share/vm/jfr/writers/jfrStorageHost.inline.hpp | 138 b/src/share/vm/jfr/writers/jfrStreamWriterHost.hpp | 60 b/src/share/vm/jfr/writers/jfrStreamWriterHost.inline.hpp | 139 b/src/share/vm/jfr/writers/jfrWriterHost.hpp | 100 b/src/share/vm/jfr/writers/jfrWriterHost.inline.hpp | 360 ++ b/src/share/vm/memory/defNewGeneration.cpp | 6 b/src/share/vm/memory/defNewGeneration.hpp | 2 b/src/share/vm/memory/genCollectedHeap.cpp | 4 b/src/share/vm/memory/metaspace.cpp | 2 b/src/share/vm/memory/metaspaceTracer.cpp | 7 b/src/share/vm/memory/referenceProcessor.cpp | 4 b/src/share/vm/oops/arrayKlass.cpp | 1 b/src/share/vm/oops/instanceKlass.cpp | 12 b/src/share/vm/oops/instanceKlass.hpp | 6 b/src/share/vm/oops/klass.cpp | 8 b/src/share/vm/oops/klass.hpp | 8 b/src/share/vm/oops/klassVtable.cpp | 27 b/src/share/vm/oops/method.hpp | 8 b/src/share/vm/opto/bytecodeInfo.cpp | 31 b/src/share/vm/opto/compile.cpp | 9 b/src/share/vm/opto/compile.hpp | 6 b/src/share/vm/opto/library_call.cpp | 92 b/src/share/vm/opto/parse.hpp | 2 b/src/share/vm/opto/superword.hpp | 51 b/src/share/vm/prims/jni.cpp | 23 b/src/share/vm/prims/jvm.cpp | 24 b/src/share/vm/prims/jvm.h | 3 b/src/share/vm/prims/methodHandles.cpp | 2 b/src/share/vm/prims/nativeLookup.cpp | 6 b/src/share/vm/prims/unsafe.cpp | 27 b/src/share/vm/prims/whitebox.cpp | 149 b/src/share/vm/prims/whitebox.hpp | 4 b/src/share/vm/runtime/arguments.cpp | 21 b/src/share/vm/runtime/biasedLocking.cpp | 68 b/src/share/vm/runtime/frame.cpp | 13 b/src/share/vm/runtime/frame.hpp | 2 b/src/share/vm/runtime/globals.cpp | 30 b/src/share/vm/runtime/globals.hpp | 60 b/src/share/vm/runtime/globals_extension.hpp | 1 b/src/share/vm/runtime/handles.cpp | 3 b/src/share/vm/runtime/java.cpp | 12 b/src/share/vm/runtime/mutex.cpp | 8 b/src/share/vm/runtime/mutexLocker.cpp | 12 b/src/share/vm/runtime/mutexLocker.hpp | 7 b/src/share/vm/runtime/objectMonitor.cpp | 50 b/src/share/vm/runtime/objectMonitor.hpp | 7 b/src/share/vm/runtime/os.cpp | 19 b/src/share/vm/runtime/os.hpp | 11 b/src/share/vm/runtime/os_perf.hpp | 292 + b/src/share/vm/runtime/safepoint.cpp | 209 + b/src/share/vm/runtime/safepoint.hpp | 1 b/src/share/vm/runtime/semaphore.hpp | 63 b/src/share/vm/runtime/semaphore.inline.hpp | 41 b/src/share/vm/runtime/sweeper.cpp | 32 b/src/share/vm/runtime/synchronizer.cpp | 18 b/src/share/vm/runtime/thread.cpp | 61 b/src/share/vm/runtime/thread.hpp | 29 b/src/share/vm/runtime/vmStructs.cpp | 33 b/src/share/vm/runtime/vmThread.cpp | 35 b/src/share/vm/runtime/vmThread.hpp | 3 b/src/share/vm/runtime/vm_operations.cpp | 1 b/src/share/vm/runtime/vm_operations.hpp | 1 b/src/share/vm/runtime/vm_version.hpp | 9 b/src/share/vm/services/diagnosticArgument.cpp | 2 b/src/share/vm/services/memTracker.hpp | 2 b/src/share/vm/utilities/align.hpp | 152 b/src/share/vm/utilities/bitMap.inline.hpp | 2 b/src/share/vm/utilities/globalDefinitions.hpp | 8 b/src/share/vm/utilities/globalDefinitions_gcc.hpp | 11 b/src/share/vm/utilities/globalDefinitions_sparcWorks.hpp | 4 b/src/share/vm/utilities/globalDefinitions_visCPP.hpp | 12 b/src/share/vm/utilities/globalDefinitions_xlc.hpp | 2 b/src/share/vm/utilities/growableArray.hpp | 42 b/src/share/vm/utilities/macros.hpp | 14 b/src/share/vm/utilities/ostream.cpp | 65 b/src/share/vm/utilities/ostream.hpp | 4 b/src/share/vm/utilities/ticks.cpp | 122 b/src/share/vm/utilities/ticks.hpp | 308 + b/src/share/vm/utilities/vmError.cpp | 12 b/test/runtime/EnableTracing/TestEnableTracing.java | 11 b/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java | 11 463 files changed, 46861 insertions(+), 3661 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue May 5 08:20:19 2020 From: shade at redhat.com (shade at redhat.com) Date: Tue, 05 May 2020 08:20:19 +0000 Subject: hg: shenandoah/jdk11: Added tag shenandoah-jdk-11.0.8+1 for changeset b593a8dba16b Message-ID: <202005050820.0458KKwQ005459@aojmv0008.oracle.com> Changeset: 45b1d6f5b404 Author: shade Date: 2020-05-04 12:39 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/45b1d6f5b404 Added tag shenandoah-jdk-11.0.8+1 for changeset b593a8dba16b ! .hgtags From rkennke at redhat.com Tue May 5 09:16:17 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 May 2020 11:16:17 +0200 Subject: RFR (S) 8244326: Shenandoah: global statistics should not accept bogus samples In-Reply-To: <207f5d8e-56a4-9de3-16cc-752f7c16d44e@redhat.com> References: <207f5d8e-56a4-9de3-16cc-752f7c16d44e@redhat.com> Message-ID: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8244326 > > Fix: > https://cr.openjdk.java.net/~shade/8244326/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing the logs Why not declare uninitialized a const field? Thanks, Roman From shade at redhat.com Tue May 5 09:19:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 May 2020 11:19:41 +0200 Subject: RFR (S) 8244326: Shenandoah: global statistics should not accept bogus samples In-Reply-To: References: <207f5d8e-56a4-9de3-16cc-752f7c16d44e@redhat.com> Message-ID: On 5/5/20 11:16 AM, Roman Kennke wrote: > Why not declare uninitialized a const field? Wanted to maintain the symmetry against ShenandoahWorkerData::uninitialized(), which is WorkerDataArray::uninitialized() in disguise: template <> size_t WorkerDataArray::uninitialized() { return (size_t)-1; } template <> double WorkerDataArray::uninitialized() { return -1.0; } -- Thanks, -Aleksey From shade at redhat.com Tue May 5 09:38:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 May 2020 11:38:06 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b01 Upstream Sync In-Reply-To: References: Message-ID: <70151c3f-4a75-71e3-8274-d02afa47788e@redhat.com> On 5/5/20 7:39 AM, Andrew John Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b01/corba/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jaxws/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jdk/merge.changeset Huge JFR merge, looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/hotspot/merge.changeset Huge JFR merge. Not sure about this change: diff --git a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp --- a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp @@ -33,7 +33,7 @@ #include "runtime/thread.inline.hpp" #include "runtime/timer.hpp" #include "utilities/ostream.hpp" -#include "utilities/ticks.inline.hpp" +#include "utilities/ticks.hpp" It looks to me that .inline.hpp is always safe to include instead of .hpp. Changing it the other way around may introduce build failures? Otherwise looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/langtools/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/nashorn/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/root/merge.changeset Looks good. > Ok to push? Apart from the Shenandoah include question, the whole bunch looks good. -- Thanks, -Aleksey From rkennke at redhat.com Tue May 5 09:40:58 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 May 2020 11:40:58 +0200 Subject: RFR (S) 8244326: Shenandoah: global statistics should not accept bogus samples In-Reply-To: References: <207f5d8e-56a4-9de3-16cc-752f7c16d44e@redhat.com> Message-ID: >> Why not declare uninitialized a const field? > > Wanted to maintain the symmetry against ShenandoahWorkerData::uninitialized(), which is > WorkerDataArray::uninitialized() in disguise: > > template <> > size_t WorkerDataArray::uninitialized() { > return (size_t)-1; > } > > template <> > double WorkerDataArray::uninitialized() { > return -1.0; > } Hmm, ok then. The compiler will know what to do with it (I hope). Roman From shade at redhat.com Tue May 5 09:43:38 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 May 2020 11:43:38 +0200 Subject: RFR (S) 8244326: Shenandoah: global statistics should not accept bogus samples In-Reply-To: References: <207f5d8e-56a4-9de3-16cc-752f7c16d44e@redhat.com> Message-ID: <0546ed4a-2947-c712-8378-a3a680386528@redhat.com> On 5/5/20 11:40 AM, Roman Kennke wrote: >>> Why not declare uninitialized a const field? >> >> Wanted to maintain the symmetry against ShenandoahWorkerData::uninitialized(), which is >> WorkerDataArray::uninitialized() in disguise: >> >> template <> >> size_t WorkerDataArray::uninitialized() { >> return (size_t)-1; >> } >> >> template <> >> double WorkerDataArray::uninitialized() { >> return -1.0; >> } > > Hmm, ok then. The compiler will know what to do with it (I hope). Yes. Even if compiler screws up, the flushes are done outside the pause ;) -- Thanks, -Aleksey From shade at redhat.com Tue May 5 09:59:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 May 2020 11:59:35 +0200 Subject: [14] RFR (S) 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache Message-ID: <378ddc0d-0f19-dd3d-e184-9ea0dc28142e@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8242365 https://hg.openjdk.java.net/jdk/jdk/rev/9e3539baac38 The patch does not apply cleanly to 14u due to changed context. I had to change some jushort* to ShenandoahLiveData* by hand. 14u webrev: https://cr.openjdk.java.net/~shade/8242365/webrev.14u.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Tue May 5 14:21:50 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 5 May 2020 10:21:50 -0400 Subject: [15] RFR 8244420: Shenandoah: Ensure _disarmed_value offset < 128 Message-ID: <71b84457-eed4-b46f-71f2-766a95921d66@redhat.com> Please review this small patch that ensures per-thread's disarmed_value offset is under 126 bytes. The offset is encoded in nmethod entry barrier code stream as a disp8 on x86_64. Bug: https://bugs.openjdk.java.net/browse/JDK-8244420 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244420/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From rkennke at redhat.com Tue May 5 15:10:26 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 5 May 2020 17:10:26 +0200 Subject: [15] RFR 8244420: Shenandoah: Ensure _disarmed_value offset < 128 In-Reply-To: <71b84457-eed4-b46f-71f2-766a95921d66@redhat.com> References: <71b84457-eed4-b46f-71f2-766a95921d66@redhat.com> Message-ID: <03d0f3d4-44f5-cc84-7489-aaef5a54838b@redhat.com> Looks good. Thanks, Roman > Please review this small patch that ensures per-thread's disarmed_value > offset is under 126 bytes. The offset is encoded in nmethod entry > barrier code stream as a disp8 on x86_64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244420 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244420/webrev.00/ > > Test: > ? hotspot_gc_shenandoah > > > Thanks, > > -Zhengyu > From shade at redhat.com Tue May 5 16:16:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 May 2020 18:16:16 +0200 Subject: [15] RFR 8244420: Shenandoah: Ensure _disarmed_value offset < 128 In-Reply-To: <71b84457-eed4-b46f-71f2-766a95921d66@redhat.com> References: <71b84457-eed4-b46f-71f2-766a95921d66@redhat.com> Message-ID: On 5/5/20 4:21 PM, Zhengyu Gu wrote: > Please review this small patch that ensures per-thread's disarmed_value > offset is under 126 bytes. The offset is encoded in nmethod entry > barrier code stream as a disp8 on x86_64. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244420 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244420/webrev.00/ *) Wouldn't it make sense to move the field right after the _gc_state then? *) Please see how STATIC_ASSERT-s are used, and do the same? -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed May 6 00:40:43 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 6 May 2020 01:40:43 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b01 Upstream Sync In-Reply-To: <70151c3f-4a75-71e3-8274-d02afa47788e@redhat.com> References: <70151c3f-4a75-71e3-8274-d02afa47788e@redhat.com> Message-ID: <3d9a2ee2-982f-f68b-2f45-260997303e36@redhat.com> On 05/05/2020 10:38, Aleksey Shipilev wrote: > On 5/5/20 7:39 AM, Andrew John Hughes wrote: snip... > > Not sure about this change: > > diff --git a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp > b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp > --- a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp > +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp > @@ -33,7 +33,7 @@ > #include "runtime/thread.inline.hpp" > #include "runtime/timer.hpp" > #include "utilities/ostream.hpp" > -#include "utilities/ticks.inline.hpp" > +#include "utilities/ticks.hpp" > > It looks to me that .inline.hpp is always safe to include instead of .hpp. Changing it the other way > around may introduce build failures? > > Otherwise looks fine. Not when it doesn't exist :-) With all the AArch64 changes, I forgot about this one which turned up on the local build. ticks.inline.hpp is removed by 8223147: "JFR Backport" and this same change is made there in the shared GC code e.g. https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/b985cbb00e68#l113.7 -- 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 May 6 09:12:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 11:12:37 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b01 Upstream Sync In-Reply-To: <3d9a2ee2-982f-f68b-2f45-260997303e36@redhat.com> References: <70151c3f-4a75-71e3-8274-d02afa47788e@redhat.com> <3d9a2ee2-982f-f68b-2f45-260997303e36@redhat.com> Message-ID: <9c3cc67f-0332-1c09-0de2-caecc2452c06@redhat.com> On 5/6/20 2:40 AM, Andrew John Hughes wrote: > On 05/05/2020 10:38, Aleksey Shipilev wrote: >> On 5/5/20 7:39 AM, Andrew John Hughes wrote: >> Not sure about this change: >> >> diff --git a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp >> b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp >> --- a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp >> +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp >> @@ -33,7 +33,7 @@ >> #include "runtime/thread.inline.hpp" >> #include "runtime/timer.hpp" >> #include "utilities/ostream.hpp" >> -#include "utilities/ticks.inline.hpp" >> +#include "utilities/ticks.hpp" >> >> It looks to me that .inline.hpp is always safe to include instead of .hpp. Changing it the other way >> around may introduce build failures? >> >> Otherwise looks fine. > > Not when it doesn't exist :-) Ah, okay then :D -- Thanks, -Aleksey From shade at redhat.com Wed May 6 09:51:29 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 11:51:29 +0200 Subject: RFR (S) 8244509: Shenandoah: refactor ShenandoahBarrierC2Support::test_* methods Message-ID: <57b4be6e-6c6f-e609-5b12-fab26381c02a@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244509 These methods are parts of critical paths and should be written in easy to understand form. Makes follow-up patches much more obvious. This one is mostly mechanical refactoring, except for introducing and rewiring "old_ctrl". Webrev: https://cr.openjdk.java.net/~shade/8244509/webrev.01/ Testing: hotspot_gc_shenandoah, benchmarks -- Thanks, -Aleksey From shade at redhat.com Wed May 6 09:51:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 11:51:37 +0200 Subject: RFR (S) 8244510: Shenandoah: invert SHC2Support::is_in_cset condition Message-ID: <4f153e02-8a32-5cfa-3a47-e202a40355d7@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244510 Current code in SHC2Support::is_in_cset treats "in cset" branch as frequent. We should really invert it after SFX barriers make that condition much less likely. It improves some benchmarks without any observable regressions on others. Note I opted to invert the condition instead of changing the probabilities, because I think it flows better: test_in_cset is UNLIKELY to be true now. Webrev: https://cr.openjdk.java.net/~shade/8244510/webrev.01/ Testing: hotspot_gc_shenandoah, benchmarks -- Thanks, -Aleksey From rkennke at redhat.com Wed May 6 09:57:35 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 May 2020 11:57:35 +0200 Subject: RFR (S) 8244510: Shenandoah: invert SHC2Support::is_in_cset condition In-Reply-To: <4f153e02-8a32-5cfa-3a47-e202a40355d7@redhat.com> References: <4f153e02-8a32-5cfa-3a47-e202a40355d7@redhat.com> Message-ID: Looks reasonable. Thank you, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244510 > > Current code in SHC2Support::is_in_cset treats "in cset" branch as frequent. We should really invert > it after SFX barriers make that condition much less likely. It improves some benchmarks without any > observable regressions on others. Note I opted to invert the condition instead of changing the > probabilities, because I think it flows better: test_in_cset is UNLIKELY to be true now. > > Webrev: > https://cr.openjdk.java.net/~shade/8244510/webrev.01/ > > Testing: hotspot_gc_shenandoah, benchmarks > From shade at redhat.com Wed May 6 10:42:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 12:42:12 +0200 Subject: [11] RFC: Pick up 11.0.8+2 to sh/jdk11 Message-ID: Upstream published 11.0.8+2, let's pick those up to sh/jdk11. Merge it trivial (only tags). I would tag the result shenandoah-jdk-11.0.8+2 immediately. Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed May 6 10:49:02 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 May 2020 12:49:02 +0200 Subject: [11] RFC: Pick up 11.0.8+2 to sh/jdk11 In-Reply-To: References: Message-ID: <68d4dd9a-82f7-679e-541c-945391bf5469@redhat.com> Go! Roman > Upstream published 11.0.8+2, let's pick those up to sh/jdk11. > > Merge it trivial (only tags). I would tag the result shenandoah-jdk-11.0.8+2 immediately. > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Wed May 6 11:30:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 13:30:39 +0200 Subject: [15] RFR 8244243: Shenandoah: Cleanup Shenandoah phase timing tracking and JFR event supporting In-Reply-To: References: Message-ID: On 5/1/20 7:08 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8244243 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244243/webrev.00/index.html It is a useful cleanup. I think it is better to get that cleanup complete: *) It feels it should be moved to shenandoahPhaseTimings and be renamed to ShenandoahTimingsTracker, to match ShenandoahWorkerTimingsTracker. "Trackers" are the good name for something that only touches the timings. *) Current ShenandoahGCPhaseTiming also carries current_phase for Shenandoah{Parallel,Concurrent}WorkerSession, shouldn't that be moved to ShenandoahGCPhase? *) Do these really need to be subclasses? I think delegation is called for here. class ShenandoahGCPhase : public ShenandoahGCPhaseTiming class ShenandoahPausePhase : public ShenandoahGCPhaseTiming class ShenandoahConcurrentPhase : public ShenandoahGCPhaseTiming -- Thanks, -Aleksey From shade at redhat.com Wed May 6 12:05:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 14:05:24 +0200 Subject: ANN: Shenandoah 11.0.8+ testing Message-ID: Hi, As 11.0.8+ release tree is now open and collects fixes that should culminate in release in mid July, Shenandoah 11u tree is also in similar position. It tracks upstream 11.0.8 closely, lagging a day or two after each 11u tag. (For example, I have just pushed shenandoah-jdk-11.0.8+2.) We have backported the bulk of the footprint, throughput, latency improvements done over the last several weeks, and there are more to come until we hit the release candidate. It also has a bunch of backported bugfixes. Please consider testing our nightlies in your canary deployments: https://wiki.openjdk.java.net/display/Shenandoah#Main-NightlyBuilds The quicker we find bugs there, the more probable they would get fixed before the next release. -- Thanks, -Aleksey From shade at redhat.com Wed May 6 12:06:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 14:06:14 +0200 Subject: [11] RFC: Pick up 11.0.8+2 to sh/jdk11 In-Reply-To: <68d4dd9a-82f7-679e-541c-945391bf5469@redhat.com> References: <68d4dd9a-82f7-679e-541c-945391bf5469@redhat.com> Message-ID: <035603b5-e68c-670b-5cfc-e1f79943021a@redhat.com> On 5/6/20 12:49 PM, Roman Kennke wrote: > Go! Thanks, pushed. -- -Aleksey From shade at redhat.com Wed May 6 12:04:04 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 06 May 2020 12:04:04 +0000 Subject: hg: shenandoah/jdk11: 22 new changesets Message-ID: <202005061204.046C46C9028089@aojmv0008.oracle.com> Changeset: 423b827deb4c Author: sgehwolf Date: 2020-04-17 11:14 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/423b827deb4c 8243059: Build fails when --with-vendor-name contains a comma Summary: Use $$(VERSION_CFLAGS) so as to avoid the variable getting evaluated early Reviewed-by: ihse, erikj ! make/launcher/LauncherCommon.gmk Changeset: 5e4b3a307c4b Author: goetz Date: 2020-04-29 10:55 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/5e4b3a307c4b Merge Changeset: 0cbaadf7de93 Author: prr Date: 2019-12-04 17:42 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/0cbaadf7de93 8214481: freetype path does not disable TrueType hinting with AA+FM hints Reviewed-by: serb, psadhukhan ! src/java.desktop/share/native/libfontmanager/freetypeScaler.c Changeset: 9d60e8cc2235 Author: prr Date: 2020-03-20 22:52 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/9d60e8cc2235 8232634: Problem List ICMColorDataTest.java Reviewed-by: serb, psadhukhan ! test/jdk/ProblemList.txt Changeset: cb1b202719d9 Author: roland Date: 2020-04-02 15:03 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/cb1b202719d9 8241900: Loop unswitching may cause dependence on null check to be lost Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopUnswitch.cpp + test/hotspot/jtreg/compiler/loopopts/TestLoopUnswitchingLostCastDependency.java Changeset: ee9b94d99e1b Author: jiefu Date: 2020-04-09 09:20 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ee9b94d99e1b 8242379: [TESTBUG] compiler/loopopts/TestLoopUnswitchingLostCastDependency.java fails with release VMs Reviewed-by: roland, kvn ! test/hotspot/jtreg/compiler/loopopts/TestLoopUnswitchingLostCastDependency.java Changeset: d98a442115fa Author: serb Date: 2020-04-06 20:27 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d98a442115fa 8196019: java/awt/Window/Grab/GrabTest.java fails on Windows Reviewed-by: prr, jdv ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Window/Grab/GrabTest.java Changeset: 2c96a3c96972 Author: serb Date: 2020-03-19 22:22 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/2c96a3c96972 8240786: [TESTBUG] The test java/awt/Window/GetScreenLocation/GetScreenLocationTest.java fails on HiDPI screen Reviewed-by: jdv, pbansal ! test/jdk/java/awt/Window/GetScreenLocation/GetScreenLocationTest.java Changeset: 222ea445ace3 Author: serb Date: 2020-03-31 19:19 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/222ea445ace3 8241808: [TESTBUG] The JDK-8039467 bug appeared on macOS Reviewed-by: kizune, pbansal ! test/jdk/java/awt/Choice/UnfocusableToplevel/UnfocusableToplevel.java Changeset: d512afc4fc11 Author: dtitov Date: 2020-04-27 12:48 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d512afc4fc11 8242239: [Graal] javax/management/generified/GenericTest.java fails: FAILED: queryMBeans sets same Reviewed-by: cjplummer, sspitsyn ! test/jdk/javax/management/generified/GenericTest.java ! test/jdk/javax/management/query/CustomQueryTest.java Changeset: fe4247fd22b0 Author: bulasevich Date: 2018-11-16 19:30 +0300 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/fe4247fd22b0 8213947: ARM32: failed check_simd should set UsePopCountInstruction to false Reviewed-by: kvn ! src/hotspot/cpu/arm/vm_version_arm_32.cpp Changeset: e3d59721d969 Author: tnakamura Date: 2020-03-28 16:47 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/e3d59721d969 8232846: ProcessHandle.Info command with non-English shows question marks Reviewed-by: stuefe, ysuenaga, rriggs ! src/java.base/windows/native/libjava/ProcessHandleImpl_win.c Changeset: d4aeef995581 Author: afarley Date: 2020-04-22 15:37 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d4aeef995581 8239365: ProcessBuilder test modifications for AIX execution Reviewed-by: rriggs, stuefe ! test/jdk/java/lang/ProcessBuilder/Basic.java Changeset: 52f7554706b2 Author: tnakamura Date: 2020-03-09 15:07 +0530 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/52f7554706b2 8240518: Incorrect JNU_ReleaseStringPlatformChars in Windows Print Reviewed-by: serb, pbansal, psadhukhan ! src/java.desktop/windows/native/libawt/windows/WPrinterJob.cpp ! src/java.desktop/windows/native/libawt/windows/awt_PrintControl.cpp Changeset: 45472096e1bb Author: henryjen Date: 2020-04-07 03:25 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/45472096e1bb 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Reviewed-by: alanb, dholmes Contributed-by: linzang at tencent.com ! make/launcher/LauncherCommon.gmk ! src/java.base/macosx/native/libjli/java_md_macosx.c ! src/java.base/share/native/libjli/java.c ! src/java.base/unix/native/libjli/java_md_solinux.c ! src/java.base/unix/native/libjli/java_md_solinux.h Changeset: cc0ab5c637ea Author: weijun Date: 2020-04-27 12:32 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/cc0ab5c637ea 8243539: Copyright info (Year) should be updated for fix of 8241638 Reviewed-by: weijun Contributed-by: Bin Liao ! make/launcher/LauncherCommon.gmk ! src/java.base/share/native/libjli/java.c ! src/java.base/unix/native/libjli/java_md_solinux.c ! src/java.base/unix/native/libjli/java_md_solinux.h Changeset: 4ed8a03c0d64 Author: alitvinov Date: 2020-04-20 19:25 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/4ed8a03c0d64 8242498: Invalid "sun.awt.TimedWindowEvent" object leads to JVM crash Reviewed-by: prr, serb ! src/java.desktop/windows/native/libawt/windows/awt_Window.cpp Changeset: 8ad331c184d4 Author: serb Date: 2020-04-16 10:12 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/8ad331c184d4 8196181: sun/java2d/GdiRendering/InsetClipping.java fails Reviewed-by: jdv ! test/jdk/ProblemList.txt ! test/jdk/sun/java2d/GdiRendering/InsetClipping.java Changeset: 88eaa453331e Author: dbatrak Date: 2020-01-27 13:02 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/88eaa453331e 8236996: Incorrect Roboto font rendering on Windows with subpixel antialiasing Reviewed-by: prr, serb ! src/java.desktop/share/classes/sun/font/FileFontStrike.java ! src/java.desktop/share/classes/sun/font/TrueTypeFont.java ! src/java.desktop/windows/native/libfontmanager/lcdglyph.c Changeset: d37f3b2d0da9 Author: goetz Date: 2020-05-06 10:03 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d37f3b2d0da9 Added tag jdk-11.0.8+2 for changeset 88eaa453331e ! .hgtags Changeset: 8cdc7bb222f2 Author: shade Date: 2020-05-06 12:38 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/8cdc7bb222f2 Merge ! .hgtags ! src/hotspot/share/opto/loopUnswitch.cpp Changeset: bcaf4226a23b Author: shade Date: 2020-05-06 12:38 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/bcaf4226a23b Added tag shenandoah-jdk-11.0.8+2 for changeset 8cdc7bb222f2 ! .hgtags From rkennke at redhat.com Wed May 6 12:39:36 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 May 2020 14:39:36 +0200 Subject: RFR (S) 8244509: Shenandoah: refactor ShenandoahBarrierC2Support::test_* methods In-Reply-To: <57b4be6e-6c6f-e609-5b12-fab26381c02a@redhat.com> References: <57b4be6e-6c6f-e609-5b12-fab26381c02a@redhat.com> Message-ID: <17acac76-da85-b7a0-2d7a-a465be457717@redhat.com> Looks ok to me. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244509 > > These methods are parts of critical paths and should be written in easy to understand form. Makes > follow-up patches much more obvious. This one is mostly mechanical refactoring, except for > introducing and rewiring "old_ctrl". > > Webrev: > https://cr.openjdk.java.net/~shade/8244509/webrev.01/ > > Testing: hotspot_gc_shenandoah, benchmarks > From rkennke at redhat.com Wed May 6 14:26:45 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 May 2020 16:26:45 +0200 Subject: RFR: 8244523: Shenandoah: Remove null-handling in LRB expansion Message-ID: <49639ccf-ac7a-3e2e-acf4-54b628269491@redhat.com> See discussion in: https://bugs.openjdk.java.net/browse/JDK-8244523 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8244523/webrev.00/ It gets rid of the whole block before expansion that finds and shuffles surrounding null-checks, the extra null-check before cset-check, the cloning of surrounding null-check to where the resolve-path has been (before the slowpath-call). It also removes the ideal-handling for CmpP. This attempted to eliminate barriers when doing if (obj == null), but this is already dealt-with in is_redundant(), and it also adds a case to is_redundant() to eliminate LRB when the only consumer is the uncommon-trap of a NULL-check (in the CallStaticJava case). Both are needed to avoid accidentally keeping an explicit null-check for what should become an implicit null-check instead. It also changes the in/out type of the runtime call to be the exact same type of the original value, instead of some bottom/notnull type with cast-to-original-type. Testing: hotspot_gc_shenandoah, specjbb and specjvm does not show regressions, some benchmarks seem to benefit a little. Manual inspection of generated assembly looks ok. Can I please get a review? From aph at redhat.com Wed May 6 14:29:37 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 May 2020 15:29:37 +0100 Subject: [11] RFR: Fix AArch64, add Shenandoah parts of JDK-8216989 In-Reply-To: <3561312d-4306-c395-6de6-c5b570795ca4@redhat.com> References: <3561312d-4306-c395-6de6-c5b570795ca4@redhat.com> Message-ID: <20664887-4c02-c45e-e049-8406aadfa00e@redhat.com> On 9/4/19 9:31 AM, Aleksey Shipilev wrote: > We have massive AArch64 failures in sh/jdk11 after recent merge, because we miss the > Shenandoah-specific parts of JDK-8216989 [1] backport. This fixes it: > http://cr.openjdk.java.net/~shade/8216989/webrev.11-sh.01/ > > The shape of the affected method is a bit different in sh/jdk11, so I had to adapt it. > > Testing: aarch64 hotspot_gc_shenandoah FYI: I'm working on the AArch64 8u backport for this same bug. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Wed May 6 14:50:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 16:50:42 +0200 Subject: RFR: 8244523: Shenandoah: Remove null-handling in LRB expansion In-Reply-To: <49639ccf-ac7a-3e2e-acf4-54b628269491@redhat.com> References: <49639ccf-ac7a-3e2e-acf4-54b628269491@redhat.com> Message-ID: On 5/6/20 4:26 PM, Roman Kennke wrote: > See discussion in: > https://bugs.openjdk.java.net/browse/JDK-8244523 > It also removes the ideal-handling for CmpP. This attempted to eliminate > barriers when doing if (obj == null), but this is already dealt-with in > is_redundant(), and it also adds a case to is_redundant() to eliminate > LRB when the only consumer is the uncommon-trap of a NULL-check (in the > CallStaticJava case). Both are needed to avoid accidentally keeping an > explicit null-check for what should become an implicit null-check instead. This feels like something not really related to this removal? No sense to split it out? > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8244523/webrev.00/ Mostly cosmetics: *) Comment indents: 486 fields[TypeFunc::Parms+0] = value_type; // original field value 487 fields[TypeFunc::Parms+1] = TypeRawPtr::BOTTOM; // original load address *) This needs a comment, something like "uncommon traps do not need barriers, values would be handled during deopt" or some such. 2932 if (n->as_CallStaticJava()->uncommon_trap_request() != 0) { 2933 break; 2934 } -- Thanks, -Aleksey From rkennke at redhat.com Wed May 6 14:58:52 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 May 2020 16:58:52 +0200 Subject: RFR: 8244523: Shenandoah: Remove null-handling in LRB expansion In-Reply-To: References: <49639ccf-ac7a-3e2e-acf4-54b628269491@redhat.com> Message-ID: <5f8837ad-4440-5602-c164-297636c44e89@redhat.com> >> See discussion in: >> https://bugs.openjdk.java.net/browse/JDK-8244523 > >> It also removes the ideal-handling for CmpP. This attempted to eliminate >> barriers when doing if (obj == null), but this is already dealt-with in >> is_redundant(), and it also adds a case to is_redundant() to eliminate >> LRB when the only consumer is the uncommon-trap of a NULL-check (in the >> CallStaticJava case). Both are needed to avoid accidentally keeping an >> explicit null-check for what should become an implicit null-check instead. > > This feels like something not really related to this removal? No sense to split it out? It is related. The CmpP and uncommon-trap-handling are there specifically to deal with null-checking. If I leave it out, we'll see extra null-checks being generated and regressions in benchmarks. >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8244523/webrev.00/ > > Mostly cosmetics: > > *) Comment indents: > > 486 fields[TypeFunc::Parms+0] = value_type; // original field value > 487 fields[TypeFunc::Parms+1] = TypeRawPtr::BOTTOM; // original load address > > *) This needs a comment, something like "uncommon traps do not need barriers, values would be > handled during deopt" or some such. > > 2932 if (n->as_CallStaticJava()->uncommon_trap_request() != 0) { > 2933 break; > 2934 } Ok: Diff: http://cr.openjdk.java.net/~rkennke/JDK-8244523/webrev.01.diff/ Full: http://cr.openjdk.java.net/~rkennke/JDK-8244523/webrev.01/ Good? Roman From shade at redhat.com Wed May 6 15:00:20 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 17:00:20 +0200 Subject: RFR: 8244523: Shenandoah: Remove null-handling in LRB expansion In-Reply-To: <5f8837ad-4440-5602-c164-297636c44e89@redhat.com> References: <49639ccf-ac7a-3e2e-acf4-54b628269491@redhat.com> <5f8837ad-4440-5602-c164-297636c44e89@redhat.com> Message-ID: <3d09677b-a0aa-8015-6773-79d06bf0756a@redhat.com> On 5/6/20 4:58 PM, Roman Kennke wrote: > Diff: > http://cr.openjdk.java.net/~rkennke/JDK-8244523/webrev.01.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8244523/webrev.01/ Yes, looks good. Roland needs to take a look? Break it up in lines: // Uncommon traps don't need barriers, values are handled during deoptimization. // It also affects null-checks into implicit null-checks. -- Thanks, -Aleksey From rkennke at redhat.com Wed May 6 20:04:59 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 May 2020 22:04:59 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark Message-ID: See bug for discussion: https://bugs.openjdk.java.net/browse/JDK-8244551 Fix is to make _update_watermark volatile and access to it ordered correctly with load_acquire() and release_store(). http://cr.openjdk.java.net/~rkennke/JDK-8244551/webrev.00/ Testing: testcase mentioned in bug on aarch64 several times, hotspot_gc_shenandoah Ok? Roman From zgu at redhat.com Wed May 6 20:19:41 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 6 May 2020 16:19:41 -0400 Subject: [15] RFR 8244243: Shenandoah: Cleanup Shenandoah phase timing tracking and JFR event supporting In-Reply-To: References: Message-ID: <96a2fc6f-6091-6791-5039-dff8f3004deb@redhat.com> Hi Aleksey, On 5/6/20 7:30 AM, Aleksey Shipilev wrote: > On 5/1/20 7:08 PM, Zhengyu Gu wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244243 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244243/webrev.00/index.html > > It is a useful cleanup. I think it is better to get that cleanup complete: > > *) It feels it should be moved to shenandoahPhaseTimings and be renamed to ShenandoahTimingsTracker, > to match ShenandoahWorkerTimingsTracker. "Trackers" are the good name for something that only > touches the timings. Sure, updated: http://cr.openjdk.java.net/~zgu/JDK-8244243/webrev.01/index.html > > *) Current ShenandoahGCPhaseTiming also carries current_phase for > Shenandoah{Parallel,Concurrent}WorkerSession, shouldn't that be moved to ShenandoahGCPhase? ShenandoahPausePhase/ShenandoahConcurrentPhase need to setup the phase for Shenandoah{Parallel,Concurrent}WorkerSession. Especially for concurrent phase, there might not have ShenandoahGCPhase in between, as JFR only supports 2 levels of concurrent event. > > *) Do these really need to be subclasses? I think delegation is called for here. > > class ShenandoahGCPhase : public ShenandoahGCPhaseTiming > class ShenandoahPausePhase : public ShenandoahGCPhaseTiming > class ShenandoahConcurrentPhase : public ShenandoahGCPhaseTiming I don't have preference either way. But delegation model requires ShenandoahGCPhaseTiming (now ShenandoahTimingsTracker) to be declared as value object (based on hotspot convention), which is inconsistent with other classes ... -Zhengyu > From rkennke at redhat.com Wed May 6 21:31:03 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 6 May 2020 23:31:03 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: References: Message-ID: Disregard this webrev, it contains another change, and Zhengyu also pointed out that I got volatile HeapWord* wrong: it should be HeapWord* volatile of course. I'll post another webrev tomorrow. Thanks, Roman > See bug for discussion: > https://bugs.openjdk.java.net/browse/JDK-8244551 > > Fix is to make _update_watermark volatile and access to it ordered > correctly with load_acquire() and release_store(). > > http://cr.openjdk.java.net/~rkennke/JDK-8244551/webrev.00/ > > Testing: testcase mentioned in bug on aarch64 several times, > hotspot_gc_shenandoah > > Ok? > > Roman > From rwestrel at redhat.com Thu May 7 07:18:40 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 07 May 2020 09:18:40 +0200 Subject: RFR (S) 8244509: Shenandoah: refactor ShenandoahBarrierC2Support::test_* methods In-Reply-To: <57b4be6e-6c6f-e609-5b12-fab26381c02a@redhat.com> References: <57b4be6e-6c6f-e609-5b12-fab26381c02a@redhat.com> Message-ID: <87pnbg5i27.fsf@redhat.com> > https://cr.openjdk.java.net/~shade/8244509/webrev.01/ Looks good. Roland. From rwestrel at redhat.com Thu May 7 07:22:25 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 07 May 2020 09:22:25 +0200 Subject: RFR (S) 8244510: Shenandoah: invert SHC2Support::is_in_cset condition In-Reply-To: <4f153e02-8a32-5cfa-3a47-e202a40355d7@redhat.com> References: <4f153e02-8a32-5cfa-3a47-e202a40355d7@redhat.com> Message-ID: <87mu6k5hvy.fsf@redhat.com> > https://cr.openjdk.java.net/~shade/8244510/webrev.01/ Looks good to me. Roland. From rwestrel at redhat.com Thu May 7 07:25:56 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 07 May 2020 09:25:56 +0200 Subject: RFR: 8244523: Shenandoah: Remove null-handling in LRB expansion In-Reply-To: <5f8837ad-4440-5602-c164-297636c44e89@redhat.com> References: <49639ccf-ac7a-3e2e-acf4-54b628269491@redhat.com> <5f8837ad-4440-5602-c164-297636c44e89@redhat.com> Message-ID: <87k11o5hq3.fsf@redhat.com> > http://cr.openjdk.java.net/~rkennke/JDK-8244523/webrev.01/ Ok. Roland. From shade at redhat.com Thu May 7 09:21:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 May 2020 11:21:24 +0200 Subject: [11] 2020-05-07, Bulk backports to sh/jdk11 Message-ID: <594005be-6cb0-bef4-c2d9-e97f05915ca2@redhat.com> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200507/webrev.01/ Here is a bunch of simpler backports for 11u: [backport] 8224573: Fix windows build after JDK-8221507 [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs [backport] 8243291: Shenandoah: no need to retire TLABs at Init Update Refs [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end [backport] 8243460: Shenandoah: purge init_update_refs_prepare counter [backport] 8243463: Shenandoah: ditch total_pause counters [backport] 8243464: Shenandoah: print statistic counters in time order [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Thu May 7 10:05:16 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 May 2020 12:05:16 +0200 Subject: 8244594: [BACKOUT] 8244523: Shenandoah: Remove null-handling in LRB expansion Message-ID: <66e2816d-f75e-5ed6-dab7-61351856082a@redhat.com> I accidentally pushed some experimental changes with JDK-8244523, I want to back this out, and re-push the patch that was reviewed. Bug: https://bugs.openjdk.java.net/browse/JDK-8244594 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8244594/webrev.00/ Good? Roman From rkennke at redhat.com Thu May 7 10:20:50 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 May 2020 12:20:50 +0200 Subject: RFR: 8244595: [REDO] 8244523: Shenandoah: Remove null-handling in LRB expansion Message-ID: Re-doing JDK-8244523, this time correctly. Bug: https://bugs.openjdk.java.net/browse/JDK-8244595 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8244595/webrev.00/ Ok? Roman From shade at redhat.com Thu May 7 10:23:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 May 2020 12:23:43 +0200 Subject: 8244594: [BACKOUT] 8244523: Shenandoah: Remove null-handling in LRB expansion In-Reply-To: <66e2816d-f75e-5ed6-dab7-61351856082a@redhat.com> References: <66e2816d-f75e-5ed6-dab7-61351856082a@redhat.com> Message-ID: <0bff84ed-b393-33dc-90b4-044255a5728c@redhat.com> On 5/7/20 12:05 PM, Roman Kennke wrote: > I accidentally pushed some experimental changes with JDK-8244523, I want > to back this out, and re-push the patch that was reviewed. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8244594 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8244594/webrev.00/ Looks fine. -- Thanks, -Aleksey From shade at redhat.com Thu May 7 10:35:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 May 2020 12:35:50 +0200 Subject: RFR: 8244595: [REDO] 8244523: Shenandoah: Remove null-handling in LRB expansion In-Reply-To: References: Message-ID: On 5/7/20 12:20 PM, Roman Kennke wrote: > Re-doing JDK-8244523, this time correctly. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8244595 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8244595/webrev.00/ Yes, thanks. I checked the generated code is sane now. -- Thanks, -Aleksey From rkennke at redhat.com Thu May 7 11:06:19 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 May 2020 13:06:19 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: References: Message-ID: Here comes the good fix. I changed volatile HeapWord* -> HeapWord* volatile. I also added an accessor that does unsynchronized/fast access, to be used at safepoint. I also moved the implementations to shenandoahHeap.inline.hpp, they are becoming more and more bulky to carry in .hpp. http://cr.openjdk.java.net/~rkennke/JDK-8244551/webrev.01/ Ok? Roman > Disregard this webrev, it contains another change, and Zhengyu also > pointed out that I got volatile HeapWord* wrong: it should be HeapWord* > volatile of course. I'll post another webrev tomorrow. > > Thanks, > Roman > >> See bug for discussion: >> https://bugs.openjdk.java.net/browse/JDK-8244551 >> >> Fix is to make _update_watermark volatile and access to it ordered >> correctly with load_acquire() and release_store(). >> >> http://cr.openjdk.java.net/~rkennke/JDK-8244551/webrev.00/ >> >> Testing: testcase mentioned in bug on aarch64 several times, >> hotspot_gc_shenandoah >> >> Ok? >> >> Roman >> > From shade at redhat.com Thu May 7 11:23:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 May 2020 13:23:11 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: References: Message-ID: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> On 5/7/20 1:06 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/JDK-8244551/webrev.01/ Nice. *) What's the point of this cast? 133 *const_cast(&_update_watermark) = w; *) Nit: message can be shorter "Should be at Shenandoah safepoint" 131 assert(SafepointSynchronize::is_at_safepoint(), 132 "only call set_update_watermark_at_safepoint at safepoint"); -- Thanks, -Aleksey From shade at redhat.com Thu May 7 11:31:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 May 2020 13:31:27 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> Message-ID: <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> On 5/7/20 1:30 PM, Roman Kennke wrote: >> *) What's the point of this cast? >> >> 133 *const_cast(&_update_watermark) = w; > > Make access non-volatile. You think it's too much? I don't think that is relevant. As long as it is not the atomic store (with fences), we are fine. -- Thanks, -Aleksey From rkennke at redhat.com Thu May 7 11:30:26 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 May 2020 13:30:26 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> Message-ID: >> http://cr.openjdk.java.net/~rkennke/JDK-8244551/webrev.01/ > > Nice. > > *) What's the point of this cast? > > 133 *const_cast(&_update_watermark) = w; Make access non-volatile. You think it's too much? > *) Nit: message can be shorter "Should be at Shenandoah safepoint" > > 131 assert(SafepointSynchronize::is_at_safepoint(), > 132 "only call set_update_watermark_at_safepoint at safepoint"); Ok, will change before push. Roman From rkennke at redhat.com Thu May 7 11:37:14 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 May 2020 13:37:14 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> Message-ID: >>> *) What's the point of this cast? >>> >>> 133 *const_cast(&_update_watermark) = w; >> >> Make access non-volatile. You think it's too much? > > I don't think that is relevant. As long as it is not the atomic store (with fences), we are fine. Ok. I will push the fix with this additional change then: diff -r 7910475d5001 src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp Thu May 07 07:03:25 2020 -0400 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp Thu May 07 07:36:26 2020 -0400 @@ -128,9 +128,8 @@ // Fast version that avoids synchronization, only to be used at safepoints. inline void ShenandoahHeapRegion::set_update_watermark_at_safepoint(HeapWord* w) { assert(bottom() <= w && w <= top(), "within bounds"); - assert(SafepointSynchronize::is_at_safepoint(), - "only call set_update_watermark_at_safepoint at safepoint"); - *const_cast(&_update_watermark) = w; + assert(SafepointSynchronize::is_at_safepoint(), "Should be at Shenandoah safepoint"); + _update_watermark = w; } #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGION_INLINE_HPP Thanks for reviewing! Roman From shade at redhat.com Thu May 7 11:37:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 May 2020 13:37:56 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> Message-ID: <7726d3bc-5157-1aa6-e2da-61354d02aad1@redhat.com> On 5/7/20 1:37 PM, Roman Kennke wrote: >>>> *) What's the point of this cast? >>>> >>>> 133 *const_cast(&_update_watermark) = w; >>> >>> Make access non-volatile. You think it's too much? >> >> I don't think that is relevant. As long as it is not the atomic store (with fences), we are fine. > > Ok. I will push the fix with this additional change then: > > diff -r 7910475d5001 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp > Thu May 07 07:03:25 2020 -0400 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp > Thu May 07 07:36:26 2020 -0400 > @@ -128,9 +128,8 @@ > // Fast version that avoids synchronization, only to be used at safepoints. > inline void > ShenandoahHeapRegion::set_update_watermark_at_safepoint(HeapWord* w) { > assert(bottom() <= w && w <= top(), "within bounds"); > - assert(SafepointSynchronize::is_at_safepoint(), > - "only call set_update_watermark_at_safepoint at safepoint"); > - *const_cast(&_update_watermark) = w; > + assert(SafepointSynchronize::is_at_safepoint(), "Should be at > Shenandoah safepoint"); > + _update_watermark = w; > } > > #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGION_INLINE_HPP Looks fine. As long as it compiles and passes the tests :) -- Thanks, -Aleksey From zgu at redhat.com Thu May 7 12:44:32 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 May 2020 08:44:32 -0400 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> Message-ID: So, the patch fixes the ordering of _top and _update_watermark to avoid assertion failure, but adds unnecessary penalty to production build? -Zhengyu On 5/7/20 7:37 AM, Roman Kennke wrote: >>>> *) What's the point of this cast? >>>> >>>> 133 *const_cast(&_update_watermark) = w; >>> >>> Make access non-volatile. You think it's too much? >> >> I don't think that is relevant. As long as it is not the atomic store (with fences), we are fine. > > Ok. I will push the fix with this additional change then: > > diff -r 7910475d5001 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp > Thu May 07 07:03:25 2020 -0400 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp > Thu May 07 07:36:26 2020 -0400 > @@ -128,9 +128,8 @@ > // Fast version that avoids synchronization, only to be used at safepoints. > inline void > ShenandoahHeapRegion::set_update_watermark_at_safepoint(HeapWord* w) { > assert(bottom() <= w && w <= top(), "within bounds"); > - assert(SafepointSynchronize::is_at_safepoint(), > - "only call set_update_watermark_at_safepoint at safepoint"); > - *const_cast(&_update_watermark) = w; > + assert(SafepointSynchronize::is_at_safepoint(), "Should be at > Shenandoah safepoint"); > + _update_watermark = w; > } > > #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGION_INLINE_HPP > > > Thanks for reviewing! > Roman > From rkennke at redhat.com Thu May 7 12:48:01 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 May 2020 14:48:01 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> Message-ID: > So, the patch fixes the ordering of _top and _update_watermark to avoid > assertion failure, but adds unnecessary penalty to production build? I wouldn't call that unnecessary. And the cost of it seems ok too, we don't update so very often, and we don't query it so very often either. I made the update-at-safepoint not use barriers, so that critical path should be ok. Roman > -Zhengyu > > > On 5/7/20 7:37 AM, Roman Kennke wrote: >>>>> *) What's the point of this cast? >>>>> >>>>> ? 133?? *const_cast(&_update_watermark) =? w; >>>> >>>> Make access non-volatile. You think it's too much? >>> >>> I don't think that is relevant. As long as it is not the atomic store >>> (with fences), we are fine. >> >> Ok. I will push the fix with this additional change then: >> >> diff -r 7910475d5001 >> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >> Thu May 07 07:03:25 2020 -0400 >> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >> Thu May 07 07:36:26 2020 -0400 >> @@ -128,9 +128,8 @@ >> ? // Fast version that avoids synchronization, only to be used at >> safepoints. >> ? inline void >> ShenandoahHeapRegion::set_update_watermark_at_safepoint(HeapWord* w) { >> ??? assert(bottom() <= w && w <= top(), "within bounds"); >> -? assert(SafepointSynchronize::is_at_safepoint(), >> -???????? "only call set_update_watermark_at_safepoint at safepoint"); >> -? *const_cast(&_update_watermark) =? w; >> +? assert(SafepointSynchronize::is_at_safepoint(), "Should be at >> Shenandoah safepoint"); >> +? _update_watermark = w; >> ? } >> >> ? #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGION_INLINE_HPP >> >> >> Thanks for reviewing! >> Roman >> > From zgu at redhat.com Thu May 7 12:55:02 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 May 2020 08:55:02 -0400 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> Message-ID: <55ef4301-0d1a-9ed2-dbce-0e2f32dc19a4@redhat.com> I did not follow this _update_watermark stuff closely. My experiment with Atomic::load/store(_update_watermark), I still saw stalled values. So I am not sure load_acquire/release_store() fix the stalled value problem, or stalled value just means more work, but not correctness? -Zhengyu On 5/7/20 8:48 AM, Roman Kennke wrote: >> So, the patch fixes the ordering of _top and _update_watermark to avoid >> assertion failure, but adds unnecessary penalty to production build? > > I wouldn't call that unnecessary. And the cost of it seems ok too, we > don't update so very often, and we don't query it so very often either. > I made the update-at-safepoint not use barriers, so that critical path > should be ok. > > Roman > > >> -Zhengyu >> >> >> On 5/7/20 7:37 AM, Roman Kennke wrote: >>>>>> *) What's the point of this cast? >>>>>> >>>>>> ? 133?? *const_cast(&_update_watermark) =? w; >>>>> >>>>> Make access non-volatile. You think it's too much? >>>> >>>> I don't think that is relevant. As long as it is not the atomic store >>>> (with fences), we are fine. >>> >>> Ok. I will push the fix with this additional change then: >>> >>> diff -r 7910475d5001 >>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>> Thu May 07 07:03:25 2020 -0400 >>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>> Thu May 07 07:36:26 2020 -0400 >>> @@ -128,9 +128,8 @@ >>> ? // Fast version that avoids synchronization, only to be used at >>> safepoints. >>> ? inline void >>> ShenandoahHeapRegion::set_update_watermark_at_safepoint(HeapWord* w) { >>> ??? assert(bottom() <= w && w <= top(), "within bounds"); >>> -? assert(SafepointSynchronize::is_at_safepoint(), >>> -???????? "only call set_update_watermark_at_safepoint at safepoint"); >>> -? *const_cast(&_update_watermark) =? w; >>> +? assert(SafepointSynchronize::is_at_safepoint(), "Should be at >>> Shenandoah safepoint"); >>> +? _update_watermark = w; >>> ? } >>> >>> ? #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGION_INLINE_HPP >>> >>> >>> Thanks for reviewing! >>> Roman >>> >> > From rkennke at redhat.com Thu May 7 13:12:12 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 May 2020 15:12:12 +0200 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: <55ef4301-0d1a-9ed2-dbce-0e2f32dc19a4@redhat.com> References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> <55ef4301-0d1a-9ed2-dbce-0e2f32dc19a4@redhat.com> Message-ID: <3abf87f7-b357-3882-1f83-8d5ca8052aeb@redhat.com> Atomic::load/store doesn't do anything wrt to ordering, it only ensures atomicity. Allocating thread would first update _top, and then _update_watermark, however, an observing thread that doesn't take the lock can observe the values updated in reverse order. By doing load_acquire() and release_store() we prevent that. Yes, it is more work (appropriate barriers), but that's ok. We should not see stale values anymore. I've run the test many times in a row without a failure, and it failed fairly reliably before. Roman > I did not follow this _update_watermark stuff closely. My experiment > with Atomic::load/store(_update_watermark), I still saw stalled values. > So I am not sure load_acquire/release_store() fix the stalled value > problem, or stalled value just means more work, but not correctness? > > -Zhengyu > > On 5/7/20 8:48 AM, Roman Kennke wrote: >>> So, the patch fixes the ordering of _top and _update_watermark to avoid >>> assertion failure, but adds unnecessary penalty to production build? >> >> I wouldn't call that unnecessary. And the cost of it seems ok too, we >> don't update so very often, and we don't query it so very often either. >> I made the update-at-safepoint not use barriers, so that critical path >> should be ok. >> >> Roman >> >> >>> -Zhengyu >>> >>> >>> On 5/7/20 7:37 AM, Roman Kennke wrote: >>>>>>> *) What's the point of this cast? >>>>>>> >>>>>>> ?? 133?? *const_cast(&_update_watermark) =? w; >>>>>> >>>>>> Make access non-volatile. You think it's too much? >>>>> >>>>> I don't think that is relevant. As long as it is not the atomic store >>>>> (with fences), we are fine. >>>> >>>> Ok. I will push the fix with this additional change then: >>>> >>>> diff -r 7910475d5001 >>>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>>> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>>> Thu May 07 07:03:25 2020 -0400 >>>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>>> Thu May 07 07:36:26 2020 -0400 >>>> @@ -128,9 +128,8 @@ >>>> ?? // Fast version that avoids synchronization, only to be used at >>>> safepoints. >>>> ?? inline void >>>> ShenandoahHeapRegion::set_update_watermark_at_safepoint(HeapWord* w) { >>>> ???? assert(bottom() <= w && w <= top(), "within bounds"); >>>> -? assert(SafepointSynchronize::is_at_safepoint(), >>>> -???????? "only call set_update_watermark_at_safepoint at safepoint"); >>>> -? *const_cast(&_update_watermark) =? w; >>>> +? assert(SafepointSynchronize::is_at_safepoint(), "Should be at >>>> Shenandoah safepoint"); >>>> +? _update_watermark = w; >>>> ?? } >>>> >>>> ?? #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGION_INLINE_HPP >>>> >>>> >>>> Thanks for reviewing! >>>> Roman >>>> >>> >> > From zgu at redhat.com Thu May 7 13:18:37 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 May 2020 09:18:37 -0400 Subject: RFR: 8244551: Shenandoah: Fix racy update of update_watermark In-Reply-To: <3abf87f7-b357-3882-1f83-8d5ca8052aeb@redhat.com> References: <5c99cbc2-56a7-c2d8-4d36-ed12f7609556@redhat.com> <8365cb9c-24a1-d60b-8184-90adf89753ba@redhat.com> <55ef4301-0d1a-9ed2-dbce-0e2f32dc19a4@redhat.com> <3abf87f7-b357-3882-1f83-8d5ca8052aeb@redhat.com> Message-ID: On 5/7/20 9:12 AM, Roman Kennke wrote: > Atomic::load/store doesn't do anything wrt to ordering, it only ensures > atomicity. > > Allocating thread would first update _top, and then _update_watermark, > however, an observing thread that doesn't take the lock can observe the > values updated in reverse order. By doing load_acquire() and > release_store() we prevent that. Yes, I understand that. Yes, it is more work (appropriate > barriers), but that's ok. Okay, then. Looks good to me. -Zhengyu We should not see stale values anymore. I've > run the test many times in a row without a failure, and it failed fairly > reliably before. > > Roman > >> I did not follow this _update_watermark stuff closely. My experiment >> with Atomic::load/store(_update_watermark), I still saw stalled values. >> So I am not sure load_acquire/release_store() fix the stalled value >> problem, or stalled value just means more work, but not correctness? >> >> -Zhengyu >> >> On 5/7/20 8:48 AM, Roman Kennke wrote: >>>> So, the patch fixes the ordering of _top and _update_watermark to avoid >>>> assertion failure, but adds unnecessary penalty to production build? >>> >>> I wouldn't call that unnecessary. And the cost of it seems ok too, we >>> don't update so very often, and we don't query it so very often either. >>> I made the update-at-safepoint not use barriers, so that critical path >>> should be ok. >>> >>> Roman >>> >>> >>>> -Zhengyu >>>> >>>> >>>> On 5/7/20 7:37 AM, Roman Kennke wrote: >>>>>>>> *) What's the point of this cast? >>>>>>>> >>>>>>>> ?? 133?? *const_cast(&_update_watermark) =? w; >>>>>>> >>>>>>> Make access non-volatile. You think it's too much? >>>>>> >>>>>> I don't think that is relevant. As long as it is not the atomic store >>>>>> (with fences), we are fine. >>>>> >>>>> Ok. I will push the fix with this additional change then: >>>>> >>>>> diff -r 7910475d5001 >>>>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>>>> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>>>> Thu May 07 07:03:25 2020 -0400 >>>>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp >>>>> Thu May 07 07:36:26 2020 -0400 >>>>> @@ -128,9 +128,8 @@ >>>>> ?? // Fast version that avoids synchronization, only to be used at >>>>> safepoints. >>>>> ?? inline void >>>>> ShenandoahHeapRegion::set_update_watermark_at_safepoint(HeapWord* w) { >>>>> ???? assert(bottom() <= w && w <= top(), "within bounds"); >>>>> -? assert(SafepointSynchronize::is_at_safepoint(), >>>>> -???????? "only call set_update_watermark_at_safepoint at safepoint"); >>>>> -? *const_cast(&_update_watermark) =? w; >>>>> +? assert(SafepointSynchronize::is_at_safepoint(), "Should be at >>>>> Shenandoah safepoint"); >>>>> +? _update_watermark = w; >>>>> ?? } >>>>> >>>>> ?? #endif // SHARE_GC_SHENANDOAH_SHENANDOAHHEAPREGION_INLINE_HPP >>>>> >>>>> >>>>> Thanks for reviewing! >>>>> Roman >>>>> >>>> >>> >> > From shade at redhat.com Thu May 7 16:38:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 May 2020 18:38:14 +0200 Subject: [15] RFR 8244243: Shenandoah: Cleanup Shenandoah phase timing tracking and JFR event supporting In-Reply-To: <96a2fc6f-6091-6791-5039-dff8f3004deb@redhat.com> References: <96a2fc6f-6091-6791-5039-dff8f3004deb@redhat.com> Message-ID: <4cb6ffa3-f0fa-f0ab-be84-204d25ee1e7b@redhat.com> On 5/6/20 10:19 PM, Zhengyu Gu wrote: > Sure, updated: > http://cr.openjdk.java.net/~zgu/JDK-8244243/webrev.01/index.html Looks fine, thank you. -- -Aleksey From rkennke at redhat.com Fri May 8 10:15:20 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 May 2020 12:15:20 +0200 Subject: [11] 2020-05-07, Bulk backports to sh/jdk11 In-Reply-To: <594005be-6cb0-bef4-c2d9-e97f05915ca2@redhat.com> References: <594005be-6cb0-bef4-c2d9-e97f05915ca2@redhat.com> Message-ID: Looks good! Thanks, Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200507/webrev.01/ > > Here is a bunch of simpler backports for 11u: > > [backport] 8224573: Fix windows build after JDK-8221507 > [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle > [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data > [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs > [backport] 8243291: Shenandoah: no need to retire TLABs at Init Update Refs > [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end > [backport] 8243460: Shenandoah: purge init_update_refs_prepare counter > [backport] 8243463: Shenandoah: ditch total_pause counters > [backport] 8243464: Shenandoah: print statistic counters in time order > [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Fri May 8 10:17:12 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 May 2020 12:17:12 +0200 Subject: [14] RFR (S) 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache In-Reply-To: <378ddc0d-0f19-dd3d-e184-9ea0dc28142e@redhat.com> References: <378ddc0d-0f19-dd3d-e184-9ea0dc28142e@redhat.com> Message-ID: <1ac87dfe-a949-8bc3-ffa6-229e4e1a1d3b@redhat.com> It looks good, thank you! Roman > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8242365 > https://hg.openjdk.java.net/jdk/jdk/rev/9e3539baac38 > > The patch does not apply cleanly to 14u due to changed context. I had to change some jushort* to > ShenandoahLiveData* by hand. 14u webrev: > https://cr.openjdk.java.net/~shade/8242365/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Fri May 8 10:16:30 2020 From: shade at redhat.com (shade at redhat.com) Date: Fri, 08 May 2020 10:16:30 +0000 Subject: hg: shenandoah/jdk11: 10 new changesets Message-ID: <202005081016.048AGWX5022893@aojmv0008.oracle.com> Changeset: 11dd9239891b Author: clanger Date: 2019-05-22 08:42 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/11dd9239891b [backport] 8224573: Fix windows build after JDK-8221507 Reviewed-by: shade, stuefe ! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp ! src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp Changeset: 07138371bf4a Author: shade Date: 2020-04-21 11:20 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/07138371bf4a [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp Changeset: 3816298cfc3f Author: shade Date: 2020-04-22 11:45 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/3816298cfc3f [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp Changeset: b02b97c46ce8 Author: shade Date: 2020-04-22 15:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/b02b97c46ce8 [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 36e7bfeebf7d Author: shade Date: 2020-04-22 15:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/36e7bfeebf7d [backport] 8243291: Shenandoah: no need to retire TLABs at Init Update Refs Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: f0be406b00d1 Author: shade Date: 2020-04-22 15:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/f0be406b00d1 [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Changeset: 2675e45a580c Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/2675e45a580c [backport] 8243460: Shenandoah: purge init_update_refs_prepare counter Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: b5ccd3c62a65 Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/b5ccd3c62a65 [backport] 8243463: Shenandoah: ditch total_pause counters Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 00b365dbb381 Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/00b365dbb381 [backport] 8243464: Shenandoah: print statistic counters in time order Reviewed-by: rkennke ! 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/shenandoahPhaseTimings.hpp Changeset: aef7ce70b5a6 Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/aef7ce70b5a6 [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp From shade at redhat.com Fri May 8 13:06:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 May 2020 15:06:10 +0200 Subject: [8] 2020-05-08, Bulk backports to sh/jdk8 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200508/webrev.01/ Here is a bunch of backports for 8u: [backport] 8242353: Shenandoah: micro-optimize region liveness handling [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end [backport] 8244551: Shenandoah: Fix racy update of update_watermark [backport] 8243463: Shenandoah: ditch total_pause counters [backport] 8243464: Shenandoah: print statistic counters in time order [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters [backport] 8243487: Shenandoah: make _num_phases illegal phase type [backport] 8244200: Shenandoah: build breakages after JDK-8241743 [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Fri May 8 13:08:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 May 2020 15:08:23 +0200 Subject: [11] RFR: Drop the workaround for JDK-8217717 Message-ID: <07d8d5b2-c720-b0c5-45be-303c5b6d27b2@redhat.com> Back when we backported self-fixing barriers, we had to include the workaround for JDK-8217717 [1]: https://hg.openjdk.java.net/shenandoah/jdk11/rev/b16b63a399f3#l6.61 That workaround arrived through upstream 11.0.7 and no longer needed. Let's drop it: https://cr.openjdk.java.net/~shade/shenandoah/11u-drop-8217717/webrev.01/ It seems to be exactly the same method that is in BarrierSetC1::resolve_address. I checked shenandoahBarrierSetC1.cpp is similar to what we have in jdk/jdk after this change. Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8217717 From rkennke at redhat.com Fri May 8 13:14:11 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 May 2020 15:14:11 +0200 Subject: [11] RFR: Drop the workaround for JDK-8217717 In-Reply-To: <07d8d5b2-c720-b0c5-45be-303c5b6d27b2@redhat.com> References: <07d8d5b2-c720-b0c5-45be-303c5b6d27b2@redhat.com> Message-ID: Yes, that looks good! Roman > Back when we backported self-fixing barriers, we had to include the workaround for JDK-8217717 [1]: > https://hg.openjdk.java.net/shenandoah/jdk11/rev/b16b63a399f3#l6.61 > > That workaround arrived through upstream 11.0.7 and no longer needed. Let's drop it: > https://cr.openjdk.java.net/~shade/shenandoah/11u-drop-8217717/webrev.01/ > > It seems to be exactly the same method that is in BarrierSetC1::resolve_address. I checked > shenandoahBarrierSetC1.cpp is similar to what we have in jdk/jdk after this change. > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Fri May 8 13:13:37 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 May 2020 15:13:37 +0200 Subject: [8] 2020-05-08, Bulk backports to sh/jdk8 In-Reply-To: References: Message-ID: <4555be0b-b393-57dd-fef2-ee6aa0cb9b7c@redhat.com> Looks good! Thank you! Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200508/webrev.01/ > > Here is a bunch of backports for 8u: > > [backport] 8242353: Shenandoah: micro-optimize region liveness handling > [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache > [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread > [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically > [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle > [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data > [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs > [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end > [backport] 8244551: Shenandoah: Fix racy update of update_watermark > [backport] 8243463: Shenandoah: ditch total_pause counters > [backport] 8243464: Shenandoah: print statistic counters in time order > [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters > [backport] 8243487: Shenandoah: make _num_phases illegal phase type > [backport] 8244200: Shenandoah: build breakages after JDK-8241743 > [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Fri May 8 13:28:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 May 2020 15:28:34 +0200 Subject: [8] 2020-05-08, Bulk backports to sh/jdk8 In-Reply-To: <4555be0b-b393-57dd-fef2-ee6aa0cb9b7c@redhat.com> References: <4555be0b-b393-57dd-fef2-ee6aa0cb9b7c@redhat.com> Message-ID: On 5/8/20 3:13 PM, Roman Kennke wrote: >> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200508/webrev.01/ >> >> Here is a bunch of backports for 8u: >> >> [backport] 8242353: Shenandoah: micro-optimize region liveness handling >> [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache >> [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread >> [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically >> [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle >> [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data >> [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs >> [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end >> [backport] 8244551: Shenandoah: Fix racy update of update_watermark >> [backport] 8243463: Shenandoah: ditch total_pause counters >> [backport] 8243464: Shenandoah: print statistic counters in time order >> [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters >> [backport] 8243487: Shenandoah: make _num_phases illegal phase type >> [backport] 8244200: Shenandoah: build breakages after JDK-8241743 >> [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods Pushed. -- Thanks, -Aleksey From shade at redhat.com Fri May 8 13:28:15 2020 From: shade at redhat.com (shade at redhat.com) Date: Fri, 08 May 2020 13:28:15 +0000 Subject: hg: shenandoah/jdk8/hotspot: 15 new changesets Message-ID: <202005081328.048DSG2j002398@aojmv0008.oracle.com> Changeset: 63ff28e2d3db Author: shade Date: 2020-04-08 13:44 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/63ff28e2d3db [backport] 8242353: Shenandoah: micro-optimize region liveness handling Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 7de7d252e64f Author: shade Date: 2020-04-08 13:44 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7de7d252e64f [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: cbd180202301 Author: shade Date: 2020-04-14 21:17 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/cbd180202301 [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread Reviewed-by: shade Contributed-by: Aditya Mandaleeka ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: ef326d11c8b4 Author: shade Date: 2020-04-14 22:18 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ef326d11c8b4 [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: f07807b7dc60 Author: shade Date: 2020-04-21 11:20 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f07807b7dc60 [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp Changeset: 086d50a5013a Author: shade Date: 2020-04-22 11:45 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/086d50a5013a [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp Changeset: 48ab5ac81f0e Author: shade Date: 2020-04-22 15:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/48ab5ac81f0e [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 79650d2d34d5 Author: shade Date: 2020-04-22 15:19 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/79650d2d34d5 [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp Changeset: 9f3d048ba5d8 Author: rkennke Date: 2020-05-07 08:00 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9f3d048ba5d8 [backport] 8244551: Shenandoah: Fix racy update of update_watermark Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 200762661cb6 Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/200762661cb6 [backport] 8243463: Shenandoah: ditch total_pause counters Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 504e60fe3333 Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/504e60fe3333 [backport] 8243464: Shenandoah: print statistic counters in time order Reviewed-by: rkennke ! 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/shenandoahPhaseTimings.hpp Changeset: 8dd67cec673e Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8dd67cec673e [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: bd0bd7315464 Author: shade Date: 2020-04-23 18:37 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/bd0bd7315464 [backport] 8243487: Shenandoah: make _num_phases illegal phase type Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 788b5b02f9b9 Author: shade Date: 2020-05-04 19:09 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/788b5b02f9b9 [backport] 8244200: Shenandoah: build breakages after JDK-8241743 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 6092e5747287 Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6092e5747287 [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.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/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.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/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp From shade at redhat.com Fri May 8 13:55:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 May 2020 15:55:57 +0200 Subject: [sh/8u] Root processing related backports In-Reply-To: References: Message-ID: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> On 3/17/20 5:27 PM, Zhengyu Gu wrote: > Webrev: > http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.00/ Please rebase this to the current sh/8u state? It should be simpler now that Traversal is gone. *) cleanup_jni_refs() is dropped in shenandoahConcurrentMark.cpp here, where is it added back? I looked at weak_roots_work(), is it in ShenandoahWeakRoots now? We have to be very accurate about this, because we broke it already at least once :) 501 // When we're done marking everything, we process weak references. 502 if (_heap->process_references()) { 503 weak_refs_work(full_gc); 504 } else { 505 cleanup_jni_refs(); 506 } *) The bug mentioned here has a reproducer, please try it? https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010952.html https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010973.html 310 // In JDK 8, this is handled by JNIHandles::weak_oops_do. We cannot enter here, because 311 // it would walk the JvmtiTagMap twice (which is okay) and possibly by multiple threads 312 // (which is not okay, because that walk is not thread-safe). In subsequent releases, 313 // it is handled in a more straightforward manner, see JDK-8189360. 314 /* 315 ShenandoahForwardedIsAliveClosure is_alive; 316 JvmtiExport::weak_oops_do(&is_alive, oops); 317 */ *) Commented out line here: 747 void ShenandoahConcurrentMark::weak_roots_work() { 748 // WorkGang* workers = _heap->workers(); 749 ShenandoahHeap* const heap = ShenandoahHeap::heap(); *) Inconsistent indenting at L137 here: 128 class ShenandoahRootScanner : public ShenandoahRootProcessor { 129 private: 130 ShenandoahSerialRoots _serial_roots; 131 ShenandoahSystemDictionaryRoots _dict_roots; 132 ShenandoahClassLoaderDataRoots _cld_roots; 133 ShenandoahThreadRoots _thread_roots; 134 ShenandoahWeakRoots _weak_roots; 135 ShenandoahStringDedupRoots _dedup_roots; 136 ShenandoahStringTableRoots _string_table_roots; 137 ShenandoahCodeCacheRoots _code_roots; ...and at L184 here: 174 // Evacuate all roots at a safepoint 175 class ShenandoahRootEvacuator : public ShenandoahRootProcessor { 176 private: 177 ShenandoahSerialRoots _serial_roots; 178 ShenandoahSystemDictionaryRoots _dict_roots; 179 ShenandoahClassLoaderDataRoots _cld_roots; 180 ShenandoahThreadRoots _thread_roots; 181 ShenandoahWeakRoots _weak_roots; 182 ShenandoahStringDedupRoots _dedup_roots; 183 ShenandoahStringTableRoots _string_table_roots; 184 ShenandoahCodeCacheRoots _code_roots; ...and L201 here: 193 class ShenandoahRootUpdater : public ShenandoahRootProcessor { 194 private: 195 ShenandoahSerialRoots _serial_roots; 196 ShenandoahSystemDictionaryRoots _dict_roots; 197 ShenandoahClassLoaderDataRoots _cld_roots; 198 ShenandoahThreadRoots _thread_roots; 199 ShenandoahWeakRoots _weak_roots; 200 ShenandoahStringDedupRoots _dedup_roots; 201 ShenandoahStringTableRoots _string_table_roots; 202 ShenandoahCodeCacheRoots _code_roots; 203 const bool _update_code_cache; ...and L219 here: 210 // Adjuster all roots at a safepoint during full gc 211 class ShenandoahRootAdjuster : public ShenandoahRootProcessor { 212 private: 213 ShenandoahSerialRoots _serial_roots; 214 ShenandoahSystemDictionaryRoots _dict_roots; 215 ShenandoahClassLoaderDataRoots _cld_roots; 216 ShenandoahThreadRoots _thread_roots; 217 ShenandoahWeakRoots _weak_roots; 218 ShenandoahStringDedupRoots _dedup_roots; 219 ShenandoahStringTableRoots _string_table_roots; 220 ShenandoahCodeCacheRoots _code_roots; *) shenandoahUtils.hpp has only the copyright header change? *) Double new line in shenandoahRootProcessor.inline.hpp here? 87 AlwaysTrueClosure always_true; 88 89 90 _serial_roots.oops_do(oops, worker_id); *) TestObjItrWithHeapDump.java: have you seen it run? Because I am not sure it even compiles with these. Those are still in com.oracle.*-something in 8u, IIRC. 36 import jdk.test.lib.process.ProcessTools; 37 import jdk.test.lib.process.OutputAnalyzer; -- Thanks, -Aleksey From shade at redhat.com Fri May 8 13:59:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 May 2020 15:59:50 +0200 Subject: [11] 2020-05-08, Backports to sh/jdk11 Message-ID: <123e36a3-2610-5e00-da08-adf5a129d635@redhat.com> http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200508/webrev.01/ This backports two critical bugfixes to sh/jdk11: [backport] 8244551: Shenandoah: Fix racy update of update_watermark [backport] 8244200: Shenandoah: build breakages after JDK-8241743 I had to change Atomic -> OrderAccess to make it compile. Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From zgu at redhat.com Fri May 8 16:50:11 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 8 May 2020 12:50:11 -0400 Subject: [sh/8u] Root processing related backports In-Reply-To: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> References: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> Message-ID: On 5/8/20 9:55 AM, Aleksey Shipilev wrote: > On 3/17/20 5:27 PM, Zhengyu Gu wrote: >> Webrev: >> http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.00/ > > Please rebase this to the current sh/8u state? It should be simpler now that Traversal is gone. This has to be redone, the patch has been left in the dust for a while. Will revisit it next week. Thanks, -Zhengyu > > *) cleanup_jni_refs() is dropped in shenandoahConcurrentMark.cpp here, where is it added back? I > looked at weak_roots_work(), is it in ShenandoahWeakRoots now? We have to be very accurate about > this, because we broke it already at least once :) > > 501 // When we're done marking everything, we process weak references. > 502 if (_heap->process_references()) { > 503 weak_refs_work(full_gc); > 504 } else { > 505 cleanup_jni_refs(); > 506 } > > *) The bug mentioned here has a reproducer, please try it? > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010952.html > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010973.html > > 310 // In JDK 8, this is handled by JNIHandles::weak_oops_do. We cannot enter here, because > 311 // it would walk the JvmtiTagMap twice (which is okay) and possibly by multiple threads > 312 // (which is not okay, because that walk is not thread-safe). In subsequent releases, > 313 // it is handled in a more straightforward manner, see JDK-8189360. > 314 /* > 315 ShenandoahForwardedIsAliveClosure is_alive; > 316 JvmtiExport::weak_oops_do(&is_alive, oops); > 317 */ > > *) Commented out line here: > > 747 void ShenandoahConcurrentMark::weak_roots_work() { > 748 // WorkGang* workers = _heap->workers(); > 749 ShenandoahHeap* const heap = ShenandoahHeap::heap(); > > *) Inconsistent indenting at L137 here: > > 128 class ShenandoahRootScanner : public ShenandoahRootProcessor { > 129 private: > 130 ShenandoahSerialRoots _serial_roots; > 131 ShenandoahSystemDictionaryRoots _dict_roots; > 132 ShenandoahClassLoaderDataRoots _cld_roots; > 133 ShenandoahThreadRoots _thread_roots; > 134 ShenandoahWeakRoots _weak_roots; > 135 ShenandoahStringDedupRoots _dedup_roots; > 136 ShenandoahStringTableRoots _string_table_roots; > 137 ShenandoahCodeCacheRoots _code_roots; > > ...and at L184 here: > > 174 // Evacuate all roots at a safepoint > 175 class ShenandoahRootEvacuator : public ShenandoahRootProcessor { > 176 private: > 177 ShenandoahSerialRoots _serial_roots; > 178 ShenandoahSystemDictionaryRoots _dict_roots; > 179 ShenandoahClassLoaderDataRoots _cld_roots; > 180 ShenandoahThreadRoots _thread_roots; > 181 ShenandoahWeakRoots _weak_roots; > 182 ShenandoahStringDedupRoots _dedup_roots; > 183 ShenandoahStringTableRoots _string_table_roots; > 184 ShenandoahCodeCacheRoots _code_roots; > > ...and L201 here: > > 193 class ShenandoahRootUpdater : public ShenandoahRootProcessor { > 194 private: > 195 ShenandoahSerialRoots _serial_roots; > 196 ShenandoahSystemDictionaryRoots _dict_roots; > 197 ShenandoahClassLoaderDataRoots _cld_roots; > 198 ShenandoahThreadRoots _thread_roots; > 199 ShenandoahWeakRoots _weak_roots; > 200 ShenandoahStringDedupRoots _dedup_roots; > 201 ShenandoahStringTableRoots _string_table_roots; > 202 ShenandoahCodeCacheRoots _code_roots; > 203 const bool _update_code_cache; > > ...and L219 here: > > 210 // Adjuster all roots at a safepoint during full gc > 211 class ShenandoahRootAdjuster : public ShenandoahRootProcessor { > 212 private: > 213 ShenandoahSerialRoots _serial_roots; > 214 ShenandoahSystemDictionaryRoots _dict_roots; > 215 ShenandoahClassLoaderDataRoots _cld_roots; > 216 ShenandoahThreadRoots _thread_roots; > 217 ShenandoahWeakRoots _weak_roots; > 218 ShenandoahStringDedupRoots _dedup_roots; > 219 ShenandoahStringTableRoots _string_table_roots; > 220 ShenandoahCodeCacheRoots _code_roots; > > *) shenandoahUtils.hpp has only the copyright header change? > > *) Double new line in shenandoahRootProcessor.inline.hpp here? > > 87 AlwaysTrueClosure always_true; > 88 > 89 > 90 _serial_roots.oops_do(oops, worker_id); > > *) TestObjItrWithHeapDump.java: have you seen it run? Because I am not sure it even compiles with > these. Those are still in com.oracle.*-something in 8u, IIRC. > > 36 import jdk.test.lib.process.ProcessTools; > 37 import jdk.test.lib.process.OutputAnalyzer; > From shade at redhat.com Fri May 8 17:32:15 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 8 May 2020 19:32:15 +0200 Subject: RFR (XXS) 8244667: Shenandoah: SBC2Support::test_gc_state takes loop for wrong control Message-ID: <0a8bc495-2fc6-fcb2-ae79-a2e005e1b53f@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8244667 When doing the refactoring in JDK-8244509, I accidentally made a change that was not semantic-preserving: get_loop is called on new ctrl from IfTrueNode, not the ctrl we have been passed. It went correctly in test_null and test_in_cset, but not in test_gc_state. It did not show up with any test failures, but it is important to get right anyway. Fix (in webrev form, so you can take a look around): https://cr.openjdk.java.net/~shade/8244667/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Fri May 8 21:03:18 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 8 May 2020 23:03:18 +0200 Subject: RFR (XXS) 8244667: Shenandoah: SBC2Support::test_gc_state takes loop for wrong control In-Reply-To: <0a8bc495-2fc6-fcb2-ae79-a2e005e1b53f@redhat.com> References: <0a8bc495-2fc6-fcb2-ae79-a2e005e1b53f@redhat.com> Message-ID: <1b406e61-0424-3ef5-0e0d-815c074be1e7@redhat.com> Looks good, thank you! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8244667 > > When doing the refactoring in JDK-8244509, I accidentally made a change that was not > semantic-preserving: get_loop is called on new ctrl from IfTrueNode, not the ctrl we have been > passed. It went correctly in test_null and test_in_cset, but not in test_gc_state. > > It did not show up with any test failures, but it is important to get right anyway. > > Fix (in webrev form, so you can take a look around): > https://cr.openjdk.java.net/~shade/8244667/webrev.01/ > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Mon May 11 11:25:58 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 May 2020 13:25:58 +0200 Subject: [11] 2020-05-08, Backports to sh/jdk11 In-Reply-To: <123e36a3-2610-5e00-da08-adf5a129d635@redhat.com> References: <123e36a3-2610-5e00-da08-adf5a129d635@redhat.com> Message-ID: <3dd4dde6-15b2-dff5-8cce-03cfafdbe0c0@redhat.com> Looks good, thanks! Roman > http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200508/webrev.01/ > > This backports two critical bugfixes to sh/jdk11: > [backport] 8244551: Shenandoah: Fix racy update of update_watermark > [backport] 8244200: Shenandoah: build breakages after JDK-8241743 > > I had to change Atomic -> OrderAccess to make it compile. > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From shade at redhat.com Mon May 11 11:38:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 May 2020 13:38:08 +0200 Subject: [11] 2020-05-08, Backports to sh/jdk11 In-Reply-To: <3dd4dde6-15b2-dff5-8cce-03cfafdbe0c0@redhat.com> References: <123e36a3-2610-5e00-da08-adf5a129d635@redhat.com> <3dd4dde6-15b2-dff5-8cce-03cfafdbe0c0@redhat.com> Message-ID: <3c59e1a7-fd44-3c5c-d400-abb5eeb91cb6@redhat.com> On 5/11/20 1:25 PM, Roman Kennke wrote: > Looks good, thanks! > > Roman > >> http://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200508/webrev.01/ >> >> This backports two critical bugfixes to sh/jdk11: >> [backport] 8244551: Shenandoah: Fix racy update of update_watermark >> [backport] 8244200: Shenandoah: build breakages after JDK-8241743 Pushed. -- Thanks, -Aleksey From shade at redhat.com Mon May 11 12:02:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 May 2020 14:02:05 +0200 Subject: RFR (XS) 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics Message-ID: <4c8d6834-646f-48b7-9ced-8d0dcc4648ca@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244730 gc/shenandoah/options/TestHeuristicsUnlock.java implicitly verifies the unlocking of IU or Passive mode. This is unnecessary, as we have /gc/shenandoah/options/TestModeUnlock.java, which does it explicitly. Current code works, because it has disabled some checks until Shenandoah is non-experimental. But it would break soon. We better off removing mode checks from this test. Fix: diff -r 158e145e3a42 test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java --- a/test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java Sat May 09 13:42:16 2020 -0700 +++ b/test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java Mon May 11 14:00:27 2020 +0200 @@ -46,12 +46,8 @@ public static void main(String[] args) throws Exception { - testWith("-XX:ShenandoahGCHeuristics=adaptive", Mode.PRODUCT); - testWith("-XX:ShenandoahGCHeuristics=static", Mode.PRODUCT); - testWith("-XX:ShenandoahGCHeuristics=compact", Mode.PRODUCT); - - testWith("-XX:ShenandoahGCMode=iu", Mode.EXPERIMENTAL); - + testWith("-XX:ShenandoahGCHeuristics=adaptive", Mode.PRODUCT); + testWith("-XX:ShenandoahGCHeuristics=static", Mode.PRODUCT); + testWith("-XX:ShenandoahGCHeuristics=compact", Mode.PRODUCT); testWith("-XX:ShenandoahGCHeuristics=aggressive", Mode.DIAGNOSTIC); - testWith("-XX:ShenandoahGCHeuristics=passive", Mode.DIAGNOSTIC); } Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Mon May 11 12:29:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 May 2020 14:29:25 +0200 Subject: RFR (S) 8244737: Shenandoah: move mode code to gc/shenandoah/mode Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8244737 Similarly to JDK-8244732, for cleanliness reasons, it makes sense to move all related mode code to gc/shenandoah/mode subfolder. Webrev: https://cr.openjdk.java.net/~shade/8244737/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Mon May 11 12:27:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 May 2020 14:27:57 +0200 Subject: RFR (S) 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics Message-ID: <5a8e5615-8d21-650d-e844-00333b2ca301@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244732 For cleanliness reasons, it makes sense to move all related heuristics code to gc/shenandoah/heuristics subfolder. This mostly affects the move of shenandoahHeuristics.hpp itself. Webrev: https://cr.openjdk.java.net/~shade/8244732/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Mon May 11 12:35:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 May 2020 14:35:22 +0200 Subject: RFR (S) 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode Message-ID: <2fc9d7fa-1085-8622-a186-e73d1bfedfad@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244739 Both ShenandoahPassiveMode and ShenandoahIUMode awkwardly subclass ShenandoahNormalMode, only to get initialize_heuristics() implemented. This would be awkward once we rename ShenandoahNormalMode to something else. Webrev: https://cr.openjdk.java.net/~shade/8244739/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Mon May 11 12:41:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 May 2020 14:41:14 +0200 Subject: RFR (S) 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode Message-ID: <7c471d8a-2cd4-90db-33e9-3f601c335a3b@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244740 Shenandoah modes define what barriers are emitted. Because of this, "normal" mode should be called "satb". It also underlines this mode to be the sibling of "iu" mode. Webrev: https://cr.openjdk.java.net/~shade/8244740/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Mon May 11 15:45:46 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 May 2020 17:45:46 +0200 Subject: RFR (XS) 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics In-Reply-To: <4c8d6834-646f-48b7-9ced-8d0dcc4648ca@redhat.com> References: <4c8d6834-646f-48b7-9ced-8d0dcc4648ca@redhat.com> Message-ID: OK! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244730 > > gc/shenandoah/options/TestHeuristicsUnlock.java implicitly verifies the unlocking of IU or Passive > mode. This is unnecessary, as we have /gc/shenandoah/options/TestModeUnlock.java, which does it > explicitly. Current code works, because it has disabled some checks until Shenandoah is > non-experimental. But it would break soon. We better off removing mode checks from this test. > > Fix: > > diff -r 158e145e3a42 test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java > --- a/test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java Sat May 09 13:42:16 > 2020 -0700 > +++ b/test/hotspot/jtreg/gc/shenandoah/options/TestHeuristicsUnlock.java Mon May 11 14:00:27 > 2020 +0200 > @@ -46,12 +46,8 @@ > > public static void main(String[] args) throws Exception { > - testWith("-XX:ShenandoahGCHeuristics=adaptive", Mode.PRODUCT); > - testWith("-XX:ShenandoahGCHeuristics=static", Mode.PRODUCT); > - testWith("-XX:ShenandoahGCHeuristics=compact", Mode.PRODUCT); > - > - testWith("-XX:ShenandoahGCMode=iu", Mode.EXPERIMENTAL); > - > + testWith("-XX:ShenandoahGCHeuristics=adaptive", Mode.PRODUCT); > + testWith("-XX:ShenandoahGCHeuristics=static", Mode.PRODUCT); > + testWith("-XX:ShenandoahGCHeuristics=compact", Mode.PRODUCT); > testWith("-XX:ShenandoahGCHeuristics=aggressive", Mode.DIAGNOSTIC); > - testWith("-XX:ShenandoahGCHeuristics=passive", Mode.DIAGNOSTIC); > } > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Mon May 11 15:47:25 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 May 2020 17:47:25 +0200 Subject: RFR (S) 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics In-Reply-To: <5a8e5615-8d21-650d-e844-00333b2ca301@redhat.com> References: <5a8e5615-8d21-650d-e844-00333b2ca301@redhat.com> Message-ID: Ok! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244732 > > For cleanliness reasons, it makes sense to move all related heuristics code to > gc/shenandoah/heuristics subfolder. This mostly affects the move of shenandoahHeuristics.hpp itself. > > Webrev: > https://cr.openjdk.java.net/~shade/8244732/webrev.01/ > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Mon May 11 15:49:46 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 May 2020 17:49:46 +0200 Subject: RFR (S) 8244737: Shenandoah: move mode code to gc/shenandoah/mode In-Reply-To: References: Message-ID: <2d60a0a0-aeb7-68fb-808a-270d8e38b6e4@redhat.com> Ok! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244737 > > Similarly to JDK-8244732, for cleanliness reasons, it makes sense to move all related mode code to > gc/shenandoah/mode subfolder. > > Webrev: > https://cr.openjdk.java.net/~shade/8244737/webrev.01/ > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Mon May 11 15:50:38 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 May 2020 17:50:38 +0200 Subject: RFR (S) 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode In-Reply-To: <2fc9d7fa-1085-8622-a186-e73d1bfedfad@redhat.com> References: <2fc9d7fa-1085-8622-a186-e73d1bfedfad@redhat.com> Message-ID: <839ca800-089a-8101-ddba-32c86e2751f4@redhat.com> Ok that makes sense! Patch looks good! Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244739 > > Both ShenandoahPassiveMode and ShenandoahIUMode awkwardly subclass ShenandoahNormalMode, only to get > initialize_heuristics() implemented. This would be awkward once we rename ShenandoahNormalMode to > something else. > > Webrev: > https://cr.openjdk.java.net/~shade/8244739/webrev.01/ > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Mon May 11 15:51:08 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 May 2020 17:51:08 +0200 Subject: RFR (S) 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode In-Reply-To: <7c471d8a-2cd4-90db-33e9-3f601c335a3b@redhat.com> References: <7c471d8a-2cd4-90db-33e9-3f601c335a3b@redhat.com> Message-ID: <03b7dfbe-d27d-49cb-88c1-69171856f3f4@redhat.com> Ok good! Thanks, Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244740 > > Shenandoah modes define what barriers are emitted. Because of this, "normal" mode should be called > "satb". It also underlines this mode to be the sibling of "iu" mode. > > Webrev: > https://cr.openjdk.java.net/~shade/8244740/webrev.01/ > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Mon May 11 17:53:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 May 2020 19:53:33 +0200 Subject: RFR (S) 8244759: Shenandoah: print verbose class unloading counters Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8244759 Webrev: https://cr.openjdk.java.net/~shade/8244759/webrev.01/ Zhengyu, do I use the new timing API correctly? Sample GC log: https://cr.openjdk.java.net/~shade/8244759/gc-log-sample.txt Testing: hotspot_gc_shenandoah (running) -- Thanks, -Aleksey From zgu at redhat.com Mon May 11 18:24:48 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 11 May 2020 14:24:48 -0400 Subject: RFR (S) 8244759: Shenandoah: print verbose class unloading counters In-Reply-To: References: Message-ID: Looks good. While you are there: 150 if (!heap->is_concurrent_weak_root_in_progress()) { 151 return; 152 } No longer needed. It have been checked by controller. Thanks, -Zhengyu On 5/11/20 1:53 PM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244759 > > Webrev: > https://cr.openjdk.java.net/~shade/8244759/webrev.01/ > > Zhengyu, do I use the new timing API correctly? > > Sample GC log: > https://cr.openjdk.java.net/~shade/8244759/gc-log-sample.txt > > Testing: hotspot_gc_shenandoah (running) > From shade at redhat.com Tue May 12 06:28:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 May 2020 08:28:44 +0200 Subject: RFR (S) 8244759: Shenandoah: print verbose class unloading counters In-Reply-To: References: Message-ID: <90f742a5-76ff-a46d-5f3c-6e3ce8100e60@redhat.com> On 5/11/20 8:24 PM, Zhengyu Gu wrote: > Looks good. Thanks. > While you are there: > > 150 if (!heap->is_concurrent_weak_root_in_progress()) { > 151 return; > 152 } I would prefer if that removal was done separately. -- Thanks, -Aleksey From shade at redhat.com Tue May 12 09:56:30 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 May 2020 11:56:30 +0200 Subject: RFR (XS) 8244807: Shenandoah: ditch filter in ShenandoahUnload::unload Message-ID: <7d8dc5af-1cc7-6982-8ae5-7e35420d974b@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244807 After JDK-8243323, the filter for is_$phase_in_progress() in ShenandoahUnload::unload() is no longer required. Cleanup: diff -r ef2f2bc93009 src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp Tue May 12 08:25:17 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp Tue May 12 11:55:10 2020 +0200 @@ -144,11 +144,7 @@ void ShenandoahUnload::unload() { - assert(ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(), "Why we here?"); - ShenandoahHeap* heap = ShenandoahHeap::heap(); - - if (!heap->is_concurrent_weak_root_in_progress()) { - return; - } + assert(ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(), "Filtered by caller"); + assert(heap->is_concurrent_weak_root_in_progress(), "Filtered by caller"); // Unlink stale metadata and nmethods Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Tue May 12 11:23:17 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 12 May 2020 13:23:17 +0200 Subject: RFR (XS) 8244807: Shenandoah: ditch filter in ShenandoahUnload::unload In-Reply-To: <7d8dc5af-1cc7-6982-8ae5-7e35420d974b@redhat.com> References: <7d8dc5af-1cc7-6982-8ae5-7e35420d974b@redhat.com> Message-ID: <92a398c1-3274-2c75-b60b-35416ee0c994@redhat.com> Ok, looks good to me. Roman > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244807 > > After JDK-8243323, the filter for is_$phase_in_progress() in ShenandoahUnload::unload() is no longer > required. Cleanup: > > diff -r ef2f2bc93009 src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp Tue May 12 08:25:17 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp Tue May 12 11:55:10 2020 +0200 > @@ -144,11 +144,7 @@ > > void ShenandoahUnload::unload() { > - assert(ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(), "Why we here?"); > - > ShenandoahHeap* heap = ShenandoahHeap::heap(); > - > - if (!heap->is_concurrent_weak_root_in_progress()) { > - return; > - } > + assert(ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(), "Filtered by caller"); > + assert(heap->is_concurrent_weak_root_in_progress(), "Filtered by caller"); > > // Unlink stale metadata and nmethods > > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Tue May 12 12:26:09 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 12 May 2020 14:26:09 +0200 Subject: RFR: 8244813: [BACKOUT] 8244523: Shenandoah: Remove null-handling in LRB expansion Message-ID: JDK-8244523 seems to cause a number of regression in nightlies (See: JDK-8244663 and maybe JDK-8244721). Let's back it out until we figure out the reasons for that. The backout was not clean because of refactorings in the same code paths. Bug: https://bugs.openjdk.java.net/browse/JDK-8244813 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8244813/webrev.02/ Testing: hotspot_gc_shenandoah Ok? Roman From shade at redhat.com Tue May 12 13:09:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 May 2020 15:09:42 +0200 Subject: RFR: 8244813: [BACKOUT] 8244523: Shenandoah: Remove null-handling in LRB expansion In-Reply-To: References: Message-ID: On 5/12/20 2:26 PM, Roman Kennke wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8244813 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8244813/webrev.02/ OK, thanks. -- -Aleksey From zgu at redhat.com Tue May 12 13:34:06 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 May 2020 09:34:06 -0400 Subject: [15] RFR 8244821: Shenandoah: disarmed_value is initialized at wrong place Message-ID: Aleksey discovered that JDK-8244328 changed where disarmed_value is set, which may cause nmethod entry barrier to see wrong disarmed value. Bug: https://bugs.openjdk.java.net/browse/JDK-8244821 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244821/webrev.00/index.html Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Tue May 12 13:39:09 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 May 2020 15:39:09 +0200 Subject: [15] RFR 8244821: Shenandoah: disarmed_value is initialized at wrong place In-Reply-To: References: Message-ID: On 5/12/20 3:34 PM, Zhengyu Gu wrote: > Aleksey discovered that JDK-8244328 changed where disarmed_value is set, > which may cause nmethod entry barrier to see wrong disarmed value. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244821 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244821/webrev.00/index.html Looks good! -- Thanks, -Aleksey From zgu at redhat.com Tue May 12 14:20:48 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 May 2020 10:20:48 -0400 Subject: RFR (XS) 8244807: Shenandoah: ditch filter in ShenandoahUnload::unload In-Reply-To: <7d8dc5af-1cc7-6982-8ae5-7e35420d974b@redhat.com> References: <7d8dc5af-1cc7-6982-8ae5-7e35420d974b@redhat.com> Message-ID: Looks good. -Zhengyu On 5/12/20 5:56 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244807 > > After JDK-8243323, the filter for is_$phase_in_progress() in ShenandoahUnload::unload() is no longer > required. Cleanup: > > diff -r ef2f2bc93009 src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp Tue May 12 08:25:17 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp Tue May 12 11:55:10 2020 +0200 > @@ -144,11 +144,7 @@ > > void ShenandoahUnload::unload() { > - assert(ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(), "Why we here?"); > - > ShenandoahHeap* heap = ShenandoahHeap::heap(); > - > - if (!heap->is_concurrent_weak_root_in_progress()) { > - return; > - } > + assert(ShenandoahConcurrentRoots::can_do_concurrent_class_unloading(), "Filtered by caller"); > + assert(heap->is_concurrent_weak_root_in_progress(), "Filtered by caller"); > > // Unlink stale metadata and nmethods > > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Tue May 12 16:58:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 May 2020 18:58:56 +0200 Subject: [11] 2020-05-12, Bulk backports to sh/jdk11 Message-ID: <289b78b8-dbcc-123b-5fbb-eb9f54d929f8@redhat.com> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200512/webrev.01/ This backports logging improvements to sh/jdk11. Not all patches apply cleanly, so please review carefully. Changesets: [backport] 8241984: Shenandoah: enhance GCTimer and JFR support [backport] 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods [backport] 8242400: Shenandoah: Restore logging to pre-jdk8241984 format [backport] 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles [backport] 8242638: Shenandoah: restore heap logging for uncommit [backport] 8243487: Shenandoah: make _num_phases illegal phase type [backport] 8243494: Shenandoah: set counters once per cycle [backport] 8239786: Shenandoah: print per-cycle statistics [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 [backport] 8243573: Shenandoah: rename GCParPhases and related code [backport] 8243578: Shenandoah: Cleanup ShenandoahStringDedup::parallel_oops_do() [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles [backport] 8244326: Shenandoah: global statistics should not accept bogus samples Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Tue May 12 18:25:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 12 May 2020 20:25:31 +0200 Subject: Class unloading in jdk15 In-Reply-To: References: Message-ID: Hi again, On 4/21/20 2:09 PM, Vicente Rossello wrote: > Let me know if I can provide something else If you are able, could you please take the latest jdk-jdk binary: https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-latest-linux-x86_64-release.tar.xz ...and run it with class unloading enabled and -Xlog:gc+stats? It would now print more verbose stats around class unloading, so we can take a look which part is really problematic. -- Thanks, -Aleksey From zgu at redhat.com Tue May 12 20:28:36 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 May 2020 16:28:36 -0400 Subject: [sh/8u] Root processing related backports In-Reply-To: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> References: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> Message-ID: <3a6e543d-e58a-8612-0bf7-d7f14cebe925@redhat.com> Updated: http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.01/ On 5/8/20 9:55 AM, Aleksey Shipilev wrote: > On 3/17/20 5:27 PM, Zhengyu Gu wrote: >> Webrev: >> http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.00/ > > Please rebase this to the current sh/8u state? It should be simpler now that Traversal is gone. > > *) cleanup_jni_refs() is dropped in shenandoahConcurrentMark.cpp here, where is it added back? I > looked at weak_roots_work(), is it in ShenandoahWeakRoots now? We have to be very accurate about > this, because we broke it already at least once :) Yes, jni weak handles are encapsulated in ShenandoahWeakRoots now. > > 501 // When we're done marking everything, we process weak references. > 502 if (_heap->process_references()) { > 503 weak_refs_work(full_gc); > 504 } else { > 505 cleanup_jni_refs(); > 506 } > Above logic is obvious fault, because processing weak references has nothing to do with jni weak handles. > *) The bug mentioned here has a reproducer, please try it? > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010952.html Tested. > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-October/010973.html > > 310 // In JDK 8, this is handled by JNIHandles::weak_oops_do. We cannot enter here, because > 311 // it would walk the JvmtiTagMap twice (which is okay) and possibly by multiple threads > 312 // (which is not okay, because that walk is not thread-safe). In subsequent releases, > 313 // it is handled in a more straightforward manner, see JDK-8189360. > 314 /* > 315 ShenandoahForwardedIsAliveClosure is_alive; > 316 JvmtiExport::weak_oops_do(&is_alive, oops); > 317 */ > > *) Commented out line here: > > 747 void ShenandoahConcurrentMark::weak_roots_work() { > 748 // WorkGang* workers = _heap->workers(); > 749 ShenandoahHeap* const heap = ShenandoahHeap::heap(); Fixed > > *) Inconsistent indenting at L137 here: > > 128 class ShenandoahRootScanner : public ShenandoahRootProcessor { > 129 private: > 130 ShenandoahSerialRoots _serial_roots; > 131 ShenandoahSystemDictionaryRoots _dict_roots; > 132 ShenandoahClassLoaderDataRoots _cld_roots; > 133 ShenandoahThreadRoots _thread_roots; > 134 ShenandoahWeakRoots _weak_roots; > 135 ShenandoahStringDedupRoots _dedup_roots; > 136 ShenandoahStringTableRoots _string_table_roots; > 137 ShenandoahCodeCacheRoots _code_roots; > > ...and at L184 here: > > 174 // Evacuate all roots at a safepoint > 175 class ShenandoahRootEvacuator : public ShenandoahRootProcessor { > 176 private: > 177 ShenandoahSerialRoots _serial_roots; > 178 ShenandoahSystemDictionaryRoots _dict_roots; > 179 ShenandoahClassLoaderDataRoots _cld_roots; > 180 ShenandoahThreadRoots _thread_roots; > 181 ShenandoahWeakRoots _weak_roots; > 182 ShenandoahStringDedupRoots _dedup_roots; > 183 ShenandoahStringTableRoots _string_table_roots; > 184 ShenandoahCodeCacheRoots _code_roots; > > ...and L201 here: > > 193 class ShenandoahRootUpdater : public ShenandoahRootProcessor { > 194 private: > 195 ShenandoahSerialRoots _serial_roots; > 196 ShenandoahSystemDictionaryRoots _dict_roots; > 197 ShenandoahClassLoaderDataRoots _cld_roots; > 198 ShenandoahThreadRoots _thread_roots; > 199 ShenandoahWeakRoots _weak_roots; > 200 ShenandoahStringDedupRoots _dedup_roots; > 201 ShenandoahStringTableRoots _string_table_roots; > 202 ShenandoahCodeCacheRoots _code_roots; > 203 const bool _update_code_cache; > > ...and L219 here: > > 210 // Adjuster all roots at a safepoint during full gc > 211 class ShenandoahRootAdjuster : public ShenandoahRootProcessor { > 212 private: > 213 ShenandoahSerialRoots _serial_roots; > 214 ShenandoahSystemDictionaryRoots _dict_roots; > 215 ShenandoahClassLoaderDataRoots _cld_roots; > 216 ShenandoahThreadRoots _thread_roots; > 217 ShenandoahWeakRoots _weak_roots; > 218 ShenandoahStringDedupRoots _dedup_roots; > 219 ShenandoahStringTableRoots _string_table_roots; > 220 ShenandoahCodeCacheRoots _code_roots; > Fixed > *) shenandoahUtils.hpp has only the copyright header change? > Removed. > *) Double new line in shenandoahRootProcessor.inline.hpp here? > > 87 AlwaysTrueClosure always_true; > 88 > 89 > 90 _serial_roots.oops_do(oops, worker_id); Fixed. > > *) TestObjItrWithHeapDump.java: have you seen it run? Because I am not sure it even compiles with > these. Those are still in com.oracle.*-something in 8u, IIRC. > > 36 import jdk.test.lib.process.ProcessTools; > 37 import jdk.test.lib.process.OutputAnalyzer; > The test was placed at wrong location, so it did not run. Now the test is refactored for 8u. Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Wed May 13 07:02:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 May 2020 09:02:50 +0200 Subject: [sh/8u] Root processing related backports In-Reply-To: <3a6e543d-e58a-8612-0bf7-d7f14cebe925@redhat.com> References: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> <3a6e543d-e58a-8612-0bf7-d7f14cebe925@redhat.com> Message-ID: <60fb376a-24a4-a037-2450-5a7bd1b7d072@redhat.com> On 5/12/20 10:28 PM, Zhengyu Gu wrote: > Updated: > http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.01/ Looks much better, thanks! Minor nits: *) Double ";;" in shenandoahClosures.inline.hpp here: 111 T o = oopDesc::load_heap_oop(p);; *) In here, we can pull ShenandoahWeakRoots out of both branches? 768 void ShenandoahConcurrentMark::weak_roots_work() { 769 ShenandoahHeap* const heap = ShenandoahHeap::heap(); 770 ShenandoahIsAliveSelector is_alive; 771 772 if (heap->has_forwarded_objects()) { 773 ShenandoahWeakUpdateClosure cl; 774 ShenandoahWeakRoots weak_roots; 775 weak_roots.weak_oops_do(is_alive.is_alive_closure(), &cl, 0); 776 } else { 777 DoNothingClosure cl; 778 ShenandoahWeakRoots weak_roots; 779 weak_roots.weak_oops_do(is_alive.is_alive_closure(), &cl, 0); 780 } 781 } *) This block in op_final_mark() looks redundant: 1457 if (has_forwarded_objects()) { 1458 // Degen may be caused by failed evacuation of roots 1459 if (is_degenerated_gc_in_progress()) { 1460 concurrent_mark()->update_roots(ShenandoahPhaseTimings::degen_gc_update_roots); 1461 } else { 1462 concurrent_mark()->update_thread_roots(ShenandoahPhaseTimings::update_roots); 1463 } 1464 } Look, it is removed here: https://hg.openjdk.java.net/jdk/jdk/rev/61f6c19d1a56#l3.23 ...and there is already the assert here: 1446 assert(!has_forwarded_objects(), "No forwarded objects on this path"); *) I think all other fields are in plural form, so it should be e.g. "_jvmti_roots"? 51 class ShenandoahSerialRoots { 52 private: 53 ShenandoahSerialRoot _universe_root; 54 ShenandoahSerialRoot _management_root; 55 ShenandoahSerialRoot _jvmti_root; 56 ShenandoahSerialRoot _jni_handle_root; 57 ShenandoahSerialRoot _flat_profiler_root; *) What are these additional checks for _invalid_phase? 132 ShenandoahGCWorkerPhase::ShenandoahGCWorkerPhase(const ShenandoahPhaseTimings::Phase phase) : 133 _timings(ShenandoahHeap::heap()->phase_timings()), _phase(phase) { 134 if (_phase != ShenandoahPhaseTimings::_invalid_phase) { 135 _timings->record_workers_start(_phase); 136 } 137 } 138 139 ShenandoahGCWorkerPhase::~ShenandoahGCWorkerPhase() { 140 if (_phase != ShenandoahPhaseTimings::_invalid_phase) { 141 _timings->record_workers_end(_phase); 142 } 143 } >> *) cleanup_jni_refs() is dropped in shenandoahConcurrentMark.cpp here, where is it added back? I >> looked at weak_roots_work(), is it in ShenandoahWeakRoots now? We have to be very accurate about >> this, because we broke it already at least once :) > > Yes, jni weak handles are encapsulated in ShenandoahWeakRoots now. > >> >> 501 // When we're done marking everything, we process weak references. >> 502 if (_heap->process_references()) { >> 503 weak_refs_work(full_gc); >> 504 } else { >> 505 cleanup_jni_refs(); >> 506 } >> > Above logic is obvious fault, because processing weak references has > nothing to do with jni weak handles. Kinda. 8u is special here: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-December/011193.html But, I can see that ShenandoahConcurrentMark::weak_roots_work() is now called unconditionally, so it does the same thing? And there is no explicit call to JvmtiExport::weak_oops_do, which makes us protected from this mess: 303 // In JDK 8, this is handled by JNIHandles::weak_oops_do. We cannot enter here, because 304 // it would walk the JvmtiTagMap twice (which is okay) and possibly by multiple threads 305 // (which is not okay, because that walk is not thread-safe). In subsequent releases, 306 // it is handled in a more straightforward manner, see JDK-8189360. 307 /* 308 ShenandoahForwardedIsAliveClosure is_alive; 309 JvmtiExport::weak_oops_do(&is_alive, oops); 310 */ -- Thanks, -Aleksey From shade at redhat.com Wed May 13 08:36:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 May 2020 10:36:56 +0200 Subject: [11] RFC: Pick up 11.0.8+3 to sh/jdk11 Message-ID: <80aef772-60be-0669-be4c-b7ce16a6f219@redhat.com> Upstream published 11.0.8+3, let's pick those up to sh/jdk11. Merge it trivial (only tags). I would tag the result shenandoah-jdk-11.0.8+3 immediately. Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Wed May 13 11:07:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 May 2020 13:07:43 +0200 Subject: Class unloading in jdk15 In-Reply-To: References: Message-ID: <3da1cb91-640b-a128-d719-1c7b2cfad75d@redhat.com> On 5/12/20 8:25 PM, Aleksey Shipilev wrote: > Hi again, > > On 4/21/20 2:09 PM, Vicente Rossello wrote: >> Let me know if I can provide something else > > If you are able, could you please take the latest jdk-jdk binary: > https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-latest-linux-x86_64-release.tar.xz > > ...and run it with class unloading enabled and -Xlog:gc+stats? > > It would now print more verbose stats around class unloading, so we can take a look which part is > really problematic. Vincente sent me the logs privately. Here are the salient parts, Code Roots work dominates when outliers happen: [2020-05-13T09:16:54.856+0000] Concurrent Class Unloading 2563469 us [2020-05-13T09:16:54.856+0000] Unlink Stale 2563068 us [2020-05-13T09:16:54.856+0000] System Dictionary 1758 us [2020-05-13T09:16:54.856+0000] Weak Class Links 27652 us [2020-05-13T09:16:54.856+0000] Code Roots 2533655 us [2020-05-13T09:16:54.856+0000] Rendezvous 105 us [2020-05-13T09:16:54.856+0000] Purge Unlinked 291 us [2020-05-13T09:16:54.856+0000] Code Roots 264 us [2020-05-13T09:16:54.856+0000] CLDG 27 us [2020-05-13T09:16:54.856+0000] Exception Caches 0 us [2020-05-13T09:17:06.522+0000] Concurrent Class Unloading 2305834 us [2020-05-13T09:17:06.522+0000] Unlink Stale 2305223 us [2020-05-13T09:17:06.522+0000] System Dictionary 2080 us [2020-05-13T09:17:06.522+0000] Weak Class Links 32926 us [2020-05-13T09:17:06.522+0000] Code Roots 2270215 us [2020-05-13T09:17:06.522+0000] Rendezvous 59 us [2020-05-13T09:17:06.522+0000] Purge Unlinked 533 us [2020-05-13T09:17:06.522+0000] Code Roots 272 us [2020-05-13T09:17:06.522+0000] CLDG 260 us [2020-05-13T09:17:06.522+0000] Exception Caches 0 us [2020-05-13T09:17:08.512+0000] Concurrent Class Unloading 1190682 us [2020-05-13T09:17:08.512+0000] Unlink Stale 1189699 us [2020-05-13T09:17:08.512+0000] System Dictionary 2995 us [2020-05-13T09:17:08.512+0000] Weak Class Links 48842 us [2020-05-13T09:17:08.512+0000] Code Roots 1137860 us [2020-05-13T09:17:08.512+0000] Rendezvous 91 us [2020-05-13T09:17:08.512+0000] Purge Unlinked 886 us [2020-05-13T09:17:08.512+0000] Code Roots 229 us [2020-05-13T09:17:08.512+0000] CLDG 657 us [2020-05-13T09:17:08.512+0000] Exception Caches 0 us [2020-05-13T09:17:26.046+0000] Concurrent Class Unloading 3125368 us [2020-05-13T09:17:26.046+0000] Unlink Stale 3123611 us [2020-05-13T09:17:26.046+0000] System Dictionary 2591 us [2020-05-13T09:17:26.046+0000] Weak Class Links 45748 us [2020-05-13T09:17:26.046+0000] Code Roots 3075268 us [2020-05-13T09:17:26.046+0000] Rendezvous 315 us [2020-05-13T09:17:26.046+0000] Purge Unlinked 1436 us [2020-05-13T09:17:26.046+0000] Code Roots 1280 us [2020-05-13T09:17:26.046+0000] CLDG 156 us [2020-05-13T09:17:26.046+0000] Exception Caches 0 us -- Thanks, -Aleksey From zgu at redhat.com Wed May 13 14:07:29 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 13 May 2020 10:07:29 -0400 Subject: Class unloading in jdk15 In-Reply-To: <3da1cb91-640b-a128-d719-1c7b2cfad75d@redhat.com> References: <3da1cb91-640b-a128-d719-1c7b2cfad75d@redhat.com> Message-ID: <90b93763-5e87-2034-7efc-38e7edeee6e6@redhat.com> On 5/13/20 7:07 AM, Aleksey Shipilev wrote: > On 5/12/20 8:25 PM, Aleksey Shipilev wrote: >> Hi again, >> >> On 4/21/20 2:09 PM, Vicente Rossello wrote: >>> Let me know if I can provide something else >> >> If you are able, could you please take the latest jdk-jdk binary: >> https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-latest-linux-x86_64-release.tar.xz >> >> ...and run it with class unloading enabled and -Xlog:gc+stats? >> >> It would now print more verbose stats around class unloading, so we can take a look which part is >> really problematic. > > Vincente sent me the logs privately. Did it still run into degenerated GC? -Zhengyu > > Here are the salient parts, Code Roots work dominates when outliers happen: > > [2020-05-13T09:16:54.856+0000] Concurrent Class Unloading 2563469 us > [2020-05-13T09:16:54.856+0000] Unlink Stale 2563068 us > [2020-05-13T09:16:54.856+0000] System Dictionary 1758 us > [2020-05-13T09:16:54.856+0000] Weak Class Links 27652 us > [2020-05-13T09:16:54.856+0000] Code Roots 2533655 us > [2020-05-13T09:16:54.856+0000] Rendezvous 105 us > [2020-05-13T09:16:54.856+0000] Purge Unlinked 291 us > [2020-05-13T09:16:54.856+0000] Code Roots 264 us > [2020-05-13T09:16:54.856+0000] CLDG 27 us > [2020-05-13T09:16:54.856+0000] Exception Caches 0 us > > [2020-05-13T09:17:06.522+0000] Concurrent Class Unloading 2305834 us > [2020-05-13T09:17:06.522+0000] Unlink Stale 2305223 us > [2020-05-13T09:17:06.522+0000] System Dictionary 2080 us > [2020-05-13T09:17:06.522+0000] Weak Class Links 32926 us > [2020-05-13T09:17:06.522+0000] Code Roots 2270215 us > [2020-05-13T09:17:06.522+0000] Rendezvous 59 us > [2020-05-13T09:17:06.522+0000] Purge Unlinked 533 us > [2020-05-13T09:17:06.522+0000] Code Roots 272 us > [2020-05-13T09:17:06.522+0000] CLDG 260 us > [2020-05-13T09:17:06.522+0000] Exception Caches 0 us > > [2020-05-13T09:17:08.512+0000] Concurrent Class Unloading 1190682 us > [2020-05-13T09:17:08.512+0000] Unlink Stale 1189699 us > [2020-05-13T09:17:08.512+0000] System Dictionary 2995 us > [2020-05-13T09:17:08.512+0000] Weak Class Links 48842 us > [2020-05-13T09:17:08.512+0000] Code Roots 1137860 us > [2020-05-13T09:17:08.512+0000] Rendezvous 91 us > [2020-05-13T09:17:08.512+0000] Purge Unlinked 886 us > [2020-05-13T09:17:08.512+0000] Code Roots 229 us > [2020-05-13T09:17:08.512+0000] CLDG 657 us > [2020-05-13T09:17:08.512+0000] Exception Caches 0 us > > [2020-05-13T09:17:26.046+0000] Concurrent Class Unloading 3125368 us > [2020-05-13T09:17:26.046+0000] Unlink Stale 3123611 us > [2020-05-13T09:17:26.046+0000] System Dictionary 2591 us > [2020-05-13T09:17:26.046+0000] Weak Class Links 45748 us > [2020-05-13T09:17:26.046+0000] Code Roots 3075268 us > [2020-05-13T09:17:26.046+0000] Rendezvous 315 us > [2020-05-13T09:17:26.046+0000] Purge Unlinked 1436 us > [2020-05-13T09:17:26.046+0000] Code Roots 1280 us > [2020-05-13T09:17:26.046+0000] CLDG 156 us > [2020-05-13T09:17:26.046+0000] Exception Caches 0 us > From shade at redhat.com Wed May 13 14:24:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 May 2020 16:24:21 +0200 Subject: Class unloading in jdk15 In-Reply-To: <90b93763-5e87-2034-7efc-38e7edeee6e6@redhat.com> References: <3da1cb91-640b-a128-d719-1c7b2cfad75d@redhat.com> <90b93763-5e87-2034-7efc-38e7edeee6e6@redhat.com> Message-ID: On 5/13/20 4:07 PM, Zhengyu Gu wrote: > Did it still run into degenerated GC? Oh yes, I believe outlier cycles end up in Degen GC. See here: http://cr.openjdk.java.net/~shade/shenandoah/conc-unload-outliers.log.xz -- Thanks, -Aleksey From kdnilsen at amazon.com Wed May 13 17:13:17 2020 From: kdnilsen at amazon.com (Nilsen, Kelvin) Date: Wed, 13 May 2020 17:13:17 +0000 Subject: RFR: 8241062: Shenandoah: rich asserts trigger "empty statement" inspection Message-ID: See http://cr.openjdk.java.net/~kdnilsen/JDK-8241062/webrev.00/ This patch addresses the problem described in https://bugs.openjdk.java.net/browse/JDK-8241062 Satisfies tier1, tier2, and hotspot_gc_shenandoah regression tests. Is this ok to merge? From shade at redhat.com Wed May 13 17:50:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 May 2020 19:50:33 +0200 Subject: RFR: 8241062: Shenandoah: rich asserts trigger "empty statement" inspection In-Reply-To: References: Message-ID: <33d685da-fb4c-2a5c-f643-ce8bdac261d3@redhat.com> On 5/13/20 7:13 PM, Nilsen, Kelvin wrote: > See http://cr.openjdk.java.net/~kdnilsen/JDK-8241062/webrev.00/ > > This patch addresses the problem described in https://bugs.openjdk.java.net/browse/JDK-8241062 > > Satisfies tier1, tier2, and hotspot_gc_shenandoah regression tests. > > Is this ok to merge? Looks fine. I'll sponsor it for you. -- Thanks, -Aleksey P.S. GC changes need to be referenced at hotspot-gc-dev@ for consistency/archival reasons, CC'ing. From zgu at redhat.com Wed May 13 17:56:23 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 13 May 2020 13:56:23 -0400 Subject: [sh/8u] Root processing related backports In-Reply-To: <60fb376a-24a4-a037-2450-5a7bd1b7d072@redhat.com> References: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> <3a6e543d-e58a-8612-0bf7-d7f14cebe925@redhat.com> <60fb376a-24a4-a037-2450-5a7bd1b7d072@redhat.com> Message-ID: Updated: http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.02/ > > Minor nits: > > *) Double ";;" in shenandoahClosures.inline.hpp here: > > 111 T o = oopDesc::load_heap_oop(p);; > Fixed > *) In here, we can pull ShenandoahWeakRoots out of both branches? > > 768 void ShenandoahConcurrentMark::weak_roots_work() { > 769 ShenandoahHeap* const heap = ShenandoahHeap::heap(); > 770 ShenandoahIsAliveSelector is_alive; > 771 > 772 if (heap->has_forwarded_objects()) { > 773 ShenandoahWeakUpdateClosure cl; > 774 ShenandoahWeakRoots weak_roots; > 775 weak_roots.weak_oops_do(is_alive.is_alive_closure(), &cl, 0); > 776 } else { > 777 DoNothingClosure cl; > 778 ShenandoahWeakRoots weak_roots; > 779 weak_roots.weak_oops_do(is_alive.is_alive_closure(), &cl, 0); > 780 } > 781 } > > *) This block in op_final_mark() looks redundant: > > 1457 if (has_forwarded_objects()) { > 1458 // Degen may be caused by failed evacuation of roots > 1459 if (is_degenerated_gc_in_progress()) { > 1460 concurrent_mark()->update_roots(ShenandoahPhaseTimings::degen_gc_update_roots); > 1461 } else { > 1462 concurrent_mark()->update_thread_roots(ShenandoahPhaseTimings::update_roots); > 1463 } > 1464 } > > Look, it is removed here: > https://hg.openjdk.java.net/jdk/jdk/rev/61f6c19d1a56#l3.23 > > ...and there is already the assert here: > > 1446 assert(!has_forwarded_objects(), "No forwarded objects on this path"); Right, I did not realize the backport (it came in after initial backport.) Fixed. > > *) I think all other fields are in plural form, so it should be e.g. "_jvmti_roots"? > > 51 class ShenandoahSerialRoots { > 52 private: > 53 ShenandoahSerialRoot _universe_root; > 54 ShenandoahSerialRoot _management_root; > 55 ShenandoahSerialRoot _jvmti_root; > 56 ShenandoahSerialRoot _jni_handle_root; > 57 ShenandoahSerialRoot _flat_profiler_root; > > Fixed. > *) What are these additional checks for _invalid_phase? > > 132 ShenandoahGCWorkerPhase::ShenandoahGCWorkerPhase(const ShenandoahPhaseTimings::Phase phase) : > 133 _timings(ShenandoahHeap::heap()->phase_timings()), _phase(phase) { > 134 if (_phase != ShenandoahPhaseTimings::_invalid_phase) { > 135 _timings->record_workers_start(_phase); > 136 } > 137 } > 138 > 139 ShenandoahGCWorkerPhase::~ShenandoahGCWorkerPhase() { > 140 if (_phase != ShenandoahPhaseTimings::_invalid_phase) { > 141 _timings->record_workers_end(_phase); > 142 } > 143 } > Hmm ... screwed up somewhere, removed. >>> *) cleanup_jni_refs() is dropped in shenandoahConcurrentMark.cpp here, where is it added back? I >>> looked at weak_roots_work(), is it in ShenandoahWeakRoots now? We have to be very accurate about >>> this, because we broke it already at least once :) >> >> Yes, jni weak handles are encapsulated in ShenandoahWeakRoots now. >> >>> >>> 501 // When we're done marking everything, we process weak references. >>> 502 if (_heap->process_references()) { >>> 503 weak_refs_work(full_gc); >>> 504 } else { >>> 505 cleanup_jni_refs(); >>> 506 } >>> >> Above logic is obvious fault, because processing weak references has >> nothing to do with jni weak handles. > > Kinda. 8u is special here: > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-December/011193.html > > But, I can see that ShenandoahConcurrentMark::weak_roots_work() is now called unconditionally, so it > does the same thing? And there is no explicit call to JvmtiExport::weak_oops_do, which makes us > protected from this mess: > > 303 // In JDK 8, this is handled by JNIHandles::weak_oops_do. We cannot enter here, because > 304 // it would walk the JvmtiTagMap twice (which is okay) and possibly by multiple threads > 305 // (which is not okay, because that walk is not thread-safe). In subsequent releases, > 306 // it is handled in a more straightforward manner, see JDK-8189360. > 307 /* > 308 ShenandoahForwardedIsAliveClosure is_alive; > 309 JvmtiExport::weak_oops_do(&is_alive, oops); > 310 */ > Ok, I digged into 8u reference processor, and yes, jni weak oops are cleaned there. Although, I could not find JDK-8189360 backport, but JVMTI weak oops no longer piggyback to JNIHandles::weak_oops_do() ... which I missed. So, let's call weak_roots_work() unconditional, has it filter out JNI weak oops if reference processing is on. Thanks, -Zhengyu From rkennke at redhat.com Wed May 13 18:08:41 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 May 2020 20:08:41 +0200 Subject: [11] RFC: Pick up 11.0.8+3 to sh/jdk11 In-Reply-To: <80aef772-60be-0669-be4c-b7ce16a6f219@redhat.com> References: <80aef772-60be-0669-be4c-b7ce16a6f219@redhat.com> Message-ID: Ok, let's do it! Thanks, Roman > Upstream published 11.0.8+3, let's pick those up to sh/jdk11. > > Merge it trivial (only tags). I would tag the result shenandoah-jdk-11.0.8+3 immediately. > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Wed May 13 18:09:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 May 2020 20:09:44 +0200 Subject: [11] RFC: Pick up 11.0.8+3 to sh/jdk11 In-Reply-To: References: <80aef772-60be-0669-be4c-b7ce16a6f219@redhat.com> Message-ID: <8eefb6be-52b9-57ef-1659-4eb41a0e2220@redhat.com> Pushed! On 5/13/20 8:08 PM, Roman Kennke wrote: > Ok, let's do it! > > Thanks, > Roman > > >> Upstream published 11.0.8+3, let's pick those up to sh/jdk11. >> >> Merge it trivial (only tags). I would tag the result shenandoah-jdk-11.0.8+3 immediately. >> >> Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed May 13 18:12:33 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 13 May 2020 20:12:33 +0200 Subject: [11] 2020-05-12, Bulk backports to sh/jdk11 In-Reply-To: <289b78b8-dbcc-123b-5fbb-eb9f54d929f8@redhat.com> References: <289b78b8-dbcc-123b-5fbb-eb9f54d929f8@redhat.com> Message-ID: Looks good to me. Thanks, Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200512/webrev.01/ > > This backports logging improvements to sh/jdk11. Not all patches apply cleanly, so please review > carefully. > > Changesets: > [backport] 8241984: Shenandoah: enhance GCTimer and JFR support > [backport] 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods > [backport] 8242400: Shenandoah: Restore logging to pre-jdk8241984 format > [backport] 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles > [backport] 8242638: Shenandoah: restore heap logging for uncommit > [backport] 8243487: Shenandoah: make _num_phases illegal phase type > [backport] 8243494: Shenandoah: set counters once per cycle > [backport] 8239786: Shenandoah: print per-cycle statistics > [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 > [backport] 8243573: Shenandoah: rename GCParPhases and related code > [backport] 8243578: Shenandoah: Cleanup ShenandoahStringDedup::parallel_oops_do() > [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly > [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles > [backport] 8244326: Shenandoah: global statistics should not accept bogus samples > > Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah, eyeballing gc logs > From shade at redhat.com Wed May 13 18:17:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 May 2020 20:17:04 +0200 Subject: [sh/8u] Root processing related backports In-Reply-To: References: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> <3a6e543d-e58a-8612-0bf7-d7f14cebe925@redhat.com> <60fb376a-24a4-a037-2450-5a7bd1b7d072@redhat.com> Message-ID: <0054879f-cbb5-a5a7-8138-8baba0c217d4@redhat.com> On 5/13/20 7:56 PM, Zhengyu Gu wrote: > Updated: > http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.02/ Very close! Roman needs to take a careful look as well. >> Kinda. 8u is special here: >> https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-December/011193.html >> >> But, I can see that ShenandoahConcurrentMark::weak_roots_work() is now called unconditionally, so it >> does the same thing? And there is no explicit call to JvmtiExport::weak_oops_do, which makes us >> protected from this mess: >> >> 303 // In JDK 8, this is handled by JNIHandles::weak_oops_do. We cannot enter here, because >> 304 // it would walk the JvmtiTagMap twice (which is okay) and possibly by multiple threads >> 305 // (which is not okay, because that walk is not thread-safe). In subsequent releases, >> 306 // it is handled in a more straightforward manner, see JDK-8189360. >> 307 /* >> 308 ShenandoahForwardedIsAliveClosure is_alive; >> 309 JvmtiExport::weak_oops_do(&is_alive, oops); >> 310 */ >> > Ok, I digged into 8u reference processor, and yes, jni weak oops are > cleaned there. > > Although, I could not find JDK-8189360 backport, but JVMTI weak oops no > longer piggyback to JNIHandles::weak_oops_do() ... which I missed. JDK-8189360 is not backported. Look in JNIHandleBlock::weak_oops_do: /* * JVMTI data structures may also contain weak oops. The iteration of them * is placed here so that we don't need to add it to each of the collectors. */ JvmtiExport::weak_oops_do(is_alive, f); So it would do JvmtiExport::weak_oops_do it during JNIHandle::weak_oops_do. Please make sure we never ever touch JvmtiExport::weak_oops_do if JNIHandle::weak_oops_do possibly runs in another worker. I would check myself tomorrow. -- Thanks, -Aleksey From shade at redhat.com Wed May 13 18:18:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 13 May 2020 20:18:19 +0200 Subject: [11] 2020-05-12, Bulk backports to sh/jdk11 In-Reply-To: References: <289b78b8-dbcc-123b-5fbb-eb9f54d929f8@redhat.com> Message-ID: <0ca366ee-e8e3-84b1-3388-b73f1d706619@redhat.com> Thanks, I'll wait for Zhengyu to take a look as well, as some of the complex patches are his. On 5/13/20 8:12 PM, Roman Kennke wrote: > Looks good to me. > > Thanks, > Roman > >> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200512/webrev.01/ >> >> This backports logging improvements to sh/jdk11. Not all patches apply cleanly, so please review >> carefully. >> >> Changesets: >> [backport] 8241984: Shenandoah: enhance GCTimer and JFR support >> [backport] 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods >> [backport] 8242400: Shenandoah: Restore logging to pre-jdk8241984 format >> [backport] 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles >> [backport] 8242638: Shenandoah: restore heap logging for uncommit >> [backport] 8243487: Shenandoah: make _num_phases illegal phase type >> [backport] 8243494: Shenandoah: set counters once per cycle >> [backport] 8239786: Shenandoah: print per-cycle statistics >> [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 >> [backport] 8243573: Shenandoah: rename GCParPhases and related code >> [backport] 8243578: Shenandoah: Cleanup ShenandoahStringDedup::parallel_oops_do() >> [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly >> [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles >> [backport] 8244326: Shenandoah: global statistics should not accept bogus samples >> >> Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah, eyeballing gc logs -- -Aleksey From zgu at redhat.com Wed May 13 19:03:03 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 13 May 2020 15:03:03 -0400 Subject: [11] 2020-05-12, Bulk backports to sh/jdk11 In-Reply-To: <0ca366ee-e8e3-84b1-3388-b73f1d706619@redhat.com> References: <289b78b8-dbcc-123b-5fbb-eb9f54d929f8@redhat.com> <0ca366ee-e8e3-84b1-3388-b73f1d706619@redhat.com> Message-ID: Looks good. -Zhengyu On 5/13/20 2:18 PM, Aleksey Shipilev wrote: > Thanks, I'll wait for Zhengyu to take a look as well, as some of the complex patches are his. > > On 5/13/20 8:12 PM, Roman Kennke wrote: >> Looks good to me. >> >> Thanks, >> Roman >> >>> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200512/webrev.01/ >>> >>> This backports logging improvements to sh/jdk11. Not all patches apply cleanly, so please review >>> carefully. >>> >>> Changesets: >>> [backport] 8241984: Shenandoah: enhance GCTimer and JFR support >>> [backport] 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods >>> [backport] 8242400: Shenandoah: Restore logging to pre-jdk8241984 format >>> [backport] 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles >>> [backport] 8242638: Shenandoah: restore heap logging for uncommit >>> [backport] 8243487: Shenandoah: make _num_phases illegal phase type >>> [backport] 8243494: Shenandoah: set counters once per cycle >>> [backport] 8239786: Shenandoah: print per-cycle statistics >>> [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 >>> [backport] 8243573: Shenandoah: rename GCParPhases and related code >>> [backport] 8243578: Shenandoah: Cleanup ShenandoahStringDedup::parallel_oops_do() >>> [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly >>> [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles >>> [backport] 8244326: Shenandoah: global statistics should not accept bogus samples >>> >>> Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah, eyeballing gc logs > From zgu at redhat.com Wed May 13 19:10:14 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 13 May 2020 15:10:14 -0400 Subject: [sh/8u] Root processing related backports In-Reply-To: <0054879f-cbb5-a5a7-8138-8baba0c217d4@redhat.com> References: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> <3a6e543d-e58a-8612-0bf7-d7f14cebe925@redhat.com> <60fb376a-24a4-a037-2450-5a7bd1b7d072@redhat.com> <0054879f-cbb5-a5a7-8138-8baba0c217d4@redhat.com> Message-ID: <0c19b065-b16e-6be5-f349-6563a8030ae7@redhat.com> > > JDK-8189360 is not backported. Look in JNIHandleBlock::weak_oops_do: > > /* > * JVMTI data structures may also contain weak oops. The iteration of them > * is placed here so that we don't need to add it to each of the collectors. > */ > JvmtiExport::weak_oops_do(is_alive, f); Looked at wrong place. Okay, recovered to original form and added comments: // When we're done marking everything, we process weak references. // It is not obvious, but reference processing actually calls // JNIHandle::weak_oops_do() to cleanup JNI and JVMTI weak oops. if (_heap->process_references()) { weak_refs_work(full_gc); } else { weak_roots_work(); } Updated: http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.03/ -Zhengyu > > So it would do JvmtiExport::weak_oops_do it during JNIHandle::weak_oops_do. Please make sure we > never ever touch JvmtiExport::weak_oops_do if JNIHandle::weak_oops_do possibly runs in another worker. > > I would check myself tomorrow. > From gnu.andrew at redhat.com Wed May 13 22:26:34 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 23:26:34 +0100 Subject: [RFR] [8u] 8u262-b02 Upstream Sync Message-ID: <5964076f-9adf-8d73-0263-887ae1a7a165@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b02: - JDK-8130737: AffineTransformOp can't handle child raster with non-zero x-offset - JDK-8172559: [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java - JDK-8230926: [macosx] Two apostrophes are entered instead of one with "U.S. International - PC" layout - JDK-8240576: JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges - JDK-8242883: Incomplete backport of JDK-8078268: backport test part Main issues of note: Much simpler this time; clean merge, only one HotSpot change. 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/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java | 7 b/src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java | 17 b/src/share/native/sun/awt/medialib/awt_ImagingLib.c | 14 b/src/share/native/sun/awt/medialib/safe_alloc.h | 4 b/test/java/awt/image/Raster/TestChildRasterOp.java | 99 b/test/javax/swing/text/html/parser/Parser/8078268/bug8078268.java | 72 b/test/javax/swing/text/html/parser/Parser/8078268/slowparse.html | 3539 ++++++++++ 8 files changed, 3743 insertions(+), 10 deletions(-) diffstat for hotspot b/.hgtags | 1 b/src/share/vm/opto/loopnode.cpp | 2 b/test/compiler/loopopts/TestBeautifyLoops.java | 61 ++++++++++++++++++++++++ 3 files changed, 63 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 Thu May 14 05:38:52 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 14 May 2020 05:38:52 +0000 Subject: hg: shenandoah/jdk11: 14 new changesets Message-ID: <202005140538.04E5cstS018586@aojmv0008.oracle.com> Changeset: 4700496b82c4 Author: zgu Date: 2020-04-08 08:13 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/4700496b82c4 [backport] 8241984: Shenandoah: enhance GCTimer and JFR support Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: 00b1b83bcd54 Author: zgu Date: 2020-04-08 11:21 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/00b1b83bcd54 [backport] 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods Reviewed-by: shade, rkennke ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: 64e2d5b29561 Author: zgu Date: 2020-04-09 08:43 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/64e2d5b29561 [backport] 8242400: Shenandoah: Restore logging to pre-jdk8241984 format Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: 45f49568ab2a Author: shade Date: 2020-04-14 15:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/45f49568ab2a [backport] 8242625: Shenandoah: restore heap logging for Degenerated/Full cycles Reviewed-by: rkennke, zgu ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: 14814aea097f Author: shade Date: 2020-04-14 15:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/14814aea097f [backport] 8242638: Shenandoah: restore heap logging for uncommit Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Changeset: 20ba8f4398ef Author: shade Date: 2020-04-23 18:37 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/20ba8f4398ef [backport] 8243487: Shenandoah: make _num_phases illegal phase type Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 2bff09005271 Author: shade Date: 2020-04-23 21:24 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/2bff09005271 [backport] 8243494: Shenandoah: set counters once per cycle Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp Changeset: 4bd73964982c Author: shade Date: 2020-04-24 11:45 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/4bd73964982c [backport] 8239786: Shenandoah: print per-cycle statistics Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 684df0132c7b Author: zgu Date: 2020-04-28 12:20 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/684df0132c7b [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 Reviewed-by: rkennke, stuefe ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: ff285d75fc4f Author: shade Date: 2020-04-30 10:02 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ff285d75fc4f [backport] 8243573: Shenandoah: rename GCParPhases and related code Reviewed-by: rkennke ! 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.hpp Changeset: 5e642d205807 Author: zgu Date: 2020-04-24 16:37 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/5e642d205807 [backport] 8243578: Shenandoah: Cleanup ShenandoahStringDedup::parallel_oops_do() Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp Changeset: 243c68be96bd Author: shade Date: 2020-04-30 18:05 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/243c68be96bd [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.hpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.inline.hpp ! 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.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.cpp ! src/hotspot/share/gc/shenandoah/shenandoahStringDedup.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp ! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp Changeset: c9cdb9eee4a0 Author: shade Date: 2020-05-01 16:03 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c9cdb9eee4a0 [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Changeset: d3cd587bb9a8 Author: shade Date: 2020-05-05 11:44 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/d3cd587bb9a8 [backport] 8244326: Shenandoah: global statistics should not accept bogus samples Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp From shade at redhat.com Thu May 14 05:59:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 May 2020 07:59:03 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b02 Upstream Sync In-Reply-To: <5964076f-9adf-8d73-0263-887ae1a7a165@redhat.com> References: <5964076f-9adf-8d73-0263-887ae1a7a165@redhat.com> Message-ID: <9ddc978f-3863-1970-9829-7546c1d90dc2@redhat.com> On 5/14/20 12:26 AM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jdk/merge.changeset Looks good. (Ok, this is a fun "" one). > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From shade at redhat.com Fri May 15 10:47:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 15 May 2020 12:47:41 +0200 Subject: RFR: 2020-05-15, Bulk backports to sh/jdk11 Message-ID: <14e32b86-a027-1f3a-00eb-666e13087330@redhat.com> https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200515/webrev.01/ This backports a few leftover changes: [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only... [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection [backport] 8224529: [TESTBUG] JFR TestShenandoahHeapRegion* tests fail on build w/o Shenandoah Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah -- Thanks, -Aleksey From shade at redhat.com Fri May 15 11:56:47 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 15 May 2020 13:56:47 +0200 Subject: [sh/8u] Root processing related backports In-Reply-To: <0c19b065-b16e-6be5-f349-6563a8030ae7@redhat.com> References: <23dbecbe-57bd-5b07-90e5-c2900a4cca98@redhat.com> <3a6e543d-e58a-8612-0bf7-d7f14cebe925@redhat.com> <60fb376a-24a4-a037-2450-5a7bd1b7d072@redhat.com> <0054879f-cbb5-a5a7-8138-8baba0c217d4@redhat.com> <0c19b065-b16e-6be5-f349-6563a8030ae7@redhat.com> Message-ID: <65aa7532-b9a0-63d1-f53e-4fe4df98cf4e@redhat.com> On 5/13/20 9:10 PM, Zhengyu Gu wrote: >> JDK-8189360 is not backported. Look in JNIHandleBlock::weak_oops_do: >> >> /* >> * JVMTI data structures may also contain weak oops. The iteration of them >> * is placed here so that we don't need to add it to each of the collectors. >> */ >> JvmtiExport::weak_oops_do(is_alive, f); > > Looked at wrong place. Okay, recovered to original form and added comments: > > // When we're done marking everything, we process weak references. > // It is not obvious, but reference processing actually calls > // JNIHandle::weak_oops_do() to cleanup JNI and JVMTI weak oops. > if (_heap->process_references()) { > weak_refs_work(full_gc); > } else { > weak_roots_work(); > } > > Updated: > http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.03/ Okay, this looks good. To follow-through the 8u insanity for double-checking, let's look at ShenandoahRootEvacuator. It does: ShenandoahSerialRoots _serial_roots; ShenandoahWeakRoots _weak_roots; ShenadoahSerialRoots does: _jni_handle_roots(&JNIHandles::oops_do, ShenandoahPhaseTimings::JNIRoots), _jvmti_roots(&JvmtiExport::oops_do, ShenandoahPhaseTimings::JVMTIRoots), ...and neither JNIHandles::oops_do nor JvmtiExport::oops_do visits JvmtiExport::weak_oops_do, or do something similar to it, e.g. JvmtiTagMap::weak_oops_do. ShenandoahWeakRoots does: _jni_weak_roots(&JNIHandles::weak_oops_do) ...which eventually enters JNIHandleBlock::weak_oops_do, which then does JvmtiExport::weak_oops_do. -- Thanks, -Aleksey From zgu at redhat.com Fri May 15 12:23:06 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 15 May 2020 08:23:06 -0400 Subject: [15] RFR 8244953: Shenandoah: gc/shenandoah/TestStringInternCleanup fails with broken string table root Message-ID: After concurrent weak roots processing, there may still be stale oops observed by threads, we need to flush them out before we can recycle trash regions. Otherwise, native barrier may see them as live oops, since region's TAMS marks are reset. Bug: https://bugs.openjdk.java.net/browse/JDK-8244953 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244953/webrev.00/index.html Test: hotspot_gc_shenandoah (10+ iterations) Thanks, -Zhengyu From rkennke at redhat.com Fri May 15 12:44:49 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 May 2020 14:44:49 +0200 Subject: RFR: 2020-05-15, Bulk backports to sh/jdk11 In-Reply-To: <14e32b86-a027-1f3a-00eb-666e13087330@redhat.com> References: <14e32b86-a027-1f3a-00eb-666e13087330@redhat.com> Message-ID: Looks good to me, thanks! Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200515/webrev.01/ > > This backports a few leftover changes: > [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only... > [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics > [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode > [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode > [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode > [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection > [backport] 8224529: [TESTBUG] JFR TestShenandoahHeapRegion* tests fail on build w/o Shenandoah > > Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah > From zgu at redhat.com Fri May 15 12:53:43 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 15 May 2020 12:53:43 +0000 Subject: hg: shenandoah/jdk8/hotspot: 8222992: Shenandoah: Pre-evacuate all roots Message-ID: <202005151253.04FCrha3005279@aojmv0008.oracle.com> Changeset: 3081bf5ef785 Author: zgu Date: 2019-05-02 09:49 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3081bf5ef785 8222992: Shenandoah: Pre-evacuate all roots Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp From zgu at redhat.com Fri May 15 12:56:06 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 15 May 2020 12:56:06 +0000 Subject: hg: shenandoah/jdk8/hotspot: 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle Message-ID: <202005151256.04FCu673006332@aojmv0008.oracle.com> Changeset: ba16b16da833 Author: zgu Date: 2019-05-27 14:34 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ba16b16da833 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.cpp From zgu at redhat.com Fri May 15 12:57:28 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 15 May 2020 12:57:28 +0000 Subject: hg: shenandoah/jdk8/hotspot: 8226413: Shenandoah: Separate root scanner for SH::object_iterate() Message-ID: <202005151257.04FCvSj7006852@aojmv0008.oracle.com> Changeset: 3a41fd38fde7 Author: zgu Date: 2019-06-20 10:12 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/3a41fd38fde7 8226413: Shenandoah: Separate root scanner for SH::object_iterate() Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp From zgu at redhat.com Fri May 15 12:57:51 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 15 May 2020 12:57:51 +0000 Subject: hg: shenandoah/jdk8/hotspot: 8231198: Shenandoah: heap walking should visit all roots most of the time Message-ID: <202005151257.04FCvpRR006960@aojmv0008.oracle.com> Changeset: ba34c5a91fac Author: shade Date: 2019-09-19 20:26 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/ba34c5a91fac 8231198: Shenandoah: heap walking should visit all roots most of the time Reviewed-by: zgu, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp From shade at redhat.com Fri May 15 13:30:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 15 May 2020 15:30:31 +0200 Subject: [15] RFR 8244953: Shenandoah: gc/shenandoah/TestStringInternCleanup fails with broken string table root In-Reply-To: References: Message-ID: On 5/15/20 2:23 PM, Zhengyu Gu wrote: > After concurrent weak roots processing, there may still be stale oops > observed by threads, we need to flush them out before we can recycle > trash regions. Otherwise, native barrier may see them as live oops, > since region's TAMS marks are reset. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244953 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244953/webrev.00/index.html Looks good. There is some logging work to do, like this: https://cr.openjdk.java.net/~shade/shenandoah/8244953-adds.patch -- Thanks, -Aleksey From zgu at redhat.com Fri May 15 14:44:23 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 15 May 2020 10:44:23 -0400 Subject: [15] RFR 8244953: Shenandoah: gc/shenandoah/TestStringInternCleanup fails with broken string table root In-Reply-To: References: Message-ID: Folded your add-on patch, retested and pushed. Thanks, -Zhengyu On 5/15/20 9:30 AM, Aleksey Shipilev wrote: > On 5/15/20 2:23 PM, Zhengyu Gu wrote: >> After concurrent weak roots processing, there may still be stale oops >> observed by threads, we need to flush them out before we can recycle >> trash regions. Otherwise, native barrier may see them as live oops, >> since region's TAMS marks are reset. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244953 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8244953/webrev.00/index.html > > Looks good. > > There is some logging work to do, like this: > https://cr.openjdk.java.net/~shade/shenandoah/8244953-adds.patch > From kdnilsen at amazon.com Fri May 15 15:05:03 2020 From: kdnilsen at amazon.com (Nilsen, Kelvin) Date: Fri, 15 May 2020 15:05:03 +0000 Subject: RFC Literally: 8232782: streamline post-LRB CAS barrier (aarch64) Message-ID: <9EFEDA57-C3AC-465E-ABBD-9DB0D62A4140@amazon.com> I've been planning to mimic the changes made with https://bugs.openjdk.java.net/browse/JDK-8222766 (Shenandoah: streamline post-LRB CAS barrier (x86)). Have run into a few challenges in that the AARCH64 variant of cmpxchg_oop has different arguments than the x86 version. In particular, AARCH64 has acquire, release, weak, and is_cae boolean arguments ?in place of the single Boolean exchange argument. I've been sleuthing though the implementation, but some "comments" would be very helpful if someone else is already familiar with this code as I am relatively new to both HotSpot and Shenandoah code bases, and to AARCH64 as well. Are these arguments providing support for ... different variants of ARM? different contextual state? experimentation with different code generation models? something else? By the way, is there a reliable and current document that addresses the "theory of operation" for coherency and synchronization between parallel tasks within the new and improved Shenandoah implementation? I have studied in depth the original Shenandoah design, but I haven't yet found any detailed descriptions (have reviewed recent talks with powerpoint overviews) of Shenandoah 2. My working assumptions are: 1. Multiple concurrent reader threads may discover the same previously uncopied object and decide to copy it. Each one in parallel copies the object and then uses CAS to "mark with forwarding address". The race is resolved to the thread that succeeds with CAS. The other threads abandon their copies and use the address "supplied" by the winning copy. 2. All threads will heal in place the obsolete pointer to the original object. But the healing process for each address also needs a lock, because a parallel mutator thread may overwrite the reference field between the moment when the reader fetched its value and attempts to replace the value with the relevant forwarding pointer. What does this lock look like to the healing reader? To the mutator? Or is there some argument as to why no locking is necessary here? Understanding the planned coordination protocol will help me get the code right for JDK-8232782 and will also help me to a better job of testing it. Thanks for any help you might be able to provide. From shade at redhat.com Fri May 15 17:31:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 15 May 2020 19:31:46 +0200 Subject: RFC Literally: 8232782: streamline post-LRB CAS barrier (aarch64) In-Reply-To: <9EFEDA57-C3AC-465E-ABBD-9DB0D62A4140@amazon.com> References: <9EFEDA57-C3AC-465E-ABBD-9DB0D62A4140@amazon.com> Message-ID: Hi, On 5/15/20 5:05 PM, Nilsen, Kelvin wrote: > Have run into a few challenges in that the AARCH64 variant of cmpxchg_oop has different arguments > than the x86 version. In particular, AARCH64 has acquire, release, weak, and is_cae boolean > arguments ?in place of the single Boolean exchange argument. I've been sleuthing though the > implementation, but some "comments" would be very helpful if someone else is already familiar > with this code as I am relatively new to both HotSpot and Shenandoah code bases, and to AARCH64 > as well. > Are these arguments providing support for ... > different variants of ARM? > different contextual state? > experimentation with different code generation models? > something else? The usual CAS we all love and cherish is usually a sequentially-consistent strong compare-and-set. Other variants are different relaxations/flavors of CAS: *) acquire/release: relaxes the memory ordering on CAS from seqcst to acq/rel; it is sometimes useful when seqcst is not really needed, or there is a seqcst operation nearby already. But, it is rather special optimization, and it should not be used by default; *) weak: relaxes the "strong" property, i.e. CAS can sporadically fail even when "compare value" is what we want. It is rather useful for LL/SC-based CAS loops, where we would retry the loop on whatever failure anyway, so we might as well use the weak form; *) is_cae: turns CAS into CAE (compare-and-exchange); in Hotspot nomenclature, it means you get to see the "failure witness", that is the actual memory value compare was done against. This can be exploited in Shenandoah CAS barrier [IIRC, x86 version already does]. When in doubt, use the default CAS. > My working assumptions are: > > 1. Multiple concurrent reader threads may discover the same previously uncopied object and decide > to copy it. Each one in parallel copies the object and then uses CAS to "mark with forwarding > address". The race is resolved to the thread that succeeds with CAS. The other threads abandon > their copies and use the address "supplied" by the winning copy. Yes. That is how it works. It should also be noted this happens before object reference is exposed to the rest of runtime system (including mutators), and only to-space references would ever be exposed. This is so called "strong to-space invariant". Previous incarnation of Shenandoah employed a weak to-space invariant, where you could see the from-space reference, and that forced CAS barrier paths to assume any conflicting store might as well be the store of from-space reference. Hence the retry loop... > 2. All threads will heal in place the obsolete pointer to the original object. But the healing > process for each address also needs a lock, because a parallel mutator thread may overwrite the > reference field between the moment when the reader fetched its value and attempts to replace the > value with the relevant forwarding pointer. What does this lock look like to the healing reader? > To the mutator? Or is there some argument as to why no locking is necessary here? If GC needs to update the reference to from-space object with reference to its to-space copy, GC just does the CAS(expect-from-space, put-to-space), and that is enough to resolve conflicts with either other GC threads trying the concurrent update, or mutators storing the value, even under the race. That is, in core, what "concurrent update references" phase does over the entire heap. Since CAS is atomic, it should not be possible to lose the mutator write. The update CAS might fail, and if that CAS was strong, that _definitely_ means something had overwritten the old, to-space reference. That means it was either the GC/mutator forwarding CAS-ed update, or mutator write. Mutator writes with strong to-space invariant mean we don't have to retry the update. This is what enables the simplification for CAS barrier you are working on :) Hope this helps. -- Thanks, -Aleksey From zgu at redhat.com Sat May 16 11:30:32 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Sat, 16 May 2020 07:30:32 -0400 Subject: [15] RFR 8245124: Shenandoah: optimize code root evacuation/update during concurrent class unloading Message-ID: Currently, we use general purpose ShenandoahNMethod::heal_nmethod() to evacuate/update nmethod during code root processing. It is not optimal, as the method deals with several scenarios. Instead, we should apply closure to evacuat/update nmethod directly. Inlining ShenandoahNMethod::oops_do() also helps. Bug:https://bugs.openjdk.java.net/browse/JDK-8245124 Webrev:http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.00/ Sample: Before: Concurrent Class Unloading?? =??? 0.231 s (a =???? 4046 us) (n =??? 57) (lvls, us =???? 2832,???? 3457,???? 3789,???? 4531, 5594) ? Unlink Stale?????????????? =??? 0.213 s (a =???? 3734 us) (n =??? 57) (lvls, us =???? 2500,???? 3164,???? 3477,???? 4199, 5293) ??? System Dictionary??????? =??? 0.001 s (a =?????? 12 us) (n =??? 57) (lvls, us =?????? 10,?????? 11,?????? 12,?????? 13, 16) ??? Weak Class Links???????? =??? 0.000 s (a =??????? 0 us) (n =??? 57) (lvls, us =??????? 0,??????? 0,??????? 0, 0,??????? 1) ??? Code Roots?????????????? =??? 0.212 s (a =???? 3721 us) (n =??? 57) (lvls, us =???? 2480,???? 3145,???? 3477,???? 4180, 5280) ? Rendezvous???????????????? =??? 0.007 s (a =????? 128 us) (n =??? 57) (lvls, us =?????? 75,????? 105,????? 119,????? 121, 230) ? Purge Unlinked???????????? =??? 0.008 s (a =????? 146 us) (n =??? 57) (lvls, us =?????? 99,????? 125,????? 145,????? 148, 251) ??? Code Roots?????????????? =??? 0.008 s (a =????? 145 us) (n =??? 57) (lvls, us =?????? 97,????? 125,????? 145,????? 148, 249) ??? CLDG???????????????????? =??? 0.000 s (a =??????? 1 us) (n =??? 57) (lvls, us =??????? 0,??????? 0,??????? 1, 1,??????? 2) ??? Exception Caches???????? =??? 0.000 s (a =??????? 0 us) (n =??? 57) (lvls, us =??????? 0,??????? 0,??????? 0, 0,??????? 1) After: Concurrent Class Unloading?? =??? 0.208 s (a =???? 3652 us) (n =??? 57) (lvls, us =???? 2559,???? 3281,???? 3457,???? 3965, 5780) ? Unlink Stale?????????????? =??? 0.190 s (a =???? 3340 us) (n =??? 57) (lvls, us =???? 2344,???? 2988,???? 3105,???? 3613, 5496) ??? System Dictionary??????? =??? 0.001 s (a =?????? 13 us) (n =??? 57) (lvls, us =??????? 9,?????? 11,?????? 12,?????? 13, 21) ??? Weak Class Links???????? =??? 0.000 s (a =??????? 0 us) (n =??? 57) (lvls, us =??????? 0,??????? 0,??????? 0, 0,??????? 1) ??? Code Roots?????????????? =??? 0.190 s (a =???? 3326 us) (n =??? 57) (lvls, us =???? 2324,???? 2969,???? 3086,???? 3613, 5482) ? Rendezvous???????????????? =??? 0.007 s (a =????? 129 us) (n =??? 57) (lvls, us =?????? 80,????? 107,????? 117,????? 119, 253) ? Purge Unlinked???????????? =??? 0.008 s (a =????? 146 us) (n =??? 57) (lvls, us =????? 107,????? 127,????? 146,????? 148, 260) ??? Code Roots?????????????? =??? 0.008 s (a =????? 145 us) (n =??? 57) (lvls, us =????? 107,????? 127,????? 145,????? 148, 258) ??? CLDG???????????????????? =??? 0.000 s (a =??????? 0 us) (n =??? 57) (lvls, us =??????? 0,??????? 0,??????? 0, 0,??????? 1) ??? Exception Caches???????? =??? 0.000 s (a =??????? 0 us) (n =??? 57) (lvls, us =??????? 0,??????? 0,??????? 0, 0,??????? 0) Test: ? hotspot_gc_shenandoah Thanks, -Zhengyu From raell at web.de Mon May 18 01:16:29 2020 From: raell at web.de (raell at web.de) Date: Mon, 18 May 2020 03:16:29 +0200 Subject: Long pause for processing weakrefs in DaCapo benchmark Message-ID: Hi all, I'm evaluating runtime and pauses for various GCs using the DaCapo benchmark suite. For benchmark "tradesoap" I observe a long maximal pause time in Shenandoah. As an example, from a run using default parameters for each GC: Runtime: 43s (Shenandoah), 34s (ZGC), 25s (Parallel), 26s (G1) Max Pause: 147ms (Shenandoah), 8.8ms (ZGC), 123ms (Parallel), 109ms (G1) The long pause results from weakrefs processing. I've been varying several parameters like ShenandoahMinFreeThreshold, ShenandoahSATBBufferSize, ShenandoahRefProcFrequency, or setting +ClassUnloadingWithConcurrentMark or +UseNUMA. But it didn't improve much. For instance, with ShenandoahMinFreeThreshold=90 the max pause reduced to 80ms (and the runtime increased for 20%). Below there is an output from two runs, one with class unloading enabled and one with class unloading disabled. Is there a parameter that can be set or something else what can be done to reduce the maximal pause time significantly? BTW: For the other benchmarks in the suite, the max pause looks fine (around 10ms or lower). Thanks and best regards Ralph The benchmark has been runing on Debian using AdoptOpenJDK jdk-14+36. Hardware: 6 cores, 16GB RAM. ------------------------------------------------------------------------------------------- 1. Example: class unloading enabled yields: Pause Final Mark (update refs) (process weakrefs) (unload classes) 172.116ms ------------------------------------------------------------------------------------------- java -Xms1G -Xmx1G -XX:+AlwaysPreTouch \ -Xlog:gc,gc+stats \ -XX:+UnlockExperimentalVMOptions \ -XX:+UseShenandoahGC \ -XX:ShenandoahMinFreeThreshold=25 \ -jar dacapo-9.12-MR1-bach.jar tradesoap -s large --no-pre-iteration-gc -9 >> $logfile 2>&1 [2.081s][info][gc] Using Shenandoah Using scaled threading model. 6 processors detected, 6 threads used to drive the workload, in a possible range of [1,512] ... [327.215s][info][gc] Trigger: Free (200M) is below minimum threshold (255M) [327.218s][info][gc] GC(445) Concurrent reset 814M->815M(1024M) 2.831ms [327.220s][info][gc] GC(445) Pause Init Mark (update refs) (process weakrefs) (unload classes) 1.187ms [327.459s][info][gc] GC(445) Concurrent marking (update refs) (process weakrefs) (unload classes) 815M->837M(1024M) 238.509ms [327.466s][info][gc] GC(445) Concurrent precleaning 837M->839M(1024M) 6.704ms [327.639s][info][gc] GC(445) Pause Final Mark (update refs) (process weakrefs) (unload classes) 172.116ms [327.680s][info][gc] GC(445) Concurrent roots processing 839M->867M(1024M) 40.903ms [327.681s][info][gc] GC(445) Concurrent cleanup 866M->592M(1024M) 0.722ms [327.751s][info][gc] GC(445) Concurrent evacuation 592M->633M(1024M) 69.871ms [327.752s][info][gc] GC(445) Pause Init Update Refs 0.174ms [327.972s][info][gc] GC(445) Concurrent update references 633M->710M(1024M) 219.948ms [327.974s][info][gc] GC(445) Pause Final Update Refs 0.658ms [327.974s][info][gc] GC(445) Concurrent cleanup 710M->503M(1024M) 0.139ms ... [411.436s][info][gc,stats] Total Pauses (G) = 14.56 s (a = 7549 us) (n = 1929) (lvls, us = 723, 1328, 2461, 3633, 173731) [411.436s][info][gc,stats] Total Pauses (N) = 12.26 s (a = 6356 us) (n = 1929) (lvls, us = 42, 189, 1367, 2402, 172170) [411.436s][info][gc,stats] Pause Init Mark (G) = 1.64 s (a = 2862 us) (n = 572) (lvls, us = 1836, 2324, 2559, 2930, 17977) [411.436s][info][gc,stats] Pause Init Mark (N) = 0.95 s (a = 1658 us) (n = 572) (lvls, us = 941, 1309, 1504, 1777, 10139) [411.436s][info][gc,stats] Make Parsable = 0.04 s (a = 69 us) (n = 572) (lvls, us = 8, 49, 64, 81, 416) [411.436s][info][gc,stats] Clear Liveness = 0.08 s (a = 146 us) (n = 572) (lvls, us = 63, 113, 127, 145, 4013) [411.436s][info][gc,stats] Scan Roots = 0.76 s (a = 1337 us) (n = 572) (lvls, us = 709, 1016, 1211, 1465, 5861) [411.436s][info][gc,stats] S: Thread Roots = 0.39 s (a = 686 us) (n = 572) (lvls, us = 438, 576, 652, 750, 3095) [411.436s][info][gc,stats] S: Universe Roots = 0.00 s (a = 4 us) (n = 572) (lvls, us = 2, 3, 4, 5, 50) [411.436s][info][gc,stats] S: JNI Roots = 0.00 s (a = 1 us) (n = 572) (lvls, us = 1, 1, 1, 1, 26) [411.436s][info][gc,stats] S: VM Global Roots = 0.00 s (a = 0 us) (n = 572) (lvls, us = 0, 0, 0, 0, 0) [411.436s][info][gc,stats] S: Synchronizer Roots = 0.00 s (a = 0 us) (n = 572) (lvls, us = 0, 0, 0, 0, 9) [411.436s][info][gc,stats] S: Management Roots = 0.00 s (a = 4 us) (n = 572) (lvls, us = 2, 3, 3, 4, 72) [411.436s][info][gc,stats] S: System Dict Roots = 0.01 s (a = 12 us) (n = 572) (lvls, us = 7, 10, 12, 14, 92) [411.436s][info][gc,stats] S: CLDG Roots = 0.08 s (a = 133 us) (n = 572) (lvls, us = 65, 100, 123, 152, 1273) [411.436s][info][gc,stats] S: JVMTI Roots = 0.00 s (a = 1 us) (n = 572) (lvls, us = 0, 1, 1, 1, 37) [411.436s][info][gc,stats] Resize TLABs = 0.02 s (a = 31 us) (n = 572) (lvls, us = 6, 22, 28, 34, 175) [411.436s][info][gc,stats] Pause Final Mark (G) = 11.74 s (a = 20527 us) (n = 572) (lvls, us = 2363, 3516, 4160, 7207, 173729) [411.436s][info][gc,stats] Pause Final Mark (N) = 11.03 s (a = 19281 us) (n = 572) (lvls, us = 1621, 2461, 3027, 5840, 172169) [411.436s][info][gc,stats] Update Roots = 0.27 s (a = 747 us) (n = 359) (lvls, us = 396, 594, 715, 838, 2452) [411.436s][info][gc,stats] U: Thread Roots = 0.18 s (a = 507 us) (n = 359) (lvls, us = 328, 426, 482, 561, 1744) [411.436s][info][gc,stats] Finish Queues = 0.47 s (a = 822 us) (n = 572) (lvls, us = 76, 170, 223, 295, 63181) [411.436s][info][gc,stats] Weak References = 9.07 s (a = 77487 us) (n = 117) (lvls, us = 154, 69531, 76562, 90039, 167547) [411.436s][info][gc,stats] Process = 9.06 s (a = 77477 us) (n = 117) (lvls, us = 42, 69531, 76562, 90039, 167539) [411.436s][info][gc,stats] System Purge = 0.22 s (a = 380 us) (n = 572) (lvls, us = 174, 283, 342, 418, 6337) [411.436s][info][gc,stats] Parallel Cleanup = 0.22 s (a = 378 us) (n = 572) (lvls, us = 174, 281, 340, 416, 6333) [411.436s][info][gc,stats] Complete Liveness = 0.06 s (a = 96 us) (n = 572) (lvls, us = 45, 71, 88, 104, 1024) [411.436s][info][gc,stats] Retire TLABs = 0.04 s (a = 74 us) (n = 572) (lvls, us = 12, 59, 67, 84, 328) [411.436s][info][gc,stats] Sync Pinned = 0.02 s (a = 33 us) (n = 572) (lvls, us = 11, 26, 28, 37, 508) [411.436s][info][gc,stats] Trash CSet = 0.01 s (a = 15 us) (n = 572) (lvls, us = 2, 3, 16, 23, 130) [411.436s][info][gc,stats] Prepare Evacuation = 0.19 s (a = 326 us) (n = 572) (lvls, us = 123, 266, 316, 363, 1330) [411.436s][info][gc,stats] Initial Evacuation = 0.63 s (a = 1107 us) (n = 572) (lvls, us = 600, 885, 1016, 1191, 6153) [411.436s][info][gc,stats] E: Thread Roots = 0.36 s (a = 625 us) (n = 572) (lvls, us = 332, 502, 588, 693, 3142) [411.436s][info][gc,stats] E: Universe Roots = 0.00 s (a = 2 us) (n = 572) (lvls, us = 1, 1, 2, 2, 34) [411.436s][info][gc,stats] E: JVMTI Weak Roots = 0.00 s (a = 0 us) (n = 572) (lvls, us = 0, 0, 0, 0, 3) [411.436s][info][gc,stats] E: JFR Weak Roots = 0.00 s (a = 1 us) (n = 572) (lvls, us = 0, 0, 0, 1, 3) [411.436s][info][gc,stats] E: Synchronizer Roots = 0.00 s (a = 0 us) (n = 572) (lvls, us = 0, 0, 0, 1, 15) [411.436s][info][gc,stats] E: Management Roots = 0.00 s (a = 3 us) (n = 572) (lvls, us = 1, 2, 2, 3, 19) [411.436s][info][gc,stats] E: System Dict Roots = 0.00 s (a = 8 us) (n = 572) (lvls, us = 5, 6, 7, 8, 32) [411.437s][info][gc,stats] E: JVMTI Roots = 0.00 s (a = 1 us) (n = 572) (lvls, us = 1, 1, 1, 1, 5) [411.437s][info][gc,stats] Pause Final Evac (G) = 0.43 s (a = 1198 us) (n = 359) (lvls, us = 785, 965, 1074, 1191, 7463) [411.437s][info][gc,stats] Pause Final Evac (N) = 0.03 s (a = 84 us) (n = 359) (lvls, us = 42, 74, 81, 90, 561) [411.437s][info][gc,stats] Retire GCLABs = 0.01 s (a = 38 us) (n = 359) (lvls, us = 17, 32, 37, 40, 403) [411.437s][info][gc,stats] Pause Init Update Refs (G) = 0.28 s (a = 1313 us) (n = 213) (lvls, us = 721, 1074, 1172, 1270, 6189) [411.437s][info][gc,stats] Pause Init Update Refs (N) = 0.04 s (a = 193 us) (n = 213) (lvls, us = 129, 158, 180, 207, 717) [411.437s][info][gc,stats] Retire GCLABs = 0.01 s (a = 37 us) (n = 213) (lvls, us = 5, 32, 36, 40, 126) [411.437s][info][gc,stats] Prepare = 0.02 s (a = 96 us) (n = 213) (lvls, us = 59, 74, 86, 107, 349) [411.437s][info][gc,stats] Pause Final Update Refs (G) = 0.47 s (a = 2200 us) (n = 213) (lvls, us = 1270, 1699, 1875, 2246, 18276) [411.437s][info][gc,stats] Pause Final Update Refs (N) = 0.21 s (a = 984 us) (n = 213) (lvls, us = 561, 766, 879, 1016, 3091) [411.437s][info][gc,stats] Update Roots = 0.16 s (a = 750 us) (n = 213) (lvls, us = 393, 564, 650, 816, 2411) [411.437s][info][gc,stats] UR: Thread Roots = 0.11 s (a = 497 us) (n = 213) (lvls, us = 150, 400, 463, 535, 1855) [411.437s][info][gc,stats] Sync Pinned = 0.02 s (a = 75 us) (n = 213) (lvls, us = 36, 60, 68, 82, 246) [411.437s][info][gc,stats] Trash CSet = 0.00 s (a = 17 us) (n = 213) (lvls, us = 4, 13, 16, 19, 75) [411.437s][info][gc,stats] Concurrent Reset = 1.87 s (a = 3277 us) (n = 572) (lvls, us = 412, 2910, 3184, 3438, 15269) [411.437s][info][gc,stats] Concurrent Marking = 122.57 s (a = 214281 us) (n = 572) (lvls, us = 26758, 140625, 212891, 271484, 423661) [411.437s][info][gc,stats] Concurrent Precleaning = 0.50 s (a = 4234 us) (n = 117) (lvls, us = 191, 3809, 4297, 4980, 7582) [411.437s][info][gc,stats] Concurrent Roots = 20.79 s (a = 36339 us) (n = 572) (lvls, us = 11328, 29883, 33984, 38477, 138885) [411.437s][info][gc,stats] Concurrent Evacuation = 22.09 s (a = 38627 us) (n = 572) (lvls, us = 637, 33203, 38477, 44336, 123103) [411.437s][info][gc,stats] Concurrent Update Refs = 37.84 s (a = 177660 us) (n = 213) (lvls, us = 24414, 132812, 181641, 212891, 631977) [411.437s][info][gc,stats] Concurrent Cleanup = 0.19 s (a = 247 us) (n = 785) (lvls, us = 79, 180, 219, 264, 1886) [411.437s][info][gc,stats] [411.437s][info][gc,stats] [411.437s][info][gc,stats] Under allocation pressure, concurrent cycles may cancel, and either continue cycle [411.437s][info][gc,stats] under stop-the-world pause or result in stop-the-world Full GC. Increase heap size, [411.437s][info][gc,stats] tune GC heuristics, set more aggressive pacing delay, or lower allocation rate [411.437s][info][gc,stats] to avoid Degenerated and Full GC cycles. [411.437s][info][gc,stats] [411.437s][info][gc,stats] 572 successful concurrent GCs [411.437s][info][gc,stats] 2 invoked explicitly [411.437s][info][gc,stats] 0 invoked implicitly [411.437s][info][gc,stats] [411.437s][info][gc,stats] 0 Degenerated GCs [411.437s][info][gc,stats] 0 caused by allocation failure [411.437s][info][gc,stats] 0 upgraded to Full GC [411.437s][info][gc,stats] [411.437s][info][gc,stats] 0 Full GCs [411.437s][info][gc,stats] 0 invoked explicitly [411.437s][info][gc,stats] 0 invoked implicitly [411.437s][info][gc,stats] 0 caused by allocation failure [411.437s][info][gc,stats] 0 upgraded from Degenerated GC [411.437s][info][gc,stats] [411.437s][info][gc,stats] [411.437s][info][gc,stats] ALLOCATION PACING: [411.437s][info][gc,stats] [411.437s][info][gc,stats] Max pacing delay is set for 10 ms. [411.437s][info][gc,stats] [411.437s][info][gc,stats] Higher delay would prevent application outpacing the GC, but it will hide the GC latencies [411.437s][info][gc,stats] from the STW pause times. Pacing affects the individual threads, and so it would also be [411.437s][info][gc,stats] invisible to the usual profiling tools, but would add up to end-to-end application latency. [411.437s][info][gc,stats] Raise max pacing delay with care. [411.437s][info][gc,stats] [411.437s][info][gc,stats] Actual pacing delays histogram: [411.437s][info][gc,stats] [411.437s][info][gc,stats] From - To Count Sum [411.437s][info][gc,stats] 1 ms - 2 ms: 117 58 ms [411.437s][info][gc,stats] 2 ms - 4 ms: 228 228 ms [411.437s][info][gc,stats] 4 ms - 8 ms: 993 1986 ms [411.437s][info][gc,stats] 8 ms - 16 ms: 50477 201908 ms [411.437s][info][gc,stats] 16 ms - 32 ms: 279 2232 ms [411.437s][info][gc,stats] 32 ms - 64 ms: 28 448 ms [411.437s][info][gc,stats] 64 ms - 128 ms: 35 1120 ms [411.437s][info][gc,stats] 128 ms - 256 ms: 2 128 ms [411.437s][info][gc,stats] Total: 52159 208108 ms ---------------------------------------------------------- 2. Example: class unloading disabled yields: Pause Final Mark (process weakrefs) 158.299ms ---------------------------------------------------------- java -Xms1G -Xmx1G -XX:+AlwaysPreTouch \ -Xlog:gc,gc+stats \ -XX:+UnlockExperimentalVMOptions \ -XX:+UseShenandoahGC \ -XX:ShenandoahMinFreeThreshold=25 \ -XX:-ClassUnloading \ -jar dacapo-9.12-MR1-bach.jar tradesoap -s large --no-pre-iteration-gc -9 >> $logfile 2>&1 [2.127s][info][gc] Using Shenandoah Using scaled threading model. 6 processors detected, 6 threads used to drive the workload, in a possible range of [1,512] ... [297.601s][info][gc] Trigger: Free (255M) is below minimum threshold (255M) [297.605s][info][gc] GC(450) Concurrent reset 716M->717M(1024M) 3.104ms [297.608s][info][gc] GC(450) Pause Init Mark (process weakrefs) 2.073ms [297.771s][info][gc] GC(450) Concurrent marking (process weakrefs) 718M->745M(1024M) 163.327ms [297.780s][info][gc] GC(450) Concurrent precleaning 745M->746M(1024M) 8.804ms [297.941s][info][gc] GC(450) Pause Final Mark (process weakrefs) 158.299ms [297.942s][info][gc] GC(450) Concurrent roots processing 747M->749M(1024M) 0.830ms [297.942s][info][gc] GC(450) Concurrent cleanup 749M->748M(1024M) 0.171ms [298.018s][info][gc] GC(450) Concurrent evacuation 748M->797M(1024M) 76.061ms [298.019s][info][gc] GC(450) Pause Init Update Refs 0.135ms [298.261s][info][gc] GC(450) Concurrent update references 797M->820M(1024M) 241.528ms [298.263s][info][gc] GC(450) Pause Final Update Refs 1.334ms [298.264s][info][gc] GC(450) Concurrent cleanup 820M->328M(1024M) 0.572ms ... [375.835s][info][gc,stats] Total Pauses (G) = 17.12 s (a = 8827 us) (n = 1939) (lvls, us = 535, 1270, 2695, 7305, 160888) [375.835s][info][gc,stats] Total Pauses (N) = 14.85 s (a = 7658 us) (n = 1939) (lvls, us = 40, 176, 1641, 6172, 158360) [375.835s][info][gc,stats] Pause Init Mark (G) = 1.76 s (a = 3054 us) (n = 577) (lvls, us = 2051, 2578, 2852, 3145, 19224) [375.835s][info][gc,stats] Pause Init Mark (N) = 1.11 s (a = 1916 us) (n = 577) (lvls, us = 1211, 1582, 1777, 2012, 14751) [375.835s][info][gc,stats] Make Parsable = 0.04 s (a = 70 us) (n = 577) (lvls, us = 23, 49, 59, 81, 424) [375.835s][info][gc,stats] Clear Liveness = 0.08 s (a = 135 us) (n = 577) (lvls, us = 78, 113, 127, 146, 354) [375.835s][info][gc,stats] Scan Roots = 0.93 s (a = 1610 us) (n = 577) (lvls, us = 969, 1309, 1484, 1719, 14015) [375.835s][info][gc,stats] S: Thread Roots = 0.39 s (a = 677 us) (n = 577) (lvls, us = 336, 572, 633, 732, 4006) [375.835s][info][gc,stats] S: Universe Roots = 0.00 s (a = 5 us) (n = 577) (lvls, us = 2, 4, 4, 5, 142) [375.835s][info][gc,stats] S: JNI Roots = 0.00 s (a = 1 us) (n = 577) (lvls, us = 1, 1, 1, 1, 7) [375.835s][info][gc,stats] S: VM Global Roots = 0.00 s (a = 0 us) (n = 577) (lvls, us = 0, 0, 0, 0, 1) [375.835s][info][gc,stats] S: Synchronizer Roots = 0.00 s (a = 0 us) (n = 577) (lvls, us = 0, 0, 0, 0, 51) [375.835s][info][gc,stats] S: Management Roots = 0.00 s (a = 7 us) (n = 577) (lvls, us = 2, 3, 3, 4, 1931) [375.835s][info][gc,stats] S: System Dict Roots = 0.01 s (a = 12 us) (n = 577) (lvls, us = 7, 10, 11, 13, 45) [375.835s][info][gc,stats] S: CLDG Roots = 0.26 s (a = 448 us) (n = 577) (lvls, us = 156, 344, 447, 506, 2152) [375.835s][info][gc,stats] S: JVMTI Roots = 0.00 s (a = 1 us) (n = 577) (lvls, us = 0, 1, 1, 1, 28) [375.835s][info][gc,stats] Resize TLABs = 0.02 s (a = 29 us) (n = 577) (lvls, us = 12, 22, 26, 34, 102) [375.835s][info][gc,stats] Pause Final Mark (G) = 14.16 s (a = 24547 us) (n = 577) (lvls, us = 4219, 7656, 8906, 11914, 160886) [375.835s][info][gc,stats] Pause Final Mark (N) = 13.49 s (a = 23375 us) (n = 577) (lvls, us = 3496, 6523, 7852, 10547, 158359) [375.836s][info][gc,stats] Update Roots = 0.25 s (a = 675 us) (n = 369) (lvls, us = 381, 543, 637, 760, 1911) [375.836s][info][gc,stats] U: Thread Roots = 0.17 s (a = 473 us) (n = 369) (lvls, us = 326, 389, 447, 535, 935) [375.836s][info][gc,stats] Finish Queues = 0.23 s (a = 407 us) (n = 577) (lvls, us = 89, 172, 225, 279, 12928) [375.836s][info][gc,stats] Weak References = 9.13 s (a = 77380 us) (n = 118) (lvls, us = 47, 70898, 78516, 85938, 141317) [375.836s][info][gc,stats] Process = 9.13 s (a = 77371 us) (n = 118) (lvls, us = 20, 70898, 78516, 85938, 141274) [375.836s][info][gc,stats] System Purge = 0.19 s (a = 323 us) (n = 577) (lvls, us = 156, 256, 311, 363, 1274) [375.836s][info][gc,stats] Parallel Cleanup = 0.19 s (a = 322 us) (n = 577) (lvls, us = 156, 254, 309, 363, 1248) [375.836s][info][gc,stats] Complete Liveness = 0.05 s (a = 88 us) (n = 577) (lvls, us = 41, 65, 79, 98, 966) [375.836s][info][gc,stats] Retire TLABs = 0.04 s (a = 72 us) (n = 577) (lvls, us = 23, 58, 66, 82, 346) [375.836s][info][gc,stats] Sync Pinned = 0.02 s (a = 32 us) (n = 577) (lvls, us = 10, 26, 28, 36, 155) [375.836s][info][gc,stats] Trash CSet = 0.01 s (a = 16 us) (n = 577) (lvls, us = 2, 3, 16, 23, 89) [375.836s][info][gc,stats] Prepare Evacuation = 0.19 s (a = 325 us) (n = 577) (lvls, us = 127, 268, 312, 365, 1076) [375.836s][info][gc,stats] Initial Evacuation = 3.31 s (a = 5739 us) (n = 577) (lvls, us = 2539, 4746, 5410, 6348, 16433) [375.836s][info][gc,stats] E: Thread Roots = 0.28 s (a = 489 us) (n = 577) (lvls, us = 297, 408, 459, 535, 3312) [375.836s][info][gc,stats] E: Code Cache Roots = 2.23 s (a = 3863 us) (n = 577) (lvls, us = 1152, 3477, 3711, 4102, 10724) [375.836s][info][gc,stats] E: Universe Roots = 0.00 s (a = 2 us) (n = 577) (lvls, us = 1, 1, 1, 2, 28) [375.836s][info][gc,stats] E: JVMTI Weak Roots = 0.00 s (a = 0 us) (n = 577) (lvls, us = 0, 0, 0, 0, 2) [375.836s][info][gc,stats] E: JFR Weak Roots = 0.00 s (a = 0 us) (n = 577) (lvls, us = 0, 0, 0, 0, 17) [375.836s][info][gc,stats] E: Synchronizer Roots = 0.00 s (a = 1 us) (n = 577) (lvls, us = 0, 0, 0, 0, 18) [375.836s][info][gc,stats] E: Management Roots = 0.00 s (a = 3 us) (n = 577) (lvls, us = 1, 2, 2, 3, 21) [375.836s][info][gc,stats] E: System Dict Roots = 0.00 s (a = 8 us) (n = 577) (lvls, us = 5, 6, 6, 7, 50) [375.836s][info][gc,stats] E: JVMTI Roots = 0.00 s (a = 1 us) (n = 577) (lvls, us = 1, 1, 1, 1, 18) [375.836s][info][gc,stats] Pause Final Evac (G) = 0.42 s (a = 1137 us) (n = 369) (lvls, us = 695, 967, 1035, 1172, 9748) [375.836s][info][gc,stats] Pause Final Evac (N) = 0.03 s (a = 82 us) (n = 369) (lvls, us = 40, 70, 76, 89, 209) [375.836s][info][gc,stats] Retire GCLABs = 0.01 s (a = 35 us) (n = 369) (lvls, us = 16, 29, 33, 37, 137) [375.836s][info][gc,stats] Pause Init Update Refs (G) = 0.34 s (a = 1628 us) (n = 208) (lvls, us = 490, 1035, 1133, 1250, 77501) [375.836s][info][gc,stats] Pause Init Update Refs (N) = 0.04 s (a = 178 us) (n = 208) (lvls, us = 84, 152, 166, 195, 742) [375.836s][info][gc,stats] Retire GCLABs = 0.01 s (a = 33 us) (n = 208) (lvls, us = 10, 28, 33, 36, 118) [375.836s][info][gc,stats] Prepare = 0.02 s (a = 88 us) (n = 208) (lvls, us = 30, 72, 79, 100, 391) [375.836s][info][gc,stats] Pause Final Update Refs (G) = 0.43 s (a = 2065 us) (n = 208) (lvls, us = 1250, 1680, 1836, 2031, 11709) [375.836s][info][gc,stats] Pause Final Update Refs (N) = 0.19 s (a = 892 us) (n = 208) (lvls, us = 604, 723, 822, 926, 3578) [375.836s][info][gc,stats] Update Roots = 0.14 s (a = 666 us) (n = 208) (lvls, us = 426, 525, 604, 709, 2734) [375.836s][info][gc,stats] UR: Thread Roots = 0.10 s (a = 466 us) (n = 208) (lvls, us = 312, 387, 434, 492, 1979) [375.836s][info][gc,stats] Sync Pinned = 0.02 s (a = 76 us) (n = 208) (lvls, us = 33, 60, 67, 79, 779) [375.836s][info][gc,stats] Trash CSet = 0.00 s (a = 17 us) (n = 208) (lvls, us = 2, 12, 14, 18, 104) [375.836s][info][gc,stats] Concurrent Reset = 1.75 s (a = 3031 us) (n = 577) (lvls, us = 416, 2715, 2949, 3164, 11012) [375.836s][info][gc,stats] Concurrent Marking = 124.01 s (a = 214925 us) (n = 577) (lvls, us = 39453, 142578, 210938, 275391, 486606) [375.836s][info][gc,stats] Concurrent Precleaning = 0.54 s (a = 4552 us) (n = 118) (lvls, us = 240, 4023, 4590, 5098, 8977) [375.836s][info][gc,stats] Concurrent Roots = 0.96 s (a = 1661 us) (n = 577) (lvls, us = 525, 871, 1055, 1855, 26504) [375.836s][info][gc,stats] Concurrent Evacuation = 22.68 s (a = 39314 us) (n = 577) (lvls, us = 127, 34375, 38477, 43945, 120119) [375.836s][info][gc,stats] Concurrent Update Refs = 34.41 s (a = 165418 us) (n = 208) (lvls, us = 21289, 125000, 169922, 199219, 296727) [375.836s][info][gc,stats] Concurrent Cleanup = 0.18 s (a = 227 us) (n = 785) (lvls, us = 73, 168, 203, 250, 1867) [375.836s][info][gc,stats] [375.836s][info][gc,stats] [375.836s][info][gc,stats] Under allocation pressure, concurrent cycles may cancel, and either continue cycle [375.836s][info][gc,stats] under stop-the-world pause or result in stop-the-world Full GC. Increase heap size, [375.836s][info][gc,stats] tune GC heuristics, set more aggressive pacing delay, or lower allocation rate [375.836s][info][gc,stats] to avoid Degenerated and Full GC cycles. [375.836s][info][gc,stats] [375.836s][info][gc,stats] 577 successful concurrent GCs [375.836s][info][gc,stats] 2 invoked explicitly [375.836s][info][gc,stats] 0 invoked implicitly [375.836s][info][gc,stats] [375.836s][info][gc,stats] 0 Degenerated GCs [375.836s][info][gc,stats] 0 caused by allocation failure [375.836s][info][gc,stats] 0 upgraded to Full GC [375.836s][info][gc,stats] [375.836s][info][gc,stats] 0 Full GCs [375.836s][info][gc,stats] 0 invoked explicitly [375.836s][info][gc,stats] 0 invoked implicitly [375.836s][info][gc,stats] 0 caused by allocation failure [375.836s][info][gc,stats] 0 upgraded from Degenerated GC [375.836s][info][gc,stats] [375.836s][info][gc,stats] [375.836s][info][gc,stats] ALLOCATION PACING: [375.836s][info][gc,stats] [375.836s][info][gc,stats] Max pacing delay is set for 10 ms. [375.836s][info][gc,stats] [375.836s][info][gc,stats] Higher delay would prevent application outpacing the GC, but it will hide the GC latencies [375.836s][info][gc,stats] from the STW pause times. Pacing affects the individual threads, and so it would also be [375.836s][info][gc,stats] invisible to the usual profiling tools, but would add up to end-to-end application latency. [375.836s][info][gc,stats] Raise max pacing delay with care. [375.836s][info][gc,stats] [375.836s][info][gc,stats] Actual pacing delays histogram: [375.836s][info][gc,stats] [375.836s][info][gc,stats] From - To Count Sum [375.836s][info][gc,stats] 1 ms - 2 ms: 257 128 ms [375.836s][info][gc,stats] 2 ms - 4 ms: 201 201 ms [375.836s][info][gc,stats] 4 ms - 8 ms: 364 728 ms [375.836s][info][gc,stats] 8 ms - 16 ms: 52317 209268 ms [375.837s][info][gc,stats] 16 ms - 32 ms: 908 7264 ms [375.837s][info][gc,stats] 32 ms - 64 ms: 13 208 ms [375.837s][info][gc,stats] 64 ms - 128 ms: 30 960 ms [375.837s][info][gc,stats] Total: 54090 218757 ms From shade at redhat.com Mon May 18 06:58:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 08:58:02 +0200 Subject: Long pause for processing weakrefs in DaCapo benchmark In-Reply-To: References: Message-ID: Hi, On 5/18/20 3:16 AM, raell at web.de wrote: > Is there a parameter that can be set or something else what can be done to reduce the > maximal pause time significantly? Class Unloading should not matter here. Weak reference processing is STW in Shenandoah due to implementation reasons (like in Parallel, G1, etc). Indeed, if you run the workload with -Xlog:ref*=debug, it would point to lots of finalizers: GC(20) Reference Processing: 50.2ms GC(20) Reconsider SoftReferences: 0.0ms GC(20) SoftRef (ms): skipped GC(20) Notify Soft/WeakReferences: 3.6ms GC(20) Balance queues: 2.1ms GC(20) SoftRef (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0, Workers: 3 GC(20) WeakRef (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0, Workers: 3 GC(20) FinalRef (ms): Min: 0.9, Avg: 1.0, Max: 1.3, Diff: 0.4, Sum: 3.0, Workers: 3 GC(20) Total (ms): Min: 1.3, Avg: 1.3, Max: 1.3, Diff: 0.0, Sum: 3.9, Workers: 3 GC(20) Notify and keep alive finalizable: 46.5ms GC(20) Balance queues: 0.0ms GC(20) FinalRef (ms): Min: 46.4, Avg: 46.4, Max: 46.4, Diff: 0.0, Sum: 139.2, Workers: 3 GC(20) Notify PhantomReferences: 0.1ms GC(20) PhantomRef (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0, Workers: 1 GC(20) SoftReference: GC(20) Discovered: 0 GC(20) Cleared: 0 GC(20) WeakReference: GC(20) Discovered: 0 GC(20) Cleared: 0 GC(20) FinalReference: GC(20) Discovered: 20807 GC(20) Cleared: 0 GC(20) PhantomReference: GC(20) Discovered: 32 GC(20) Cleared: 6 Finalizers are very unfortunate class of weak references: they appear dead during the marking time, and then reference processing has to make them, and all their descendants, alive again -- basically marking through the new parts of object graph. That takes a while, as we see here. It is, thankfully, quite rare in current applications, but sometimes it gets discovered on these special workloads. Our go-to answer to customers in these cases is, "Try not to use finalizers to begin with". Anyhow, there are two ways to mitigate the pauses: 1. Notice the log above says "Workers: 3". That is ergonomic decision to run the whole thing with 3 GC threads. You can override it with -XX:ParallelGCThreads=6, for example. This would balance the work across more threads, hopefully improving the wall clock time. 2. Having more frequent ref processing would make this processing more incremental. -XX:ShenandoahRefProcFrequency=1 should help here. > The benchmark has been runing on Debian using AdoptOpenJDK jdk-14+36. For evaluation purposes targeting 14u, I'd run with 14u nightlies, which include all improvements that would be released with 14.0.2 in July: https://builds.shipilev.net/openjdk-jdk14/ There are many interesting bugs/potholes fixed there. Notably, you should not see "Final Evac" pauses anymore. -- Thanks, -Aleksey From shade at redhat.com Mon May 18 12:21:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 14:21:33 +0200 Subject: sh/jdk8 windows builds failure Message-ID: In sh/jdk8, current Windows build fails: https://builds.shipilev.net/openjdk-shenandoah-jdk8/build-logs/build-windows-x86_64-fastdebug.log C:\buildbot\worker\build-shenandoah-jdk8-windows\build\hotspot\src\share\vm\gc_implementation\shenandoah\shenandoahRootProcessor.cpp(76) : error C3083: '{ctor}': the symbol to the left of a '::' must be a type ...because there is double qualification here: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c18245ae4adf#l7.64 Zhengyu, please fix that when reapplying the backports. -- Thanks, -Aleksey From shade at redhat.com Mon May 18 12:40:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 14:40:41 +0200 Subject: [8] RFR: 2020-05-18, Bulk backports to sh/jdk8 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200518/webrev.01/ This mostly backports the new logging to sh/jdk8: [backport] 8243494: Shenandoah: set counters once per cycle [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah [backport] 8239786: Shenandoah: print per-cycle statistics [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 [backport] 8243573: Shenandoah: rename GCParPhases and related code [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles [backport] 8244326: Shenandoah: global statistics should not accept bogus samples It took significant time to adjust the patches for 8u, so please review carefully. Testing: hotspot_gc_shenandoah {fastdebug,release}, eyeballing the gc logs -- Thanks, -Aleksey From shade at redhat.com Mon May 18 12:47:38 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 14:47:38 +0200 Subject: [15] RFR 8245124: Shenandoah: optimize code root evacuation/update during concurrent class unloading In-Reply-To: References: Message-ID: On 5/16/20 1:30 PM, Zhengyu Gu wrote: > Bug:https://bugs.openjdk.java.net/browse/JDK-8245124 > Webrev:http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.00/ *) Would you mind splitting out the ShenandoahNMethod::oops_do inlining? *) What if we specialize the branch from ShenandoahNMethod::heal_nmethod into shenandoahNMethod.inline.hpp, like: void ShenandoahNMethod::heal_nmethod(nmethod* nm) { ... if (heap->is_concurrent_mark_in_progress()) { ... } else if (heap->is_concurrent_weak_root_in_progress()) { heal_nmethod_weak_roots(); } else { ... } } ...and then use it in ShenandoahNMethodUnlinkClosure? That would make the code a bit more understandable? *) Odd dangling line here: 278 nm_data->oops_do(&oops_cl, true /*fix relocation*/); _bs->disarm(nm); -- Thanks, -Aleksey From shade at redhat.com Mon May 18 13:11:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 15:11:19 +0200 Subject: [8] RFR: Shenandoah: add root statistics for string dedup table/queues Message-ID: <02cdbeb7-d021-7073-7955-20b9bc462795@redhat.com> This is sh/jdk8-specific fix to add root statistics for string dedup table/queues. This would match what sh/jdk11 and jdk/jdk are doing. Webrev: https://cr.openjdk.java.net/~shade/shenandoah/8u-strdedup-root-stats/webrev.01/ Testing: hotspot_gc_shenandoah, eyeballing gc logs with string dedup enabled -- Thanks, -Aleksey From shade at redhat.com Mon May 18 16:51:59 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 18:51:59 +0200 Subject: [14] RFR 8242301: Shenandoah: Inline LRB runtime call Message-ID: <06b75cf9-e887-7677-02e4-f02ababb8f31@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8242301 https://hg.openjdk.java.net/jdk/jdk/rev/9a001fab4846 Some context mismatches in 14u, here's the webrev: https://cr.openjdk.java.net/~shade/8242301/webrev.14u.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Mon May 18 17:12:41 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 19:12:41 +0200 Subject: [14] RFR 8241984: Shenandoah: enhance GCTimer and JFR support Message-ID: <5cf064af-da77-43ca-8403-21cf4f5f1f3a@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8241984 https://hg.openjdk.java.net/jdk/jdk/rev/13e20575efe1 There are were some conflicts during the application, so I had to reapply some hunks myself. Also, there is no GCTraceTimeWrapper in 14u, only GCTraceTimeImplWrapper. 14u webrev: https://cr.openjdk.java.net/~shade/8241984/webrev.14u.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Mon May 18 17:27:45 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 19:27:45 +0200 Subject: [14] RFR 8242400: Shenandoah: Restore logging to pre-jdk8241984 format Message-ID: <23a05217-4016-11ab-723e-a87197dfe6e3@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8242400 https://hg.openjdk.java.net/jdk/jdk/rev/7992ff451fec Missing GCTraceConcTimeImpl -> GCTraceConcTime rename in 14u yields the conflict. Trivially resolved by changing it back. 14u webrev: https://cr.openjdk.java.net/~shade/8242400/webrev.14u.01/ Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah -- Thanks, -Aleksey From shade at redhat.com Mon May 18 17:35:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 19:35:25 +0200 Subject: [14] RFR 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end Message-ID: <022678b9-9e75-112b-1669-e534d5f971ae@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8243395 https://hg.openjdk.java.net/jdk/jdk/rev/28d9bc4b13b2 Context is a bit different, but patch is otherwise is very simple. 14u webrev: https://cr.openjdk.java.net/~shade/8243395/webrev.14u.01/ Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah -- Thanks, -Aleksey From zgu at redhat.com Mon May 18 17:37:18 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 May 2020 13:37:18 -0400 Subject: [14] RFR 8242400: Shenandoah: Restore logging to pre-jdk8241984 format In-Reply-To: <23a05217-4016-11ab-723e-a87197dfe6e3@redhat.com> References: <23a05217-4016-11ab-723e-a87197dfe6e3@redhat.com> Message-ID: Looks good. -Zhengyu On 5/18/20 1:27 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8242400 > https://hg.openjdk.java.net/jdk/jdk/rev/7992ff451fec > > Missing GCTraceConcTimeImpl -> GCTraceConcTime rename in 14u yields the conflict. Trivially resolved > by changing it back. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8242400/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah > From zgu at redhat.com Mon May 18 17:39:52 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 May 2020 13:39:52 -0400 Subject: [14] RFR 8241984: Shenandoah: enhance GCTimer and JFR support In-Reply-To: <5cf064af-da77-43ca-8403-21cf4f5f1f3a@redhat.com> References: <5cf064af-da77-43ca-8403-21cf4f5f1f3a@redhat.com> Message-ID: <3bfbff7d-1dde-c8b2-32d3-e1111d4e4a79@redhat.com> Looks good. -Zhengyu On 5/18/20 1:12 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8241984 > https://hg.openjdk.java.net/jdk/jdk/rev/13e20575efe1 > > There are were some conflicts during the application, so I had to reapply some hunks myself. Also, > there is no GCTraceTimeWrapper in 14u, only GCTraceTimeImplWrapper. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8241984/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From zgu at redhat.com Mon May 18 17:51:12 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 May 2020 13:51:12 -0400 Subject: [15] RFR 8245124: Shenandoah: optimize code root evacuation/update during concurrent class unloading In-Reply-To: References: Message-ID: <6e8e4ce3-3195-b91f-4032-ea51520056bc@redhat.com> Hi, On 5/18/20 8:47 AM, Aleksey Shipilev wrote: > On 5/16/20 1:30 PM, Zhengyu Gu wrote: >> Bug:https://bugs.openjdk.java.net/browse/JDK-8245124 >> Webrev:http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.00/ > > *) Would you mind splitting out the ShenandoahNMethod::oops_do inlining? > Any reason to split? this patch is not backportable to pre-jdk14. > *) What if we specialize the branch from ShenandoahNMethod::heal_nmethod into > shenandoahNMethod.inline.hpp, like: > > void ShenandoahNMethod::heal_nmethod(nmethod* nm) { > ... > > if (heap->is_concurrent_mark_in_progress()) { > ... > } else if (heap->is_concurrent_weak_root_in_progress()) { > heal_nmethod_weak_roots(); > } else { > ... > } > } > > ...and then use it in ShenandoahNMethodUnlinkClosure? That would make the code a bit more > understandable? > Updated: http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.01/index.html > *) Odd dangling line here: > > 278 nm_data->oops_do(&oops_cl, true /*fix relocation*/); _bs->disarm(nm); > Fixed. Thanks, -Zhengyu > From zgu at redhat.com Mon May 18 17:52:08 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 May 2020 13:52:08 -0400 Subject: [14] RFR 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end In-Reply-To: <022678b9-9e75-112b-1669-e534d5f971ae@redhat.com> References: <022678b9-9e75-112b-1669-e534d5f971ae@redhat.com> Message-ID: <318a9c2d-9788-d617-5b33-a9a5035364ff@redhat.com> Looks good. -Zhengyu On 5/18/20 1:35 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8243395 > https://hg.openjdk.java.net/jdk/jdk/rev/28d9bc4b13b2 > > Context is a bit different, but patch is otherwise is very simple. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8243395/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah > From shade at redhat.com Mon May 18 17:54:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 19:54:12 +0200 Subject: [15] RFR 8245124: Shenandoah: optimize code root evacuation/update during concurrent class unloading In-Reply-To: <6e8e4ce3-3195-b91f-4032-ea51520056bc@redhat.com> References: <6e8e4ce3-3195-b91f-4032-ea51520056bc@redhat.com> Message-ID: <54762a64-cdd7-8332-7a39-3bde1b2cfcf8@redhat.com> On 5/18/20 7:51 PM, Zhengyu Gu wrote: > On 5/18/20 8:47 AM, Aleksey Shipilev wrote: >> On 5/16/20 1:30 PM, Zhengyu Gu wrote: >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8245124 >>> Webrev:http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.00/ >> >> *) Would you mind splitting out the ShenandoahNMethod::oops_do inlining? >> > Any reason to split? this patch is not backportable to pre-jdk14. No reason, really. Thought it would be cleaner for backports. > Updated: http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.01/index.html Good. Any reason why ShenandoahEvacOOMScope is not inside heal_nmethod_metadata()? Is there any problem to call _bs->disarm(nm) when holding that scope? -- Thanks, -Aleksey From zgu at redhat.com Mon May 18 18:03:45 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 May 2020 14:03:45 -0400 Subject: [15] RFR 8245124: Shenandoah: optimize code root evacuation/update during concurrent class unloading In-Reply-To: <54762a64-cdd7-8332-7a39-3bde1b2cfcf8@redhat.com> References: <6e8e4ce3-3195-b91f-4032-ea51520056bc@redhat.com> <54762a64-cdd7-8332-7a39-3bde1b2cfcf8@redhat.com> Message-ID: <901e6de6-2fac-a938-4f3f-db0d3c6e59d9@redhat.com> >> Updated: http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.01/index.html > > Good. Any reason why ShenandoahEvacOOMScope is not inside heal_nmethod_metadata()? Is there any > problem to call _bs->disarm(nm) when holding that scope? This is something I want to get rid of, especially on code root unlinking path. Moving ShenandoahEvacOOMScope up is another noticeable improvement, unfortunately, unload_nmethod_caches() triggers barrier. -Zhengyu > From shade at redhat.com Mon May 18 18:07:55 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 May 2020 20:07:55 +0200 Subject: [15] RFR 8245124: Shenandoah: optimize code root evacuation/update during concurrent class unloading In-Reply-To: <901e6de6-2fac-a938-4f3f-db0d3c6e59d9@redhat.com> References: <6e8e4ce3-3195-b91f-4032-ea51520056bc@redhat.com> <54762a64-cdd7-8332-7a39-3bde1b2cfcf8@redhat.com> <901e6de6-2fac-a938-4f3f-db0d3c6e59d9@redhat.com> Message-ID: On 5/18/20 8:03 PM, Zhengyu Gu wrote: >>> Updated: http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.01/index.html >> >> Good. Any reason why ShenandoahEvacOOMScope is not inside heal_nmethod_metadata()? Is there any >> problem to call _bs->disarm(nm) when holding that scope? > This is something I want to get rid of, especially on code root > unlinking path. Moving ShenandoahEvacOOMScope up is another noticeable > improvement, unfortunately, unload_nmethod_caches() triggers barrier. Ah. So you want to batch entering/exiting the scope? Okay then. -- Thanks, -Aleksey From rkennke at redhat.com Mon May 18 18:12:42 2020 From: rkennke at redhat.com (rkennke at redhat.com) Date: Mon, 18 May 2020 20:12:42 +0200 Subject: [14] RFR 8242301: Shenandoah: Inline LRB runtime call In-Reply-To: <06b75cf9-e887-7677-02e4-f02ababb8f31@redhat.com> References: <06b75cf9-e887-7677-02e4-f02ababb8f31@redhat.com> Message-ID: <6c79151411ff2983d8d8bb51318a78005da6b1e2.camel@redhat.com> Looks good to me! Thanks, Roman On Mon, 2020-05-18 at 18:51 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8242301 > https://hg.openjdk.java.net/jdk/jdk/rev/9a001fab4846 > > Some context mismatches in 14u, here's the webrev: > https://cr.openjdk.java.net/~shade/8242301/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From zgu at redhat.com Mon May 18 18:24:23 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 May 2020 14:24:23 -0400 Subject: [15] RFR 8245124: Shenandoah: optimize code root evacuation/update during concurrent class unloading In-Reply-To: References: <6e8e4ce3-3195-b91f-4032-ea51520056bc@redhat.com> <54762a64-cdd7-8332-7a39-3bde1b2cfcf8@redhat.com> <901e6de6-2fac-a938-4f3f-db0d3c6e59d9@redhat.com> Message-ID: <54e226ee-db78-64bb-3f75-36116bdaf02b@redhat.com> On 5/18/20 2:07 PM, Aleksey Shipilev wrote: > On 5/18/20 8:03 PM, Zhengyu Gu wrote: >>>> Updated: http://cr.openjdk.java.net/~zgu/JDK-8245124/webrev.01/index.html >>> >>> Good. Any reason why ShenandoahEvacOOMScope is not inside heal_nmethod_metadata()? Is there any >>> problem to call _bs->disarm(nm) when holding that scope? >> This is something I want to get rid of, especially on code root >> unlinking path. Moving ShenandoahEvacOOMScope up is another noticeable >> improvement, unfortunately, unload_nmethod_caches() triggers barrier. > > Ah. So you want to batch entering/exiting the scope? Okay then. Yes. Thanks, -Zhengyu > From gnu.andrew at redhat.com Tue May 19 01:52:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 May 2020 02:52:22 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b02 Upstream Sync In-Reply-To: <9ddc978f-3863-1970-9829-7546c1d90dc2@redhat.com> References: <5964076f-9adf-8d73-0263-887ae1a7a165@redhat.com> <9ddc978f-3863-1970-9829-7546c1d90dc2@redhat.com> Message-ID: <915d9339-87f2-5834-0094-e42be31f2eaf@redhat.com> On 14/05/2020 06:59, Aleksey Shipilev wrote: > On 5/14/20 12:26 AM, Andrew Hughes wrote: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxws/merge.changeset > > Look trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jdk/merge.changeset > > Looks good. (Ok, this is a fun "" one). > Definitely. >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/hotspot/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/root/merge.changeset > > Look trivially 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 From shade at redhat.com Tue May 19 09:23:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 11:23:24 +0200 Subject: [8] RFR: Shenandoah: specialize String Table scans for better pause performance Message-ID: This is sh/jdk8 specific fix. String Table scans dominate some workloads, notably Cassandra. But they are also visible on simple hello world scenarios. The underlying reason is that parallel StringTable scans use a very small chunk size, so on decently-sized tables we hit the contended atomic very often. Larger chunk size is needed to improve performance. Since that chunk size is hard-coded and entrenched in the 8u upstream code, I chose to copy-paste the relevant method and specialize it for Shenandoah. 11u and later code handles it better with OopStorage and concurrent hash tables, so this specialization is only needed for 8u. 8u webrev: https://cr.openjdk.java.net/~shade/shenandoah/8u-stringtable-scan/webrev.01/ This yields the impressive improvements on Cassandra perf tests, see example GC cycles: === Baseline: Pause Init Mark (N) 3646 us Accumulate Stats 18 us Make Parsable 4 us Update Region States 86 us Scan Roots 3478 us S: 26681 us S: Thread Roots 1521 us, workers (us): 468, 392, 111, 122, 113, 106, 111, 98, S: Universe Roots 3 us, workers (us): 3, ---, ---, ---, ---, ---, ---, ---, S: JNI Handles Roots 3 us, workers (us): 3, ---, ---, ---, ---, ---, ---, ---, S: JNI Weak Roots 25 us, workers (us): ---, ---, ---, 25, ---, ---, ---, ---, S: String Table Roots 24644 us, workers (us): 2857, 2935, 3141, 3122, 3148, 3148, 3148, 3145, S: Synchronizer Roots 3 us, workers (us): 2, 0, 0, 0, 0, 0, 0, 0, S: Flat Profiler Roots 2 us, workers (us): ---, ---, 2, ---, ---, ---, ---, ---, S: Management Roots 2 us, workers (us): 2, ---, ---, ---, ---, ---, ---, ---, S: System Dict Roots 10 us, workers (us): ---, ---, 10, ---, ---, ---, ---, ---, S: CLDG Roots 458 us, workers (us): 12, 13, 75, 72, 74, 75, 65, 72, S: JVMTI Roots 10 us, workers (us): ---, 10, ---, ---, ---, ---, ---, ---, Resize TLABs 11 us === Patched: Pause Init Mark (N) 999 us Accumulate Stats 17 us Make Parsable 4 us Update Region States 92 us Scan Roots 824 us S: 5494 us S: Thread Roots 1584 us, workers (us): 121, 613, 114, 131, 301, 110, 102, 93, S: Universe Roots 2 us, workers (us): 2, ---, ---, ---, ---, ---, ---, ---, S: JNI Handles Roots 4 us, workers (us): ---, 4, ---, ---, ---, ---, ---, ---, S: JNI Weak Roots 20 us, workers (us): ---, ---, ---, ---, ---, 20, ---, ---, S: String Table Roots 3374 us, workers (us): 506, 81, 479, 487, 372, 482, 473, 494, S: Synchronizer Roots 4 us, workers (us): 0, 0, 3, 0, 0, 0, 0, 0, S: Flat Profiler Roots 5 us, workers (us): ---, 5, ---, ---, ---, ---, ---, ---, S: Management Roots 1 us, workers (us): 1, ---, ---, ---, ---, ---, ---, ---, S: System Dict Roots 10 us, workers (us): ---, ---, 10, ---, ---, ---, ---, ---, S: CLDG Roots 478 us, workers (us): 79, 12, 77, 69, 13, 75, 75, 78, S: JVMTI Roots 10 us, workers (us): 10, ---, ---, ---, ---, ---, ---, ---, Resize TLABs 10 us Testing: hotspot_gc_shenandoah, Cassandra benches, eyeballing gc logs -- Thanks, -Aleksey From rkennke at redhat.com Tue May 19 09:36:47 2020 From: rkennke at redhat.com (rkennke at redhat.com) Date: Tue, 19 May 2020 11:36:47 +0200 Subject: [8] RFR: Shenandoah: specialize String Table scans for better pause performance In-Reply-To: References: Message-ID: <59674d1f7055b03b33e408a1e9bb90e1edf742d7.camel@redhat.com> Looks good to me! Thanks, Roman > This is sh/jdk8 specific fix. String Table scans dominate some > workloads, notably Cassandra. But > they are also visible on simple hello world scenarios. The underlying > reason is that parallel > StringTable scans use a very small chunk size, so on decently-sized > tables we hit the contended > atomic very often. Larger chunk size is needed to improve > performance. > > Since that chunk size is hard-coded and entrenched in the 8u upstream > code, I chose to copy-paste > the relevant method and specialize it for Shenandoah. 11u and later > code handles it better with > OopStorage and concurrent hash tables, so this specialization is only > needed for 8u. > > 8u webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-stringtable-scan/webrev.01/ > > This yields the impressive improvements on Cassandra perf tests, see > example GC cycles: > > === Baseline: > > Pause Init Mark (N) 3646 us > Accumulate Stats 18 us > Make Parsable 4 us > Update Region States 86 us > Scan Roots 3478 us > S: 26681 us > S: Thread Roots 1521 us, workers (us): 468, 392, 111, > 122, 113, 106, 111, 98, > S: Universe Roots 3 us, workers (us): 3, ---, ---, > ---, ---, ---, ---, ---, > S: JNI Handles Roots 3 us, workers (us): 3, ---, ---, > ---, ---, ---, ---, ---, > S: JNI Weak Roots 25 us, workers (us): ---, ---, - > --, 25, ---, ---, ---, ---, > S: String Table Roots 24644 us, workers (us): 2857, 2935, > 3141, 3122, 3148, 3148, 3148, 3145, > S: Synchronizer Roots 3 us, workers > (us): 2, 0, 0, 0, 0, 0, 0, 0, > S: Flat Profiler Roots 2 us, workers (us): ---, ---, 2, > ---, ---, ---, ---, ---, > S: Management Roots 2 us, workers (us): 2, ---, ---, > ---, ---, ---, ---, ---, > S: System Dict Roots 10 us, workers (us): ---, ---, 10, > ---, ---, ---, ---, ---, > S: CLDG Roots 458 us, workers > (us): 12, 13, 75, 72, 74, 75, 65, 72, > S: JVMTI Roots 10 us, workers (us): ---, 10, ---, > ---, ---, ---, ---, ---, > Resize TLABs 11 us > > === Patched: > Pause Init Mark (N) 999 us > Accumulate Stats 17 us > Make Parsable 4 us > Update Region States 92 us > Scan Roots 824 us > S: 5494 us > S: Thread Roots 1584 us, workers (us): 121, 613, 114, > 131, 301, 110, 102, 93, > S: Universe Roots 2 us, workers (us): 2, ---, ---, > ---, ---, ---, ---, ---, > S: JNI Handles Roots 4 us, workers (us): ---, 4, ---, > ---, ---, ---, ---, ---, > S: JNI Weak Roots 20 us, workers (us): ---, ---, ---, > ---, ---, 20, ---, ---, > S: String Table Roots 3374 us, workers (us): 506, 81, 479, > 487, 372, 482, 473, 494, > S: Synchronizer Roots 4 us, workers > (us): 0, 0, 3, 0, 0, 0, 0, 0, > S: Flat Profiler Roots 5 us, workers (us): ---, 5, ---, > ---, ---, ---, ---, ---, > S: Management Roots 1 us, workers (us): 1, ---, ---, > ---, ---, ---, ---, ---, > S: System Dict Roots 10 us, workers (us): ---, ---, 10, > ---, ---, ---, ---, ---, > S: CLDG Roots 478 us, workers > (us): 79, 12, 77, 69, 13, 75, 75, 78, > S: JVMTI Roots 10 us, workers (us): 10, ---, ---, > ---, ---, ---, ---, ---, > Resize TLABs 10 us > > > Testing: hotspot_gc_shenandoah, Cassandra benches, eyeballing gc logs > From shade at redhat.com Tue May 19 11:09:13 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 13:09:13 +0200 Subject: [11] RFR: 2020-05-19, Bulk backports to sh/jdk11 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200519/webrev.01/ This backports C2 changes. 8244509 was applied by accepting the incoming code shape wholesale. 8244663 and 8244721 regression tests were verified to fail before and passing after. I skipped 8245083 (null-ptr stuff), because it was problematic before, and needs more time to soak. Changes: [backport] 8244663: Shenandoah: C2 assertion fails in Matcher::collect_null_checks [backport] 8244721: CTW: C2 (Shenandoah) compilation fails with "unexpected infinite loop graph [backport] 8244509: Shenandoah: refactor ShenandoahBarrierC2Support::test_* methods [backport] 8244667: Shenandoah: SBC2Support::test_gc_state takes loop for wrong control [backport] 8244510: Shenandoah: invert SHC2Support::is_in_cset condition Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with Shenandoah (in progress) -- Thanks, -Aleksey From zgu at redhat.com Tue May 19 11:34:37 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 May 2020 07:34:37 -0400 Subject: [8] RFR: Shenandoah: specialize String Table scans for better pause performance In-Reply-To: References: Message-ID: <9a9405bd-b329-1a7a-a6ad-d42adbbe6b34@redhat.com> 935 assert(UseShenandoahGC, "Only for Shenandoah"); 936 const int chunk_size = limit / (ParallelGCThreads * 10); 937 Maybe need to guard against minimum chunk_size? even through, it is unlikely, but possible chunk_size == 0. Otherwise, looks good. -Zhengyu On 5/19/20 5:23 AM, Aleksey Shipilev wrote: > This is sh/jdk8 specific fix. String Table scans dominate some workloads, notably Cassandra. But > they are also visible on simple hello world scenarios. The underlying reason is that parallel > StringTable scans use a very small chunk size, so on decently-sized tables we hit the contended > atomic very often. Larger chunk size is needed to improve performance. > > Since that chunk size is hard-coded and entrenched in the 8u upstream code, I chose to copy-paste > the relevant method and specialize it for Shenandoah. 11u and later code handles it better with > OopStorage and concurrent hash tables, so this specialization is only needed for 8u. > > 8u webrev: > https://cr.openjdk.java.net/~shade/shenandoah/8u-stringtable-scan/webrev.01/ > > This yields the impressive improvements on Cassandra perf tests, see example GC cycles: > > === Baseline: > > Pause Init Mark (N) 3646 us > Accumulate Stats 18 us > Make Parsable 4 us > Update Region States 86 us > Scan Roots 3478 us > S: 26681 us > S: Thread Roots 1521 us, workers (us): 468, 392, 111, 122, 113, 106, 111, 98, > S: Universe Roots 3 us, workers (us): 3, ---, ---, ---, ---, ---, ---, ---, > S: JNI Handles Roots 3 us, workers (us): 3, ---, ---, ---, ---, ---, ---, ---, > S: JNI Weak Roots 25 us, workers (us): ---, ---, ---, 25, ---, ---, ---, ---, > S: String Table Roots 24644 us, workers (us): 2857, 2935, 3141, 3122, 3148, 3148, 3148, 3145, > S: Synchronizer Roots 3 us, workers (us): 2, 0, 0, 0, 0, 0, 0, 0, > S: Flat Profiler Roots 2 us, workers (us): ---, ---, 2, ---, ---, ---, ---, ---, > S: Management Roots 2 us, workers (us): 2, ---, ---, ---, ---, ---, ---, ---, > S: System Dict Roots 10 us, workers (us): ---, ---, 10, ---, ---, ---, ---, ---, > S: CLDG Roots 458 us, workers (us): 12, 13, 75, 72, 74, 75, 65, 72, > S: JVMTI Roots 10 us, workers (us): ---, 10, ---, ---, ---, ---, ---, ---, > Resize TLABs 11 us > > === Patched: > Pause Init Mark (N) 999 us > Accumulate Stats 17 us > Make Parsable 4 us > Update Region States 92 us > Scan Roots 824 us > S: 5494 us > S: Thread Roots 1584 us, workers (us): 121, 613, 114, 131, 301, 110, 102, 93, > S: Universe Roots 2 us, workers (us): 2, ---, ---, ---, ---, ---, ---, ---, > S: JNI Handles Roots 4 us, workers (us): ---, 4, ---, ---, ---, ---, ---, ---, > S: JNI Weak Roots 20 us, workers (us): ---, ---, ---, ---, ---, 20, ---, ---, > S: String Table Roots 3374 us, workers (us): 506, 81, 479, 487, 372, 482, 473, 494, > S: Synchronizer Roots 4 us, workers (us): 0, 0, 3, 0, 0, 0, 0, 0, > S: Flat Profiler Roots 5 us, workers (us): ---, 5, ---, ---, ---, ---, ---, ---, > S: Management Roots 1 us, workers (us): 1, ---, ---, ---, ---, ---, ---, ---, > S: System Dict Roots 10 us, workers (us): ---, ---, 10, ---, ---, ---, ---, ---, > S: CLDG Roots 478 us, workers (us): 79, 12, 77, 69, 13, 75, 75, 78, > S: JVMTI Roots 10 us, workers (us): 10, ---, ---, ---, ---, ---, ---, ---, > Resize TLABs 10 us > > > Testing: hotspot_gc_shenandoah, Cassandra benches, eyeballing gc logs > From shade at redhat.com Tue May 19 11:43:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 13:43:06 +0200 Subject: [8] RFR: Shenandoah: specialize String Table scans for better pause performance In-Reply-To: <9a9405bd-b329-1a7a-a6ad-d42adbbe6b34@redhat.com> References: <9a9405bd-b329-1a7a-a6ad-d42adbbe6b34@redhat.com> Message-ID: <85f31902-7fd7-58ed-0861-10a65d0e892d@redhat.com> On 5/19/20 1:34 PM, Zhengyu Gu wrote: > 935 assert(UseShenandoahGC, "Only for Shenandoah"); > 936 const int chunk_size = limit / (ParallelGCThreads * 10); > 937 > > Maybe need to guard against minimum chunk_size? even through, it is > unlikely, but possible chunk_size == 0. Oh yeah. Let's do this: const int chunk_size = MAX2(ClaimChunkSize, limit / (ParallelGCThreads * 10)); -- Thanks, -Aleksey From rkennke at redhat.com Tue May 19 11:43:22 2020 From: rkennke at redhat.com (rkennke at redhat.com) Date: Tue, 19 May 2020 13:43:22 +0200 Subject: [8] RFR: 2020-05-18, Bulk backports to sh/jdk8 In-Reply-To: References: Message-ID: <894820d4a1c96205c2dfd7ce06aef7ad54f49532.camel@redhat.com> This looks good to me! Thanks, Roman On Mon, 2020-05-18 at 14:40 +0200, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200518/webrev.01/ > > This mostly backports the new logging to sh/jdk8: > [backport] 8243494: Shenandoah: set counters once per cycle > [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work > for Shenandoah > [backport] 8239786: Shenandoah: print per-cycle statistics > [backport] 8243848: Shenandoah: Windows build fails after JDK- > 8239786 > [backport] 8243573: Shenandoah: rename GCParPhases and related code > [backport] 8244180: Shenandoah: carry Phase to > ShWorkerTimingsTracker explicitly > [backport] 8244226: Shenandoah: per-cycle statistics contain worker > data from previous cycles > [backport] 8244326: Shenandoah: global statistics should not accept > bogus samples > > It took significant time to adjust the patches for 8u, so please > review carefully. > > Testing: hotspot_gc_shenandoah {fastdebug,release}, eyeballing the gc > logs > From zgu at redhat.com Tue May 19 11:45:48 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 May 2020 07:45:48 -0400 Subject: [8] RFR: Shenandoah: specialize String Table scans for better pause performance In-Reply-To: <85f31902-7fd7-58ed-0861-10a65d0e892d@redhat.com> References: <9a9405bd-b329-1a7a-a6ad-d42adbbe6b34@redhat.com> <85f31902-7fd7-58ed-0861-10a65d0e892d@redhat.com> Message-ID: On 5/19/20 7:43 AM, Aleksey Shipilev wrote: > On 5/19/20 1:34 PM, Zhengyu Gu wrote: >> 935 assert(UseShenandoahGC, "Only for Shenandoah"); >> 936 const int chunk_size = limit / (ParallelGCThreads * 10); >> 937 >> >> Maybe need to guard against minimum chunk_size? even through, it is >> unlikely, but possible chunk_size == 0. > > Oh yeah. Let's do this: > const int chunk_size = MAX2(ClaimChunkSize, limit / (ParallelGCThreads * 10)); > Looks good. -Zhengyu > From rkennke at redhat.com Tue May 19 11:51:02 2020 From: rkennke at redhat.com (rkennke at redhat.com) Date: Tue, 19 May 2020 13:51:02 +0200 Subject: [8] RFR: Shenandoah: add root statistics for string dedup table/queues In-Reply-To: <02cdbeb7-d021-7073-7955-20b9bc462795@redhat.com> References: <02cdbeb7-d021-7073-7955-20b9bc462795@redhat.com> Message-ID: Ok looks good! Thanks, Roman On Mon, 2020-05-18 at 15:11 +0200, Aleksey Shipilev wrote: > This is sh/jdk8-specific fix to add root statistics for string dedup > table/queues. This would match > what sh/jdk11 and jdk/jdk are doing. > > Webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-strdedup-root-stats/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs with string dedup > enabled > From zgu at redhat.com Tue May 19 11:51:32 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 May 2020 07:51:32 -0400 Subject: [8] RFR: Shenandoah: add root statistics for string dedup table/queues In-Reply-To: <02cdbeb7-d021-7073-7955-20b9bc462795@redhat.com> References: <02cdbeb7-d021-7073-7955-20b9bc462795@redhat.com> Message-ID: Good to me. -Zhengyu On 5/18/20 9:11 AM, Aleksey Shipilev wrote: > This is sh/jdk8-specific fix to add root statistics for string dedup table/queues. This would match > what sh/jdk11 and jdk/jdk are doing. > > Webrev: > https://cr.openjdk.java.net/~shade/shenandoah/8u-strdedup-root-stats/webrev.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs with string dedup enabled > From zgu at redhat.com Tue May 19 12:15:21 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 May 2020 08:15:21 -0400 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope Message-ID: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> Currently, Shenandoah does no support nesting evacuation OOM scope, that presents a several drawbacks: 1) Can not allow barriers on some/many GC paths, manifested by JDK-8237396 and JDK-8242216. Although, we fixed them in shared code, but sooner or later, the problem will likely pop up again. 2) We have to setup the scope closes to evacuation code and narrows the scope. Setting up and tearing down scope are expensive, while nesting is a lot cheaper. 3) Complicates code, have to deal with weather the call comes from GC or barrier. Supporting nesting scope is actually quite simple and cheap. We only need the top level scope to participate evacuation OOM protocol (enter and exit the protocol), while nesting scope simply push/pop nesting level. With nesting scope support, we can setup the scope early, e.g. once per-worker task. It shows very promising performance improvement for code roots processing during concurrent class unloading. Bug: https://bugs.openjdk.java.net/browse/JDK-8245240 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245240/webrev.00/index.html Test: hotspot_gc_shenandoah tier1 with Shenandoah Thanks, -Zhengyu From shade at redhat.com Tue May 19 12:24:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 14:24:02 +0200 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> Message-ID: <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> On 5/19/20 2:15 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8245240 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245240/webrev.00/index.html I haven't looked through the state machine in more detail, but just a few coding nits: *) Do we really want to merge both _nesting_level and _is_evac_oom in the same field? Why can't we do it in separate fields? If we do want them to share a byte, I think we have to assert that writes to that byte field only happen from the same thread. Otherwise word-tearing bites us. *) This is just "if (level != 0)", right? 88 // Not top level, just return 89 if (level > 1) { 90 return; 91 } -- Thanks, -Aleksey From zgu at redhat.com Tue May 19 12:32:50 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 May 2020 08:32:50 -0400 Subject: [8] RFR: 2020-05-18, Bulk backports to sh/jdk8 In-Reply-To: References: Message-ID: <10f2db74-6b29-3f63-bb2a-4c9d766d2cc0@redhat.com> Nit: 1) 130 void ShenandoahPhaseTimings::set_cycle_data(Phase phase, double time) { 131 #ifdef ASSERT 132 double d = _cycle_data[phase]; 133 assert(d == uninitialized(), err_msg("Should not be set yet: %s, current value: %lf", phase_name(phase), d)); 134 #endif 135 _cycle_data[phase] = time; 136 } 137 138 Double empty lines 2) 106 void ShenandoahStringDedup::parallel_oops_do(ShenandoahPhaseTimings::Phase phase, OopClosure* cl) { 107 _queues->parallel_oops_do(cl); 108 _table->parallel_oops_do(cl); 109 _thread->parallel_oops_do(cl); Timing for queue and table are added in a separate backport, but seems to miss for thread. It is a 8u specific. Otherwise, looks good. Thanks, -Zhengyu On 5/18/20 8:40 AM, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200518/webrev.01/ > > This mostly backports the new logging to sh/jdk8: > [backport] 8243494: Shenandoah: set counters once per cycle > [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah > [backport] 8239786: Shenandoah: print per-cycle statistics > [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 > [backport] 8243573: Shenandoah: rename GCParPhases and related code > [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly > [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles > [backport] 8244326: Shenandoah: global statistics should not accept bogus samples > > It took significant time to adjust the patches for 8u, so please review carefully. > > Testing: hotspot_gc_shenandoah {fastdebug,release}, eyeballing the gc logs > From zgu at redhat.com Tue May 19 12:35:56 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 May 2020 08:35:56 -0400 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> Message-ID: <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> On 5/19/20 8:24 AM, Aleksey Shipilev wrote: > On 5/19/20 2:15 PM, Zhengyu Gu wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245240 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245240/webrev.00/index.html > > I haven't looked through the state machine in more detail, but just a few coding nits: > > *) Do we really want to merge both _nesting_level and _is_evac_oom in the same field? Why can't we > do it in separate fields? If we do want them to share a byte, I think we have to assert that writes > to that byte field only happen from the same thread. Otherwise word-tearing bites us. I don't have a strong opinion, I refactored it out of current layout. But there is no chance for word tearing, since it is read/write by the same 'current' thread. > > *) This is just "if (level != 0)", right? > Yea. > 88 // Not top level, just return > 89 if (level > 1) { > 90 return; > 91 } > Thanks, -Zhengyu From shade at redhat.com Tue May 19 12:38:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 14:38:02 +0200 Subject: [8] RFR: 2020-05-18, Bulk backports to sh/jdk8 In-Reply-To: <10f2db74-6b29-3f63-bb2a-4c9d766d2cc0@redhat.com> References: <10f2db74-6b29-3f63-bb2a-4c9d766d2cc0@redhat.com> Message-ID: <2f7ec4aa-c955-54fe-558b-9e49427eb918@redhat.com> On 5/19/20 2:32 PM, Zhengyu Gu wrote: > Nit: > > 1) > 130 void ShenandoahPhaseTimings::set_cycle_data(Phase phase, double time) { > 131 #ifdef ASSERT > 132 double d = _cycle_data[phase]; > 133 assert(d == uninitialized(), err_msg("Should not be set yet: %s, > current value: %lf", phase_name(phase), d)); > 134 #endif > 135 _cycle_data[phase] = time; > 136 } > 137 > 138 > > Double empty lines Fixed. > 2) > 106 void > ShenandoahStringDedup::parallel_oops_do(ShenandoahPhaseTimings::Phase > phase, OopClosure* cl) { > 107 _queues->parallel_oops_do(cl); > 108 _table->parallel_oops_do(cl); > 109 _thread->parallel_oops_do(cl); > > > Timing for queue and table are added in a separate backport, but seems > to miss for thread. It is a 8u specific. Yeah. I'll go and amend this one: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2020-May/012219.html > Otherwise, looks good. Thanks, I'll push this one. -- Thanks, -Aleksey From shade at redhat.com Tue May 19 12:50:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 14:50:42 +0200 Subject: [8] RFR: Shenandoah: add root statistics for string dedup table/queues In-Reply-To: References: <02cdbeb7-d021-7073-7955-20b9bc462795@redhat.com> Message-ID: This one: https://cr.openjdk.java.net/~shade/shenandoah/8u-strdedup-root-stats/webrev.02/ ...also adds the 8u-specific strdedup-thread counter. Still passes hotspot_gc_shenandoah. -Aleksey On 5/19/20 1:51 PM, Zhengyu Gu wrote: > Good to me. > > -Zhengyu > > On 5/18/20 9:11 AM, Aleksey Shipilev wrote: >> This is sh/jdk8-specific fix to add root statistics for string dedup table/queues. This would match >> what sh/jdk11 and jdk/jdk are doing. >> >> Webrev: >> https://cr.openjdk.java.net/~shade/shenandoah/8u-strdedup-root-stats/webre From zgu at redhat.com Tue May 19 12:57:34 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 May 2020 08:57:34 -0400 Subject: [8] RFR: Shenandoah: add root statistics for string dedup table/queues In-Reply-To: References: <02cdbeb7-d021-7073-7955-20b9bc462795@redhat.com> Message-ID: <727660b9-2ac3-20fb-33a0-ef29f17531d8@redhat.com> Good to go. -Zhengyu On 5/19/20 8:50 AM, Aleksey Shipilev wrote: > This one: > https://cr.openjdk.java.net/~shade/shenandoah/8u-strdedup-root-stats/webrev.02/ > > ...also adds the 8u-specific strdedup-thread counter. > > Still passes hotspot_gc_shenandoah. > > -Aleksey > > On 5/19/20 1:51 PM, Zhengyu Gu wrote: >> Good to me. >> >> -Zhengyu >> >> On 5/18/20 9:11 AM, Aleksey Shipilev wrote: >>> This is sh/jdk8-specific fix to add root statistics for string dedup table/queues. This would match >>> what sh/jdk11 and jdk/jdk are doing. >>> >>> Webrev: >>> https://cr.openjdk.java.net/~shade/shenandoah/8u-strdedup-root-stats/webre > From raell at web.de Tue May 19 13:35:43 2020 From: raell at web.de (raell at web.de) Date: Tue, 19 May 2020 15:35:43 +0200 Subject: Long pause for processing weakrefs in DaCapo benchmark In-Reply-To: References: Message-ID: Hi?Aleksey, ? thank you very much for your help. By using your suggested adjustments? ParallelGCThreads=6 &?ShenandoahRefProcFrequency=1 the max pause? reduced for?about 50% and runtime improved by 20%.? ? Best regards? Ralph? ? ? From shade at redhat.com Tue May 19 14:46:17 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 16:46:17 +0200 Subject: [8] RFR: 2020-05-19, Bulk backports to sh/jdk8 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200519/webrev.01/ This backports a few easy leftovers, mostly file moves to sh/jdk8: [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Tue May 19 15:01:56 2020 From: rkennke at redhat.com (rkennke at redhat.com) Date: Tue, 19 May 2020 17:01:56 +0200 Subject: [8] RFR: 2020-05-19, Bulk backports to sh/jdk8 In-Reply-To: References: Message-ID: <6edc2fed925cd9656eaf1e26e59f91db8bfc9fac.camel@redhat.com> Looks good, thank you! Roman > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200519/webrev.01/ > > This backports a few easy leftovers, mostly file moves to sh/jdk8: > [backport] 8241062: Shenandoah: rich asserts trigger "empty > statement" inspection > [backport] 8244730: Shenandoah: > gc/shenandoah/options/TestHeuristicsUnlock.java should only verify > [backport] 8244732: Shenandoah: move heuristics code to > gc/shenandoah/heuristics > [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode > [backport] 8244739: Shenandoah: break superclass dependency on > ShenandoahNormalMode > [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to > ShenandoahSATBMode > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From zgu at redhat.com Tue May 19 15:53:32 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 19 May 2020 11:53:32 -0400 Subject: [sh/8u] backport 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Message-ID: <792ab716-547d-aaf7-1d64-c06eeb2055d5@redhat.com> Please review this backport. The patch is largely inline with original patch, but 8u does not have mark word refactoring, HeapWord casting and etc. One noticeable difference, is that, 8u does not process roots concurrently, so there is no chance for heap iteration to encounter dead oops. Bug: https://bugs.openjdk.java.net/browse/JDK-8237632 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632-8u/webev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Tue May 19 16:42:26 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 18:42:26 +0200 Subject: [sh/8u] backport 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR In-Reply-To: <792ab716-547d-aaf7-1d64-c06eeb2055d5@redhat.com> References: <792ab716-547d-aaf7-1d64-c06eeb2055d5@redhat.com> Message-ID: <9c999ea8-daee-363f-bc3f-37b8eeaec524@redhat.com> On 5/19/20 5:53 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8237632 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632-8u/webev.00/ Looks good! -- Thanks, -Aleksey From rkennke at redhat.com Tue May 19 17:05:28 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 19 May 2020 19:05:28 +0200 Subject: [11] RFR: 2020-05-19, Bulk backports to sh/jdk11 In-Reply-To: References: Message-ID: Ok! Thanks, Roman On Tue, 2020-05-19 at 13:09 +0200, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200519/webrev.01/ > > This backports C2 changes. 8244509 was applied by accepting the > incoming code shape wholesale. > 8244663 and 8244721 regression tests were verified to fail before and > passing after. I skipped > 8245083 (null-ptr stuff), because it was problematic before, and > needs more time to soak. > > Changes: > [backport] 8244663: Shenandoah: C2 assertion fails in > Matcher::collect_null_checks > [backport] 8244721: CTW: C2 (Shenandoah) compilation fails with > "unexpected infinite loop graph > [backport] 8244509: Shenandoah: refactor > ShenandoahBarrierC2Support::test_* methods > [backport] 8244667: Shenandoah: SBC2Support::test_gc_state takes > loop for wrong control > [backport] 8244510: Shenandoah: invert SHC2Support::is_in_cset > condition > > Testing: hotspot_gc_shenandoah {fastdebug,release}, tier{1,2} with > Shenandoah (in progress) > From zgu at redhat.com Tue May 19 17:27:46 2020 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 19 May 2020 17:27:46 +0000 Subject: hg: shenandoah/jdk8/hotspot: [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Message-ID: <202005191727.04JHRkuO017953@aojmv0008.oracle.com> Changeset: 6cb89922d316 Author: zgu Date: 2020-02-26 15:32 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/6cb89922d316 [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp From rkennke at redhat.com Tue May 19 19:38:12 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 19 May 2020 21:38:12 +0200 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> Message-ID: It looks correct and good to me. I don't have a strong opinion regarding packed fields or separate fields. Bitfield access seems slightly awkward (I had to look it up to see what it actually is), otoh, space is limited in TL, so... ? Roman > On 5/19/20 8:24 AM, Aleksey Shipilev wrote: > > On 5/19/20 2:15 PM, Zhengyu Gu wrote: > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245240 > > > Webrev: > > > http://cr.openjdk.java.net/~zgu/JDK-8245240/webrev.00/index.html > > > > I haven't looked through the state machine in more detail, but just > > a few coding nits: > > > > *) Do we really want to merge both _nesting_level and > > _is_evac_oom in the same field? Why can't we > > do it in separate fields? If we do want them to share a byte, I > > think we have to assert that writes > > to that byte field only happen from the same thread. Otherwise > > word-tearing bites us. > I don't have a strong opinion, I refactored it out of current > layout. > But there is no chance for word tearing, since it is read/write by > the > same 'current' thread. > > > *) This is just "if (level != 0)", right? > > > > Yea. > > > 88 // Not top level, just return > > 89 if (level > 1) { > > 90 return; > > 91 } > > > > Thanks, > > -Zhengyu > From shade at redhat.com Tue May 19 21:14:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 19 May 2020 23:14:03 +0200 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> Message-ID: <1c62b14b-2405-1707-49af-b8f681f7f9d0@redhat.com> On 5/19/20 9:38 PM, Roman Kennke wrote: > I don't have a strong opinion regarding packed fields or separate > fields. Bitfield access seems slightly awkward (I had to look it up to > see what it actually is), otoh, space is limited in TL, so... ? I would prefer separate fields to make the code clearer. Are we really down to squeezing in a new byte in TL? -- Thanks, -Aleksey From rkennke at redhat.com Tue May 19 21:23:06 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 19 May 2020 23:23:06 +0200 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: <1c62b14b-2405-1707-49af-b8f681f7f9d0@redhat.com> References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> <1c62b14b-2405-1707-49af-b8f681f7f9d0@redhat.com> Message-ID: <028aeceda642bbe811dca59cbc2303822eae22a7.camel@redhat.com> On Tue, 2020-05-19 at 23:14 +0200, Aleksey Shipilev wrote: > On 5/19/20 9:38 PM, Roman Kennke wrote: > > I don't have a strong opinion regarding packed fields or separate > > fields. Bitfield access seems slightly awkward (I had to look it up > > to > > see what it actually is), otoh, space is limited in TL, so... ? > > I would prefer separate fields to make the code clearer. Are we > really down to squeezing in a new > byte in TL? True. As long as it fits and doesn't exceed the current limit, I guess we're ok. I expect that it also means simpler generated machine code. Roman From shade at redhat.com Wed May 20 07:49:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 09:49:44 +0200 Subject: [8] RFR: Move barrier sets to their proper locations Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/8u-move-sbs/webrev.01/ It always bothers me with backports that barrier set files and shenandoahSupport is at inconvenient places in sh/jdk8. We are better move them to the location that match sh/jdk11 and jdk/jdk. Testing: Linux x86_64 builds {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Wed May 20 09:25:13 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 11:25:13 +0200 Subject: [11] RFC: Pick up 11.0.8+4 to sh/jdk11 Message-ID: Upstream had published 11.0.8+4, let's pick it up to sh/jdk11. Merge is trivial, I would tag it with shenandoah-jdk-11.0.8+4 right away. Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed May 20 09:41:50 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 20 May 2020 11:41:50 +0200 Subject: [11] RFC: Pick up 11.0.8+4 to sh/jdk11 In-Reply-To: References: Message-ID: <96a1fdc793996523de940c0b1fa4d981508f05ba.camel@redhat.com> Ok good! Thanks, Roman On Wed, 2020-05-20 at 11:25 +0200, Aleksey Shipilev wrote: > Upstream had published 11.0.8+4, let's pick it up to sh/jdk11. > > Merge is trivial, I would tag it with shenandoah-jdk-11.0.8+4 right > away. > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Wed May 20 10:31:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 12:31:27 +0200 Subject: RFR (S) 8244729: Shenandoah: remove resolve paths from SBSA::generate_shenandoah_lrb Message-ID: <186ae7c6-e381-e27e-e0e6-be37eecc7d5a@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8244729 After JDK-8232992, we don't need the resolve path in ShenandoahBarrierSetAssembler. The slowpath call to ShenandoahRuntime would fix the reference, and we would not have to resolve it once again. Webrev: https://cr.openjdk.java.net/~shade/8244729/webrev.01/ Testing: hotspot_gc_shenandoah {x86_64, aarch64} -- Thanks, -Aleksey From shade at redhat.com Wed May 20 12:58:35 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 14:58:35 +0200 Subject: RFR (XS) 8245461: Shenandoah: refine mode name()-s Message-ID: <3b35f9a3-aadd-39ec-97bb-fd3162b0507c@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8245461 Fixes a typo in SATB name(), and updates the IU mode to match. diff -r b620b11f83d7 src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp --- a/src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp Wed May 20 12:01:44 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp Wed May 20 14:57:05 2020 +0200 @@ -36,3 +36,3 @@ - virtual const char* name() { return "Incremental-Update"; } + virtual const char* name() { return "Incremental-Update (IU)"; } virtual bool is_diagnostic() { return false; } diff -r b620b11f83d7 src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.hpp --- a/src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.hpp Wed May 20 12:01:44 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.hpp Wed May 20 14:57:05 2020 +0200 @@ -35,3 +35,3 @@ virtual ShenandoahHeuristics* initialize_heuristics() const; - virtual const char* name() { return "Snapshot-At-TheBeginning"; } + virtual const char* name() { return "Snapshot-At-The-Beginning (SATB)"; } virtual bool is_diagnostic() { return false; } Testing: builds -- Thanks, -Aleksey From shade at redhat.com Wed May 20 13:02:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 15:02:01 +0200 Subject: RFR (XXS) 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments Message-ID: <1228f591-8e3d-ee58-cb1b-909da69afa3d@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8245463 Minor style problem: diff -r 819f7b4f0b08 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Wed May 20 14:56:58 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Wed May 20 15:01:15 2020 +0200 @@ -211,3 +211,3 @@ public: - ShenandoahPhaseTimings(uint _max_workers); + ShenandoahPhaseTimings(uint max_workers); Testing: builds -- Thanks, -Aleksey From zgu at redhat.com Wed May 20 13:10:38 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 May 2020 09:10:38 -0400 Subject: RFR (XXS) 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments In-Reply-To: <1228f591-8e3d-ee58-cb1b-909da69afa3d@redhat.com> References: <1228f591-8e3d-ee58-cb1b-909da69afa3d@redhat.com> Message-ID: <7fffaec8-227e-462d-6ca5-ce27535a5fb2@redhat.com> Looks good. -Zhengyu On 5/20/20 9:02 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245463 > > Minor style problem: > > diff -r 819f7b4f0b08 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Wed May 20 14:56:58 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Wed May 20 15:01:15 2020 +0200 > @@ -211,3 +211,3 @@ > public: > - ShenandoahPhaseTimings(uint _max_workers); > + ShenandoahPhaseTimings(uint max_workers); > > Testing: builds > From zgu at redhat.com Wed May 20 13:11:17 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 May 2020 09:11:17 -0400 Subject: RFR (XS) 8245461: Shenandoah: refine mode name()-s In-Reply-To: <3b35f9a3-aadd-39ec-97bb-fd3162b0507c@redhat.com> References: <3b35f9a3-aadd-39ec-97bb-fd3162b0507c@redhat.com> Message-ID: <914ebadb-6f3d-1c08-9dbd-916a99fa7628@redhat.com> Looks good. -Zhengyu On 5/20/20 8:58 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245461 > > Fixes a typo in SATB name(), and updates the IU mode to match. > > diff -r b620b11f83d7 src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp > --- a/src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp Wed May 20 12:01:44 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp Wed May 20 14:57:05 2020 +0200 > @@ -36,3 +36,3 @@ > > - virtual const char* name() { return "Incremental-Update"; } > + virtual const char* name() { return "Incremental-Update (IU)"; } > virtual bool is_diagnostic() { return false; } > diff -r b620b11f83d7 src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.hpp > --- a/src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.hpp Wed May 20 12:01:44 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.hpp Wed May 20 14:57:05 2020 +0200 > @@ -35,3 +35,3 @@ > virtual ShenandoahHeuristics* initialize_heuristics() const; > - virtual const char* name() { return "Snapshot-At-TheBeginning"; } > + virtual const char* name() { return "Snapshot-At-The-Beginning (SATB)"; } > virtual bool is_diagnostic() { return false; } > > Testing: builds > From zgu at redhat.com Wed May 20 15:08:15 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 May 2020 11:08:15 -0400 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: <028aeceda642bbe811dca59cbc2303822eae22a7.camel@redhat.com> References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> <1c62b14b-2405-1707-49af-b8f681f7f9d0@redhat.com> <028aeceda642bbe811dca59cbc2303822eae22a7.camel@redhat.com> Message-ID: Okay, then added assertion to make sure: http://cr.openjdk.java.net/~zgu/JDK-8245240/webrev.01/index.html Test: hotspot_gc_shenandoah (Linux/64 and 32) Built on Windows Thanks, -Zhengyu On 5/19/20 5:23 PM, Roman Kennke wrote: > On Tue, 2020-05-19 at 23:14 +0200, Aleksey Shipilev wrote: >> On 5/19/20 9:38 PM, Roman Kennke wrote: >>> I don't have a strong opinion regarding packed fields or separate >>> fields. Bitfield access seems slightly awkward (I had to look it up >>> to >>> see what it actually is), otoh, space is limited in TL, so... ? >> >> I would prefer separate fields to make the code clearer. Are we >> really down to squeezing in a new >> byte in TL? > > True. As long as it fits and doesn't exceed the current limit, I guess > we're ok. I expect that it also means simpler generated machine code. > > Roman > From shade at redhat.com Wed May 20 15:48:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 17:48:24 +0200 Subject: sh/jdk8 is FROZEN Message-ID: <4da8c3e9-b582-9407-9791-20aab3af869a@redhat.com> Hi, Please note sh/jdk8 is currently frozen to merge to integration repository, which we need to pick up cleanly. So, don't push anything until further notice. -- Thanks, -Aleksey From rkennke at redhat.com Wed May 20 15:56:03 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 20 May 2020 17:56:03 +0200 Subject: [8] RFR: Move barrier sets to their proper locations In-Reply-To: References: Message-ID: Ok. I was wondering the same for a while, but always assumed we'd need build-machinery changes to pick up stuff under subdirectories. Roman On Wed, 2020-05-20 at 09:49 +0200, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/8u-move-sbs/webrev.01/ > > It always bothers me with backports that barrier set files and > shenandoahSupport is at inconvenient > places in sh/jdk8. We are better move them to the location that match > sh/jdk11 and jdk/jdk. > > Testing: Linux x86_64 builds {fastdebug,release} > From zgu at redhat.com Wed May 20 16:15:47 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 May 2020 12:15:47 -0400 Subject: [15] RFR 8245288: Shenandoah: move up ShenandoahEvacOOM scope for code root processing during concurrent class unloading Message-ID: <43ab6215-23b2-1979-8b7e-8c62ce6eec52@redhat.com> Please review this small patch that moves up evacuation OOM scope. With JDK-8245240, we can avoid setting up/tearing down the scope for each nmethod, it turns out to be significant performance gain [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8245288 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245288/webrev.00/ Test: ? hotspot_gc_shenandoah Thanks, -Zhengyu [1] Baseline: Concurrent Class Unloading = 0.248 s (a = 4353 us) (n = 57) (lvls, us = 2910, 3887, 4199, 4707, 6253) ??Unlink Stale = 0.231 s (a = 4056 us) (n = 57) (lvls, us = 2598, 3574, 3906, 4414, 5969) ????System Dictionary = 0.001 s (a = 12 us) (n = 57) (lvls, us = 9, 11, 12, 12, 17) ????Weak Class Links = 0.000 s (a = 0 us) (n = 57) (lvls, us = 0, 0, 0, 0, 1) ????Code Roots = 0.230 s (a = 4043 us) (n = 57) (lvls, us = 2598, 3555, 3887, 4395, 5955) ??Rendezvous = 0.007 s (a = 119 us) (n = 57) (lvls, us = 72, 96, 115, 121, 204) ??Purge Unlinked = 0.008 s (a = 142 us) (n = 57) (lvls, us = 95, 125, 145, 150, 220) ????Code Roots = 0.008 s (a = 141 us) (n = 57) (lvls, us = 95, 123, 143, 148, 219) ????CLDG = 0.000 s (a = 0 us) (n = 57) (lvls, us = 0, 0, 0, 0, 1) ????Exception Caches = 0.000 s (a = 0 us) (n = 57) (lvls, us = 0, 0, 0, 0, 0) Patched: Concurrent Class Unloading = 0.146 s (a = 2567 us) (n = 57) (lvls, us = 1797, 2012, 2207, 3066, 4131) ??Unlink Stale = 0.129 s (a = 2263 us) (n = 57) (lvls, us = 1562, 1699, 1855, 2773, 3835) ????System Dictionary = 0.001 s (a = 12 us) (n = 57) (lvls, us = 10, 11, 12, 13, 24) ????Weak Class Links = 0.000 s (a = 0 us) (n = 57) (lvls, us = 0, 0, 0, 0, 1) ????Code Roots = 0.128 s (a = 2249 us) (n = 57) (lvls, us = 1543, 1699, 1836, 2754, 3822) ??Rendezvous = 0.007 s (a = 124 us) (n = 57) (lvls, us = 82, 107, 117, 119, 205) ??Purge Unlinked = 0.008 s (a = 143 us) (n = 57) (lvls, us = 97, 123, 145, 150, 209) ????Code Roots = 0.008 s (a = 142 us) (n = 57) (lvls, us = 97, 121, 143, 148, 208) ????CLDG = 0.000 s (a = 0 us) (n = 57) (lvls, us = 0, 0, 0, 0, 1) ????Exception Caches = 0.000 s (a = 0 us) (n = 57) (lvls, us = 0, 0, 0, 0, 0) From shade at redhat.com Wed May 20 16:17:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 18:17:51 +0200 Subject: RFR: 2020-05-20, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah Message-ID: <6aa656e7-437a-a9dc-7c00-a8833e8cef9d@redhat.com> https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200520/webrev.01/ This is a huge (sorry!) integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge. While the webrev is large, it contains lots of removals and refactorings in Shenandoah parts of the code. The actual changes to shared code are small and limited only to Shenandoah codepaths. There should be no changes to shared parts outside Shenandoah paths. Feel free to ignore the changes to Shenandoah code, we (Shenandoah devs) vouch for those parts :) I tagged the merge with aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20. 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 Fix slowdebug build after JDK-8230853 backport [backport] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata [backport] 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java [backport] 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier [backport] 8242130: Shenandoah: Simplify arraycopy-barrier dispatching [backport] 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name [backport] 8242054: Shenandoah: New incremental-update mode [backport] 8242271: Shenandoah: add test to verify GC mode unlock [backport] 8242273: Shenandoah: accept either SATB or IU barriers, but not both [backport] 8242301: Shenandoah: Inline LRB runtime call [backport] 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry [backport] 8242353: Shenandoah: micro-optimize region liveness handling [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end [backport] 8244551: Shenandoah: Fix racy update of update_watermark [backport] 8243463: Shenandoah: ditch total_pause counters [backport] 8243464: Shenandoah: print statistic counters in time order [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters [backport] 8243487: Shenandoah: make _num_phases illegal phase type [backport] 8244200: Shenandoah: build breakages after JDK-8241743 [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods [backport] 8221435: Shenandoah should not mark through weak roots [backport] 8221629: Shenandoah: Cleanup class unloading logic [backport] 8222992: Shenandoah: Pre-evacuate all roots [backport] 8223215: Shenandoah: Support verifying subset of roots [backport] 8223774: Shenandoah: Refactor ShenandoahRootProcessor and family [backport] 8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots [backport] 8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with --disable-precompiled-headers [backport] 8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable [backport] 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle [backport] 8225014: Separate ShenandoahRootScanner method for object_iterate [backport] 8225573: Shenandoah: Enhance ShenandoahVerifier to ensure roots to-space invariant [backport] 8225590: Shenandoah: Refactor ShenandoahClassLoaderDataRoots API [backport] 8226413: Shenandoah: Separate root scanner for SH::object_iterate() [backport] 8231198: Shenandoah: heap walking should visit all roots most of the time [backport] 8231244: Shenandoah: all-roots heap walking misses some weak roots [backport] 8243494: Shenandoah: set counters once per cycle [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah [backport] 8239786: Shenandoah: print per-cycle statistics [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 [backport] 8243573: Shenandoah: rename GCParPhases and related code [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles [backport] 8244326: Shenandoah: global statistics should not accept bogus samples Shenandoah: add root statistics for string dedup table/queues Shenandoah: specialize String Table scans for better pause performance [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 quite extensively -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed May 20 16:30:55 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 May 2020 17:30:55 +0100 Subject: [aarch64-port-dev ] RFR: 2020-05-20, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: <6aa656e7-437a-a9dc-7c00-a8833e8cef9d@redhat.com> References: <6aa656e7-437a-a9dc-7c00-a8833e8cef9d@redhat.com> Message-ID: On 20/05/2020 17:17, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200520/webrev.01/ > > This is a huge (sorry!) integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It > was generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge. > > While the webrev is large, it contains lots of removals and refactorings in Shenandoah parts of the > code. The actual changes to shared code are small and limited only to Shenandoah codepaths. There > should be no changes to shared parts outside Shenandoah paths. > > Feel free to ignore the changes to Shenandoah code, we (Shenandoah devs) vouch for those parts :) > > I tagged the merge with aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20. > > 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 > Fix slowdebug build after JDK-8230853 backport > [backport] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata > [backport] 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with > java/util/Collections/FindSubList.java > [backport] 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier > [backport] 8242130: Shenandoah: Simplify arraycopy-barrier dispatching > [backport] 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name > [backport] 8242054: Shenandoah: New incremental-update mode > [backport] 8242271: Shenandoah: add test to verify GC mode unlock > [backport] 8242273: Shenandoah: accept either SATB or IU barriers, but not both > [backport] 8242301: Shenandoah: Inline LRB runtime call > [backport] 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry > [backport] 8242353: Shenandoah: micro-optimize region liveness handling > [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache > [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread > [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically > [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle > [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data > [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs > [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end > [backport] 8244551: Shenandoah: Fix racy update of update_watermark > [backport] 8243463: Shenandoah: ditch total_pause counters > [backport] 8243464: Shenandoah: print statistic counters in time order > [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters > [backport] 8243487: Shenandoah: make _num_phases illegal phase type > [backport] 8244200: Shenandoah: build breakages after JDK-8241743 > [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods > [backport] 8221435: Shenandoah should not mark through weak roots > [backport] 8221629: Shenandoah: Cleanup class unloading logic > [backport] 8222992: Shenandoah: Pre-evacuate all roots > [backport] 8223215: Shenandoah: Support verifying subset of roots > [backport] 8223774: Shenandoah: Refactor ShenandoahRootProcessor and family > [backport] 8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots > [backport] 8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with > --disable-precompiled-headers > [backport] 8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable > [backport] 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current > GC cycle > [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update > cycle > [backport] 8225014: Separate ShenandoahRootScanner method for object_iterate > [backport] 8225573: Shenandoah: Enhance ShenandoahVerifier to ensure roots to-space invariant > [backport] 8225590: Shenandoah: Refactor ShenandoahClassLoaderDataRoots API > [backport] 8226413: Shenandoah: Separate root scanner for SH::object_iterate() > [backport] 8231198: Shenandoah: heap walking should visit all roots most of the time > [backport] 8231244: Shenandoah: all-roots heap walking misses some weak roots > [backport] 8243494: Shenandoah: set counters once per cycle > [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah > [backport] 8239786: Shenandoah: print per-cycle statistics > [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 > [backport] 8243573: Shenandoah: rename GCParPhases and related code > [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly > [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles > [backport] 8244326: Shenandoah: global statistics should not accept bogus samples > Shenandoah: add root statistics for string dedup table/queues > Shenandoah: specialize String Table scans for better pause performance > [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection > [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify > the heuristics > [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics > [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode > [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode > [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode > [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR > > Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 quite extensively > Shared code changes look ok and mostly restricted to Shenandoah-specific blocks AFAICS. Let's get this in, and then I'll test it once merged with the b03 work I have. 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 May 20 18:00:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 20:00:50 +0200 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> <1c62b14b-2405-1707-49af-b8f681f7f9d0@redhat.com> <028aeceda642bbe811dca59cbc2303822eae22a7.camel@redhat.com> Message-ID: On 5/20/20 5:08 PM, Zhengyu Gu wrote: > Okay, then added assertion to make sure: > http://cr.openjdk.java.net/~zgu/JDK-8245240/webrev.01/index.html In push_evac_oom_scope, don't we want to assert that (level != sizeof(uint8_t)*8) or something? The overflow there would be catastrophic, right? Actually, now that I think of it, wouldn't it be safer to make _oom_scope_nesting_level uint32_t, for example? That would be physically harder to overflow. Otherwise looks fine. -- Thanks, -Aleksey From shade at redhat.com Wed May 20 18:01:40 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 20:01:40 +0200 Subject: [15] RFR 8245288: Shenandoah: move up ShenandoahEvacOOM scope for code root processing during concurrent class unloading In-Reply-To: <43ab6215-23b2-1979-8b7e-8c62ce6eec52@redhat.com> References: <43ab6215-23b2-1979-8b7e-8c62ce6eec52@redhat.com> Message-ID: <2e5a4b30-1a61-7eb2-2313-bc719825f2e8@redhat.com> On 5/20/20 6:15 PM, Zhengyu Gu wrote: > Please review this small patch that moves up evacuation OOM scope. With > JDK-8245240, we can avoid setting up/tearing down the scope for each > nmethod, it turns out to be significant performance gain [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245288 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245288/webrev.00/ Looks good! -- Thanks, -Aleksey From shade at redhat.com Wed May 20 18:22:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 20:22:25 +0200 Subject: [aarch64-port-dev ] RFR: 2020-05-20, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: References: <6aa656e7-437a-a9dc-7c00-a8833e8cef9d@redhat.com> Message-ID: <5d54bc62-9ed4-f6e9-ae13-fc8aea7562c1@redhat.com> On 5/20/20 6:30 PM, Andrew Hughes wrote: > Let's get this in, and then I'll test it once merged with the b03 work I > have. Thank you, pushed. -- Thanks, -Aleksey From shade at redhat.com Wed May 20 18:26:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 20:26:42 +0200 Subject: RFC: Pick up aarch64-shenandoah-jdk8u262-b02 to sh/jdk8 Message-ID: <1bdedfb0-091a-5794-bb01-56ed3b0f731a@redhat.com> I have recently pushed the sh/jdk8 merge to integration forest: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008970.html Let's pick up everything from that merge (and all other directories) to sh/jdk8! There are no merges at all, because sh/jdk8 is clean downstream. Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Wed May 20 18:42:48 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 May 2020 14:42:48 -0400 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> <1c62b14b-2405-1707-49af-b8f681f7f9d0@redhat.com> <028aeceda642bbe811dca59cbc2303822eae22a7.camel@redhat.com> Message-ID: <350a9e3b-b050-f4bd-2b9b-177afdf07318@redhat.com> > > In push_evac_oom_scope, don't we want to assert that (level != sizeof(uint8_t)*8) or something? The > overflow there would be catastrophic, right? Sure. diff -r 25dc6d2ed231 src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp Wed May 20 13:28:17 2020 -0400 +++ b/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp Wed May 20 14:34:41 2020 -0400 @@ -159,6 +159,8 @@ // Push the scope one level deeper, return previous level static uint8_t push_evac_oom_scope(Thread* thread) { uint8_t level = evac_oom_scope_level(thread); + // UINT_MAX = 255 + assert(level < 254, "Overflow nesting level"); data(thread)->_oom_scope_nesting_level = level + 1; return level; } > > Actually, now that I think of it, wouldn't it be safer to make _oom_scope_nesting_level uint32_t, > for example? That would be physically harder to overflow.Actually, this patch helps to workaround barrier problem, which forces us to 'flat' the scope. Logically, we should have at most 2 levels. Top level is setup by workers and the second level is setup by barrier. Thanks, -Zhengyu > > Otherwise looks fine. > From shade at redhat.com Wed May 20 18:44:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 20:44:16 +0200 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: <350a9e3b-b050-f4bd-2b9b-177afdf07318@redhat.com> References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> <1c62b14b-2405-1707-49af-b8f681f7f9d0@redhat.com> <028aeceda642bbe811dca59cbc2303822eae22a7.camel@redhat.com> <350a9e3b-b050-f4bd-2b9b-177afdf07318@redhat.com> Message-ID: <8cda066e-c4e2-047d-f7d9-9af0474642a8@redhat.com> On 5/20/20 8:42 PM, Zhengyu Gu wrote: > diff -r 25dc6d2ed231 > src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp > Wed May 20 13:28:17 2020 -0400 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp > Wed May 20 14:34:41 2020 -0400 > @@ -159,6 +159,8 @@ > // Push the scope one level deeper, return previous level > static uint8_t push_evac_oom_scope(Thread* thread) { > uint8_t level = evac_oom_scope_level(thread); > + // UINT_MAX = 255 > + assert(level < 254, "Overflow nesting level"); > data(thread)->_oom_scope_nesting_level = level + 1; > return level; > } OK, fine. You can put the comment at the same line. -- Thanks, -Aleksey From zgu at redhat.com Wed May 20 19:56:19 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 May 2020 15:56:19 -0400 Subject: RFC: Pick up aarch64-shenandoah-jdk8u262-b02 to sh/jdk8 In-Reply-To: <1bdedfb0-091a-5794-bb01-56ed3b0f731a@redhat.com> References: <1bdedfb0-091a-5794-bb01-56ed3b0f731a@redhat.com> Message-ID: <552ba600-b2d0-a797-beb0-45b1bfccccb3@redhat.com> Good to me. -Zhengyu On 5/20/20 2:26 PM, Aleksey Shipilev wrote: > I have recently pushed the sh/jdk8 merge to integration forest: > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008970.html > > Let's pick up everything from that merge (and all other directories) to sh/jdk8! There are no merges > at all, because sh/jdk8 is clean downstream. > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Wed May 20 19:56:53 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 20 May 2020 19:56:53 +0000 Subject: hg: shenandoah/jdk8/jaxws: 13 new changesets Message-ID: <202005201956.04KJurF5024501@aojmv0008.oracle.com> Changeset: c772bca13e9f Author: andrew Date: 2020-04-14 19:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/c772bca13e9f Added tag jdk8u252-ga for changeset b012193ff452 ! .hgtags Changeset: 78b398816044 Author: andrew Date: 2020-03-03 13:22 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/78b398816044 Added tag jdk8u262-b00 for changeset fac54385ffea ! .hgtags Changeset: 587f4d12fccf Author: andrew Date: 2020-03-24 21:50 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/587f4d12fccf Merge ! .hgtags Changeset: 9502e19d094c Author: andrew Date: 2020-03-27 19:14 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/9502e19d094c Merge ! .hgtags Changeset: 6c74f9af22a0 Author: zgu Date: 2019-12-16 11:27 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/6c74f9af22a0 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Reviewed-by: serb ! THIRD_PARTY_README Changeset: c8d9ee347858 Author: andrew Date: 2020-04-24 03:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/c8d9ee347858 Merge ! .hgtags Changeset: ed881d547a80 Author: andrew Date: 2020-04-24 04:22 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/ed881d547a80 Added tag jdk8u262-b01 for changeset c8d9ee347858 ! .hgtags Changeset: 9faf0521fd87 Author: andrew Date: 2020-04-26 18:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/9faf0521fd87 Merge jdk8u262-b01 ! .hgtags ! THIRD_PARTY_README Changeset: 6b8e4be6b209 Author: andrew Date: 2020-04-26 19:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/6b8e4be6b209 Added tag aarch64-shenandoah-jdk8u262-b01 for changeset 9faf0521fd87 ! .hgtags Changeset: e924dd3a8068 Author: andrew Date: 2020-05-05 18:39 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/e924dd3a8068 Added tag jdk8u262-b02 for changeset ed881d547a80 ! .hgtags Changeset: 87211142e96a Author: andrew Date: 2020-05-11 00:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/87211142e96a Merge jdk8u262-b02 ! .hgtags Changeset: 3defd1827494 Author: andrew Date: 2020-05-11 00:17 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/3defd1827494 Added tag aarch64-shenandoah-jdk8u262-b02 for changeset 87211142e96a ! .hgtags Changeset: 66e34278c58b Author: shade Date: 2020-05-20 20:46 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/66e34278c58b Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset 3defd1827494 ! .hgtags From shade at redhat.com Wed May 20 19:56:52 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 20 May 2020 19:56:52 +0000 Subject: hg: shenandoah/jdk8/langtools: 13 new changesets Message-ID: <202005201956.04KJuqFR024474@aojmv0008.oracle.com> Changeset: 81b5a085b07c Author: andrew Date: 2020-04-14 19:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/81b5a085b07c Added tag jdk8u252-ga for changeset 01036da3155c ! .hgtags Changeset: 5a2cae3c40d0 Author: andrew Date: 2020-03-03 13:22 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/5a2cae3c40d0 Added tag jdk8u262-b00 for changeset 4d4304fcc0cc ! .hgtags Changeset: 8e574a114590 Author: andrew Date: 2020-03-24 21:50 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/8e574a114590 Merge ! .hgtags Changeset: 196e2b0867e4 Author: andrew Date: 2020-03-27 19:15 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/196e2b0867e4 Merge ! .hgtags Changeset: 32d4efcf2f32 Author: zgu Date: 2019-12-16 11:28 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/32d4efcf2f32 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Reviewed-by: serb ! THIRD_PARTY_README Changeset: 05fc0d4d4fbe Author: andrew Date: 2020-04-24 03:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/05fc0d4d4fbe Merge ! .hgtags Changeset: 910ec7999bd5 Author: andrew Date: 2020-04-24 04:22 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/910ec7999bd5 Added tag jdk8u262-b01 for changeset 05fc0d4d4fbe ! .hgtags Changeset: ec5a9cff3f55 Author: andrew Date: 2020-04-26 18:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/ec5a9cff3f55 Merge jdk8u262-b01 ! .hgtags ! THIRD_PARTY_README Changeset: ef1d808370e1 Author: andrew Date: 2020-04-26 19:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/ef1d808370e1 Added tag aarch64-shenandoah-jdk8u262-b01 for changeset ec5a9cff3f55 ! .hgtags Changeset: 4c272a5760ca Author: andrew Date: 2020-05-05 18:39 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/4c272a5760ca Added tag jdk8u262-b02 for changeset 910ec7999bd5 ! .hgtags Changeset: 9dea89bb6d52 Author: andrew Date: 2020-05-11 00:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/9dea89bb6d52 Merge jdk8u262-b02 ! .hgtags Changeset: 321ac97143cb Author: andrew Date: 2020-05-11 00:17 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/321ac97143cb Added tag aarch64-shenandoah-jdk8u262-b02 for changeset 9dea89bb6d52 ! .hgtags Changeset: e9c33bf08c2d Author: shade Date: 2020-05-20 20:46 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/e9c33bf08c2d Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset 321ac97143cb ! .hgtags From shade at redhat.com Wed May 20 19:56:59 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 20 May 2020 19:56:59 +0000 Subject: hg: shenandoah/jdk8/corba: 13 new changesets Message-ID: <202005201957.04KJv0FY024678@aojmv0008.oracle.com> Changeset: 3da649db678e Author: andrew Date: 2020-04-14 19:55 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/3da649db678e Added tag jdk8u252-ga for changeset 9340b3be1b47 ! .hgtags Changeset: a4541b2a58eb Author: andrew Date: 2020-03-03 13:22 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a4541b2a58eb Added tag jdk8u262-b00 for changeset b2c092b72c7c ! .hgtags Changeset: a0eab50cd355 Author: andrew Date: 2020-03-24 21:50 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a0eab50cd355 Merge ! .hgtags Changeset: a38e61c49b56 Author: andrew Date: 2020-03-27 19:14 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/a38e61c49b56 Merge ! .hgtags Changeset: dd72530c1255 Author: zgu Date: 2019-12-16 11:26 -0500 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/dd72530c1255 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Reviewed-by: serb ! THIRD_PARTY_README Changeset: 644b5985f127 Author: andrew Date: 2020-04-24 03:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/644b5985f127 Merge ! .hgtags Changeset: 43f43d941996 Author: andrew Date: 2020-04-24 04:22 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/43f43d941996 Added tag jdk8u262-b01 for changeset 644b5985f127 ! .hgtags Changeset: 46c9e5f5501a Author: andrew Date: 2020-04-26 18:58 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/46c9e5f5501a Merge jdk8u262-b01 ! .hgtags ! THIRD_PARTY_README Changeset: 2f4e96e75c0e Author: andrew Date: 2020-04-26 19:27 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2f4e96e75c0e Added tag aarch64-shenandoah-jdk8u262-b01 for changeset 46c9e5f5501a ! .hgtags Changeset: e86f6f0db020 Author: andrew Date: 2020-05-05 18:39 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e86f6f0db020 Added tag jdk8u262-b02 for changeset 43f43d941996 ! .hgtags Changeset: 23a644b6986b Author: andrew Date: 2020-05-11 00:07 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/23a644b6986b Merge jdk8u262-b02 ! .hgtags Changeset: 65b269fd33bc Author: andrew Date: 2020-05-11 00:17 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/65b269fd33bc Added tag aarch64-shenandoah-jdk8u262-b02 for changeset 23a644b6986b ! .hgtags Changeset: 3d225c7b9203 Author: shade Date: 2020-05-20 20:46 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/3d225c7b9203 Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset 65b269fd33bc ! .hgtags From rkennke at redhat.com Wed May 20 20:19:18 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 20 May 2020 22:19:18 +0200 Subject: [15] RFR 8245240: Shenandoah: support nesting evacuation OOM scope In-Reply-To: <8cda066e-c4e2-047d-f7d9-9af0474642a8@redhat.com> References: <60a3cc15-2b71-c5b9-87bd-9dcbbd248ace@redhat.com> <88fdf8eb-0ad6-a346-e1cc-ac27623c2860@redhat.com> <51480bb0-b485-4ea4-06fe-10b792bcc2be@redhat.com> <1c62b14b-2405-1707-49af-b8f681f7f9d0@redhat.com> <028aeceda642bbe811dca59cbc2303822eae22a7.camel@redhat.com> <350a9e3b-b050-f4bd-2b9b-177afdf07318@redhat.com> <8cda066e-c4e2-047d-f7d9-9af0474642a8@redhat.com> Message-ID: On Wed, 2020-05-20 at 20:44 +0200, Aleksey Shipilev wrote: > On 5/20/20 8:42 PM, Zhengyu Gu wrote: > > diff -r 25dc6d2ed231 > > src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp > > --- > > a/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp > > Wed May 20 13:28:17 2020 -0400 > > +++ > > b/src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp > > Wed May 20 14:34:41 2020 -0400 > > @@ -159,6 +159,8 @@ > > // Push the scope one level deeper, return previous level > > static uint8_t push_evac_oom_scope(Thread* thread) { > > uint8_t level = evac_oom_scope_level(thread); > > + // UINT_MAX = 255 > > + assert(level < 254, "Overflow nesting level"); > > data(thread)->_oom_scope_nesting_level = level + 1; > > return level; > > } > > OK, fine. You can put the comment at the same line. Looks good to me too. Roman From shade at redhat.com Thu May 21 10:10:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 12:10:28 +0200 Subject: RFR (S) 8245464: Shenandoah: allocate collection set bitmap at lower addresses Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8245464 See the rationale in the bug itself. Webrev: https://cr.openjdk.java.net/~shade/8245464/webrev.02/ Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Thu May 21 10:58:37 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 May 2020 12:58:37 +0200 Subject: RFR (S) 8245464: Shenandoah: allocate collection set bitmap at lower addresses In-Reply-To: References: Message-ID: <9076a4ebafd51ccb0abfaa173742da6ff7235ba5.camel@redhat.com> Looks good to me. Thanks, Roman On Thu, 2020-05-21 at 12:10 +0200, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245464 > > See the rationale in the bug itself. > > Webrev: > https://cr.openjdk.java.net/~shade/8245464/webrev.02/ > > Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah > From shade at redhat.com Thu May 21 11:00:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 13:00:05 +0200 Subject: RFR (S) 8245465: Shenandoah: test_in_cset can use more efficient encoding Message-ID: <8caaecf4-5660-491d-a03a-15a25c1ffefb@redhat.com> RFE: https://cr.openjdk.java.net/~shade/8245465/webrev.02/ See the rationale in the bug itself. Webrev: https://bugs.openjdk.java.net/browse/JDK-8245465 Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah, eyeballing asm, benchmarks -- Thanks, -Aleksey From rkennke at redhat.com Thu May 21 11:19:37 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 May 2020 13:19:37 +0200 Subject: RFR (S) 8245465: Shenandoah: test_in_cset can use more efficient encoding In-Reply-To: <8caaecf4-5660-491d-a03a-15a25c1ffefb@redhat.com> References: <8caaecf4-5660-491d-a03a-15a25c1ffefb@redhat.com> Message-ID: Maybe this warrants a note why you cast to X and back, instead of using the seemingly more obvious normal AddP addresing? Otherwise we may scratch our heads in a year or so why we did this? Roman > RFE: > https://cr.openjdk.java.net/~shade/8245465/webrev.02/ > > See the rationale in the bug itself. > > Webrev: > https://bugs.openjdk.java.net/browse/JDK-8245465 > > Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah, eyeballing > asm, benchmarks > From shade at redhat.com Thu May 21 11:24:54 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 13:24:54 +0200 Subject: RFR (S) 8245465: Shenandoah: test_in_cset can use more efficient encoding In-Reply-To: References: <8caaecf4-5660-491d-a03a-15a25c1ffefb@redhat.com> Message-ID: On 5/21/20 1:19 PM, Roman Kennke wrote: > Maybe this warrants a note why you cast to X and back, instead of using > the seemingly more obvious normal AddP addresing? Otherwise we may > scratch our heads in a year or so why we did this? Sure: https://cr.openjdk.java.net/~shade/8245465/webrev.03/ -- Thanks, -Aleksey From rkennke at redhat.com Thu May 21 11:38:38 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 May 2020 13:38:38 +0200 Subject: RFR (S) 8245465: Shenandoah: test_in_cset can use more efficient encoding In-Reply-To: References: <8caaecf4-5660-491d-a03a-15a25c1ffefb@redhat.com> Message-ID: OK! Thank you! Roman Aleksey Shipilev schrieb am Do., 21. Mai 2020, 13:25: > On 5/21/20 1:19 PM, Roman Kennke wrote: > > Maybe this warrants a note why you cast to X and back, instead of using > > the seemingly more obvious normal AddP addresing? Otherwise we may > > scratch our heads in a year or so why we did this? > > Sure: > https://cr.openjdk.java.net/~shade/8245465/webrev.03/ > > > -- > Thanks, > -Aleksey > > From shade at redhat.com Thu May 21 12:20:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 14:20:19 +0200 Subject: RFR (XS): Shenandoah: fix build failures after JDK-8244737 backport Message-ID: <9e7058d4-7db7-2ca8-f456-efff6b0a503b@redhat.com> Hi, Surprising to me, after integration to aarch64-port/jdk8u-shenandoah [1], CI suddenly started reporting failures in Linux minimal1 and Windows builds. This is the fix: https://cr.openjdk.java.net/~shade/shenandoah/8u-fix-8244737.patch This is 8u-speficic trouble. I would prefer to push it to aarch64-port/jdk8u-shenandoah/hotspot directly to unbreak the integration repository. I would then pull it to shenandoah/jdk8. Testing: windows-x86_64-server-fastdebug, linux-x86-minimal1-fastdebug builds -- Thanks, -Aleksey [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008970.html From rkennke at redhat.com Thu May 21 12:28:19 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 21 May 2020 14:28:19 +0200 Subject: RFR (S) 8244729: Shenandoah: remove resolve paths from SBSA::generate_shenandoah_lrb In-Reply-To: <186ae7c6-e381-e27e-e0e6-be37eecc7d5a@redhat.com> References: <186ae7c6-e381-e27e-e0e6-be37eecc7d5a@redhat.com> Message-ID: Yes, looks good! Thanks, Roman On Wed, 2020-05-20 at 12:31 +0200, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8244729 > > After JDK-8232992, we don't need the resolve path in > ShenandoahBarrierSetAssembler. The slowpath > call to ShenandoahRuntime would fix the reference, and we would not > have to resolve it once again. > > Webrev: > https://cr.openjdk.java.net/~shade/8244729/webrev.01/ > > Testing: hotspot_gc_shenandoah {x86_64, aarch64} > From gnu.andrew at redhat.com Thu May 21 16:24:14 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 21 May 2020 17:24:14 +0100 Subject: [aarch64-port-dev ] RFR (XS): Shenandoah: fix build failures after JDK-8244737 backport In-Reply-To: <9e7058d4-7db7-2ca8-f456-efff6b0a503b@redhat.com> References: <9e7058d4-7db7-2ca8-f456-efff6b0a503b@redhat.com> Message-ID: <00809f91-a8eb-45e6-12a1-913425cf1157@redhat.com> On 21/05/2020 13:20, Aleksey Shipilev wrote: > Hi, > > Surprising to me, after integration to aarch64-port/jdk8u-shenandoah [1], CI suddenly started > reporting failures in Linux minimal1 and Windows builds. This is the fix: > https://cr.openjdk.java.net/~shade/shenandoah/8u-fix-8244737.patch > > This is 8u-speficic trouble. I would prefer to push it to aarch64-port/jdk8u-shenandoah/hotspot > directly to unbreak the integration repository. I would then pull it to shenandoah/jdk8. > > Testing: windows-x86_64-server-fastdebug, linux-x86-minimal1-fastdebug builds > Ah, the old HotSpot build... Don't you just love it? Changes look good to me and I'm glad you caught it before I hit it. Push the fix and I'll include it in the tag of the merge with the b03 work. 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 Thu May 21 16:25:53 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 18:25:53 +0200 Subject: [aarch64-port-dev ] RFR (XS): Shenandoah: fix build failures after JDK-8244737 backport In-Reply-To: <00809f91-a8eb-45e6-12a1-913425cf1157@redhat.com> References: <9e7058d4-7db7-2ca8-f456-efff6b0a503b@redhat.com> <00809f91-a8eb-45e6-12a1-913425cf1157@redhat.com> Message-ID: <776a79f2-c464-ddf7-888c-02040c314cb2@redhat.com> On 5/21/20 6:24 PM, Andrew Hughes wrote: > Ah, the old HotSpot build... Don't you just love it? Yes, my everything explode with delight! > Changes look good to me and I'm glad you caught it before I hit it. Push > the fix and I'll include it in the tag of the merge with the b03 work. Thanks, pushed. -- -Aleksey From shade at redhat.com Thu May 21 18:15:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 20:15:05 +0200 Subject: [14] RFR (S) 8243464: Shenandoah: print statistic counters in time order Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8243464 https://hg.openjdk.java.net/jdk/jdk/rev/d115f09c2dbf This is a part of bulk backport of enhanced Shenandoah logging to 14u. The context is a bit different, because there is no split between weak/strong roots in 14u. 14u webrev: https://cr.openjdk.java.net/~shade/8243464/wevrev.14u.01/ Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Thu May 21 18:40:27 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 20:40:27 +0200 Subject: [14] RFR (S) 8243487: Shenandoah: make _num_phases illegal phase type Message-ID: <00dc5a31-dc8a-3b00-4c0d-2c5f5aea0478@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8243487 https://hg.openjdk.java.net/jdk/jdk/rev/93e446b95cfc This is a part of bulk backport of enhanced Shenandoah logging to 14u. The context is a bit different, because the root list in assert is a bit different. 14u webrev: https://cr.openjdk.java.net/~shade/8243487/webrev.14u.01/ Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Thu May 21 18:43:28 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 20:43:28 +0200 Subject: [14] RFR (S) 8243478: Shenandoah: avoid implicit worker_id = 0 Message-ID: <6b081631-befc-a995-b12c-d271a67b5e1a@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8243478 https://hg.openjdk.java.net/jdk/jdk/rev/cfc5b66e39c8 This is a part of bulk backport of enhanced Shenandoah logging to 14u. Again, the context is a bit different, because there is no split between weak/strong roots in 14u and closures are named differently. 14u webrev: https://cr.openjdk.java.net/~shade/8243478/webrev.14u.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Thu May 21 18:46:55 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 20:46:55 +0200 Subject: [14] RFR (S) 8243494: Shenandoah: set counters once per cycle Message-ID: <7637e596-fd77-8903-47f0-6daf079f61ac@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8243494 https://hg.openjdk.java.net/jdk/jdk/rev/d0e8e1d3d8e3 This is a part of bulk backport of enhanced Shenandoah logging to 14u. Again, the context is a bit different, because phase roots list is a bit different. 14u webrev: https://cr.openjdk.java.net/~shade/8243494/webrev.14u.01/ Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Thu May 21 18:51:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 20:51:44 +0200 Subject: [14] RFR (M) 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly In-Reply-To: References: Message-ID: <9101c279-2d3e-b0c1-a24f-0135fc48d2c3@redhat.com> +proper subject to underline it is about 14u. On 5/21/20 8:50 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8244180 > https://hg.openjdk.java.net/jdk/jdk/rev/649dbd90e0e9 > > This is a part of bulk backport of enhanced Shenandoah logging to 14u. Again, the context is a bit > different, because weak/strong roots split is not there. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8244180/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Thu May 21 18:50:43 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 20:50:43 +0200 Subject: RFR (M) 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8244180 https://hg.openjdk.java.net/jdk/jdk/rev/649dbd90e0e9 This is a part of bulk backport of enhanced Shenandoah logging to 14u. Again, the context is a bit different, because weak/strong roots split is not there. 14u webrev: https://cr.openjdk.java.net/~shade/8244180/webrev.14u.01/ Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Thu May 21 18:54:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 20:54:08 +0200 Subject: [14] RFR (S) 8243495: Shenandoah: print root statistics for concurrent weak/strong root phases Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8243495 https://hg.openjdk.java.net/jdk/jdk/rev/45e615754576 This is a part of bulk backport of enhanced Shenandoah logging to 14u. Again, the context is a bit different, because there is no weak/strong roots split. It is, however, good to have the logs for "Concurrent Roots" phase too. 14u webrev: https://cr.openjdk.java.net/~shade/8243495/webrev.14u.01/ Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From zgu at redhat.com Thu May 21 18:56:19 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 21 May 2020 14:56:19 -0400 Subject: [14] RFR (S) 8243478: Shenandoah: avoid implicit worker_id = 0 In-Reply-To: <6b081631-befc-a995-b12c-d271a67b5e1a@redhat.com> References: <6b081631-befc-a995-b12c-d271a67b5e1a@redhat.com> Message-ID: <30fc51db-8220-6605-99bf-8737560b3816@redhat.com> Looks good. -Zhengyu On 5/21/20 2:43 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8243478 > https://hg.openjdk.java.net/jdk/jdk/rev/cfc5b66e39c8 > > This is a part of bulk backport of enhanced Shenandoah logging to 14u. Again, the context is a bit > different, because there is no split between weak/strong roots in 14u and closures are named > differently. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8243478/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah > From shade at redhat.com Thu May 21 20:12:38 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 22:12:38 +0200 Subject: sh/jdk8 is unfrozen In-Reply-To: <4da8c3e9-b582-9407-9791-20aab3af869a@redhat.com> References: <4da8c3e9-b582-9407-9791-20aab3af869a@redhat.com> Message-ID: <593e7c61-d63e-34a6-65db-095775180237@redhat.com> On 5/20/20 5:48 PM, Aleksey Shipilev wrote: > Please note sh/jdk8 is currently frozen to merge to integration repository, which we need to pick up > cleanly. So, don't push anything until further notice. sh/jdk8 seems clean and open for business again. You can go ahead and prepare more backports for it. We better wait for Monday to get the absolute clear for backports to be pushed, but current version would serve as good base. -- Thanks, -Aleksey From shade at redhat.com Thu May 21 20:13:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 22:13:22 +0200 Subject: ANN: Shenandoah 8u262+ testing Message-ID: <6a0746d7-e9ab-5e09-3f03-bb07ea8d34b3@redhat.com> Hi, As 8u262 release tree is open and collects fixes that should culminate in release in mid July, Shenandoah 8u tree is also in similar position. It tracks upstream 8u262, and we pull from there more or less regularly. We have backported the bulk of the footprint, throughput, latency improvements done over the last several weeks, and there are more to come until we hit the release candidate. It also has a bunch of backported bugfixes. Please consider testing our nightlies in your canary deployments: https://wiki.openjdk.java.net/display/Shenandoah#Main-NightlyBuilds Note: this is not the release candidate, and it can be rough around the edges. Please deploy only where the VM bug/crash would not be catastrophic. The quicker we find bugs there, the more probable they would get fixed before the next release. -- Thanks, -Aleksey From rkennke at redhat.com Fri May 22 12:32:03 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 22 May 2020 14:32:03 +0200 Subject: [14] RFR (S) 8243494: Shenandoah: set counters once per cycle In-Reply-To: <7637e596-fd77-8903-47f0-6daf079f61ac@redhat.com> References: <7637e596-fd77-8903-47f0-6daf079f61ac@redhat.com> Message-ID: Good! Thanks, Roman On Thu, 2020-05-21 at 20:46 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8243494 > https://hg.openjdk.java.net/jdk/jdk/rev/d0e8e1d3d8e3 > > This is a part of bulk backport of enhanced Shenandoah logging to > 14u. Again, the context is a bit > different, because phase roots list is a bit different. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8243494/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From rkennke at redhat.com Fri May 22 12:32:35 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 22 May 2020 14:32:35 +0200 Subject: [14] RFR (M) 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly In-Reply-To: <9101c279-2d3e-b0c1-a24f-0135fc48d2c3@redhat.com> References: <9101c279-2d3e-b0c1-a24f-0135fc48d2c3@redhat.com> Message-ID: Good! Thanks, Roman On Thu, 2020-05-21 at 20:51 +0200, Aleksey Shipilev wrote: > +proper subject to underline it is about 14u. > > On 5/21/20 8:50 PM, Aleksey Shipilev wrote: > > Original RFE: > > https://bugs.openjdk.java.net/browse/JDK-8244180 > > https://hg.openjdk.java.net/jdk/jdk/rev/649dbd90e0e9 > > > > This is a part of bulk backport of enhanced Shenandoah logging to > > 14u. Again, the context is a bit > > different, because weak/strong roots split is not there. > > > > 14u webrev: > > https://cr.openjdk.java.net/~shade/8244180/webrev.14u.01/ > > > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > > From rkennke at redhat.com Fri May 22 12:32:55 2020 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 22 May 2020 14:32:55 +0200 Subject: [14] RFR (S) 8243495: Shenandoah: print root statistics for concurrent weak/strong root phases In-Reply-To: References: Message-ID: Ok! Thanks, Roman On Thu, 2020-05-21 at 20:54 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8243495 > https://hg.openjdk.java.net/jdk/jdk/rev/45e615754576 > > This is a part of bulk backport of enhanced Shenandoah logging to > 14u. Again, the context is a bit > different, because there is no weak/strong roots split. It is, > however, good to have the logs for > "Concurrent Roots" phase too. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8243495/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From rkennke at redhat.com Fri May 22 22:10:53 2020 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 23 May 2020 00:10:53 +0200 Subject: RFR: Backport SFX-related changes to sh/jdk8 Message-ID: <721fe2d20dfe61b4236f8f03f7aca8b2373f5553.camel@redhat.com> This backports changes related to self-fixing barriers to sh/jdk8: - 8202976: Add C1 lea patching support for x86: This is non-Shenandoah change from upstream JDK11. We need support for patching lea instructions, it has been added to upstream in jdk11 timeframe for ZGC. I modified it so that patching code is only generated when using Shenandoah. I also added a tiny bit of AARCH64 support, which came in upstream with the huge ZGC Support for AARCH64 change. - 8231087: Shenandoah: Self-fixing load reference barriers for C1/C2 This is the main change for C2 support. It also contains C1 support, but it wouldn't do anything in JDK8 until it also gets interpreter support, because in sh/jdk8, C1 LRB calls via interpreter LRB-asm (not via its own stub). The C1 parts are significantly different, please review carefully. - 8233021: Shenandoah: SBSC2::is_shenandoah_lrb_call should match all LRB shapes A trivial bug-fix that I took 1:1 to sh/jdk8 - 8232992: Shenandoah: Implement self-fixing interpreter LRB Interpreter support. Pretty much a rewrite, because 1. the barrier interface is very different and 2. it also needs to handle C1 calls and do some slightly different register shuffling Webrev: http://cr.openjdk.java.net/~rkennke/sfx-jdk8/webrev.01/ Testing: hotspot_gc_shenandoah (x86_64, aarch64), specjvm (with Xint, C1-only and C2) I can build x86_32, but cannot test it here because of a weird kernel bug. Can somebody with a stable x86_32 env please give it a try? Can I also please get a careful review? Thanks, Roman From rkennke at redhat.com Sat May 23 20:40:33 2020 From: rkennke at redhat.com (Roman Kennke) Date: Sat, 23 May 2020 22:40:33 +0200 Subject: RFR: Backport SFX-related changes to sh/jdk8 In-Reply-To: <721fe2d20dfe61b4236f8f03f7aca8b2373f5553.camel@redhat.com> References: <721fe2d20dfe61b4236f8f03f7aca8b2373f5553.camel@redhat.com> Message-ID: I totally forgot to include: 8238153 CTW: C2 (Shenandoah) compilation fails with "Unknown node in get_load_addr: CreateEx" A simple fix that applied cleanly. Also, I made a mistake when fixing x86_32 which broke x86_64, and I fixed it now: http://cr.openjdk.java.net/~rkennke/sfx-jdk8/webrev.03/ Re-run tests on x86_64. Please review webrev.03! Roman On Sat, 2020-05-23 at 00:10 +0200, Roman Kennke wrote: > This backports changes related to self-fixing barriers to sh/jdk8: > > - 8202976: Add C1 lea patching support for x86: > This is non-Shenandoah change from upstream JDK11. We need support > for > patching lea instructions, it has been added to upstream in jdk11 > timeframe for ZGC. I modified it so that patching code is only > generated when using Shenandoah. I also added a tiny bit of AARCH64 > support, which came in upstream with the huge ZGC Support for AARCH64 > change. > > - 8231087: Shenandoah: Self-fixing load reference barriers for C1/C2 > This is the main change for C2 support. It also contains C1 support, > but it wouldn't do anything in JDK8 until it also gets interpreter > support, because in sh/jdk8, C1 LRB calls via interpreter LRB-asm > (not > via its own stub). The C1 parts are significantly different, please > review carefully. > > - 8233021: Shenandoah: SBSC2::is_shenandoah_lrb_call should match all > LRB shapes > A trivial bug-fix that I took 1:1 to sh/jdk8 > > - 8232992: Shenandoah: Implement self-fixing interpreter LRB > Interpreter support. Pretty much a rewrite, because 1. the barrier > interface is very different and 2. it also needs to handle C1 calls > and > do some slightly different register shuffling > > > Webrev: > http://cr.openjdk.java.net/~rkennke/sfx-jdk8/webrev.01/ > > Testing: hotspot_gc_shenandoah (x86_64, aarch64), specjvm (with Xint, > C1-only and C2) > > I can build x86_32, but cannot test it here because of a weird kernel > bug. Can somebody with a stable x86_32 env please give it a try? > > Can I also please get a careful review? > > Thanks, > Roman > > From shade at redhat.com Mon May 25 07:30:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 09:30:58 +0200 Subject: [8] RFR: Parallel cleaning improvements Message-ID: In sh/jdk8, we have gc/shared/parallelCleaning.* that is only used by Shenandoah. We did this a long time ago thinking we would share this with G1. But, in later releases, we have decided to have gc/shenandoah/shenandoahParallelCleaning.* instead. sh/jdk11 has it, jdk/jdk has it. sh/jdk8 should do the same. Additionally, there are format specifier problems in ~ShenandoahStringSymbolTableUnlinkTask, which prevent it to build with C++11 enabled. Those are fixed in a separate changeset. Webrev: https://cr.openjdk.java.net/~shade/shenandoah/8u-parallel-cleaning/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From rwestrel at redhat.com Mon May 25 08:23:51 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 25 May 2020 10:23:51 +0200 Subject: RFR (S) 8245465: Shenandoah: test_in_cset can use more efficient encoding In-Reply-To: References: <8caaecf4-5660-491d-a03a-15a25c1ffefb@redhat.com> Message-ID: <87wo501kyw.fsf@redhat.com> > https://cr.openjdk.java.net/~shade/8245465/webrev.03/ Looks ok. Roland. From shade at redhat.com Mon May 25 08:34:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 10:34:46 +0200 Subject: RFR: Backport SFX-related changes to sh/jdk8 In-Reply-To: References: <721fe2d20dfe61b4236f8f03f7aca8b2373f5553.camel@redhat.com> Message-ID: <9ea31e6f-752f-167d-7d03-ef094393a167@redhat.com> On 5/23/20 10:40 PM, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/sfx-jdk8/webrev.03/ Cannot shake the feeling this is too risky for July release. *) We cannot pick up changesets like that: 8202976: Add C1 lea patching support for x86 ...because it messes up tracking. It should be something like: Cherry-pick 8202976: Add C1 lea patching support for x86 *) src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp: the new block should be guarded by UseShenandoahGC? *) src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: I thought we were discussing how to isolate this with UseShenandoahGC? It is odd to change upstream LIR_Assembler::leal. *) src/cpu/aarch64/vm/macroAssembler_aarch64.cpp It looks to me Shenandoah interception is cleaner with early return like this: void MacroAssembler::load_heap_oop(Register dst, Address src) { #if INCLUDE_ALL_GCS if (UseShenandoahGC) { ShenandoahBarrierSetAssembler::bsasm()->load_heap_oop(this, dst, src); return; } #endif if (UseCompressedOops) { ldrw(dst, src); decode_heap_oop(dst); } else { ldr(dst, src); } } *) src/cpu/x86/vm/macroAssembler_x86.cpp: same as above. Should just use early return. *) src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp: bad indent at L437, L468. 430 static void load_at(MacroAssembler* masm, Register dst, Address src) { 431 #ifdef _LP64 432 if (UseCompressedOops) { 433 __ movl(dst, src); 434 __ decode_heap_oop(dst); 435 } else 436 #endif 437 __ movptr(dst, src); 438 } 461 static void load_at_not_null(MacroAssembler* masm, Register dst, Address src) { 462 #ifdef _LP64 463 if (UseCompressedOops) { 464 __ movl(dst, src); 465 __ decode_heap_oop_not_null(dst); 466 } else 467 #endif 468 __ movptr(dst, src); 469 } *) src/share/vm/c1/c1_LIRGenerator.cpp, I do not understand this change: - if (is_volatile && !needs_patching) { - volatile_field_load(address, tmp, info); + if (is_volatile) { + volatile_field_load(addr->as_address_ptr(), tmp, info); } else { - LIR_PatchCode patch_code = needs_patching ? lir_patch_normal : lir_patch_none; - __ load(address, tmp, info, patch_code); + __ load(addr->as_address_ptr(), tmp, info); } if (is_volatile && os::is_MP()) { __ membar_acquire(); Does this mean we always call load(..., lir_patch_none), even when need_patching is true? *) src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp, this is odd: 108 #ifdef AARCH64 109 // AArch64 expects double-size register. 110 obj_reg = gen->new_pointer_register(); 111 #else 112 // x86 expects single-size register. 113 obj_reg = gen->new_register(T_OBJECT); 114 #endif I thought we eliminated it with: https://hg.openjdk.java.net/jdk/jdk/rev/732 -- Thanks, -Aleksey From rkennke at redhat.com Mon May 25 09:41:13 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 May 2020 11:41:13 +0200 Subject: [14] RFR (S) 8243487: Shenandoah: make _num_phases illegal phase type In-Reply-To: <00dc5a31-dc8a-3b00-4c0d-2c5f5aea0478@redhat.com> References: <00dc5a31-dc8a-3b00-4c0d-2c5f5aea0478@redhat.com> Message-ID: Looks good, thank you! Roman On Thu, 2020-05-21 at 20:40 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8243487 > https://hg.openjdk.java.net/jdk/jdk/rev/93e446b95cfc > > This is a part of bulk backport of enhanced Shenandoah logging to > 14u. The context is a bit > different, because the root list in assert is a bit different. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8243487/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From rkennke at redhat.com Mon May 25 09:40:21 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 May 2020 11:40:21 +0200 Subject: [14] RFR (S) 8243464: Shenandoah: print statistic counters in time order In-Reply-To: References: Message-ID: Looks good, thank you! Roman On Thu, 2020-05-21 at 20:15 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8243464 > https://hg.openjdk.java.net/jdk/jdk/rev/d115f09c2dbf > > This is a part of bulk backport of enhanced Shenandoah logging to > 14u. The context is a bit > different, because there is no split between weak/strong roots in > 14u. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8243464/wevrev.14u.01/ > > Testing: hotspot_gc_shenandoah, eyeballing gc logs > From shade at redhat.com Mon May 25 13:13:17 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 15:13:17 +0200 Subject: RFR (S) 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties Message-ID: <6968df00-1ff1-3790-7488-054a7b5a3ed7@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8245726 JDK-8245720 would print most stuff in Capitalized Form. GC modes already print in capitalized form. Heuristics should do the same. Additionally, lifting the is_diagnostic/is_experimental implementations right into header makes it a bit more clean, and matches what modes are doing. Webrev: https://cr.openjdk.java.net/~shade/8245726/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Mon May 25 13:34:53 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 May 2020 15:34:53 +0200 Subject: RFR: Backport SFX-related changes to sh/jdk8 In-Reply-To: <9ea31e6f-752f-167d-7d03-ef094393a167@redhat.com> References: <721fe2d20dfe61b4236f8f03f7aca8b2373f5553.camel@redhat.com> <9ea31e6f-752f-167d-7d03-ef094393a167@redhat.com> Message-ID: <757e3b2f803d80a11c1eac132a6db4c55a6899c1.camel@redhat.com> > > http://cr.openjdk.java.net/~rkennke/sfx-jdk8/webrev.03/ > Cannot shake the feeling this is too risky for July release. > Yeah, I've been thinking the same. Should I hold it back? > *) We cannot pick up changesets like that: > 8202976: Add C1 lea patching support for x86 > > ...because it messes up tracking. It should be something like: > Cherry-pick 8202976: Add C1 lea patching support for x86 > Right, fixed. > *) src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp: the new block > should be guarded by UseShenandoahGC? > Yes, fixed too. > *) src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: I thought we were > discussing how to isolate this with > UseShenandoahGC? It is odd to change upstream LIR_Assembler::leal. > Uff, how did that get lost? Anyhow, fixed. > *) src/cpu/aarch64/vm/macroAssembler_aarch64.cpp > > It looks to me Shenandoah interception is cleaner with early return > like this: > > void MacroAssembler::load_heap_oop(Register dst, Address src) > { > #if INCLUDE_ALL_GCS > if (UseShenandoahGC) { > ShenandoahBarrierSetAssembler::bsasm()->load_heap_oop(this, dst, > src); > return; > } > #endif > > if (UseCompressedOops) { > ldrw(dst, src); > decode_heap_oop(dst); > } else { > ldr(dst, src); > } > } > Right, fixed this too. > *) src/cpu/x86/vm/macroAssembler_x86.cpp: same as above. Should just > use early return. > Yup. > *) src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp: bad indent > at L437, L468. > > 430 static void load_at(MacroAssembler* masm, Register dst, Address > src) { > 431 #ifdef _LP64 > 432 if (UseCompressedOops) { > 433 __ movl(dst, src); > 434 __ decode_heap_oop(dst); > 435 } else > 436 #endif > 437 __ movptr(dst, src); > 438 } > > 461 static void load_at_not_null(MacroAssembler* masm, Register dst, > Address src) { > 462 #ifdef _LP64 > 463 if (UseCompressedOops) { > 464 __ movl(dst, src); > 465 __ decode_heap_oop_not_null(dst); > 466 } else > 467 #endif > 468 __ movptr(dst, src); > 469 } > This is pre-existing and not ours. > *) src/share/vm/c1/c1_LIRGenerator.cpp, I do not understand this > change: > > - if (is_volatile && !needs_patching) { > - volatile_field_load(address, tmp, info); > + if (is_volatile) { > + volatile_field_load(addr->as_address_ptr(), tmp, info); > } else { > - LIR_PatchCode patch_code = needs_patching ? lir_patch_normal : > lir_patch_none; > - __ load(address, tmp, info, patch_code); > + __ load(addr->as_address_ptr(), tmp, info); > } > if (is_volatile && os::is_MP()) { > __ membar_acquire(); > > Does this mean we always call load(..., lir_patch_none), even when > need_patching is true? > Yes, that is right. The reason is that the address is lea-ed in the LRB, and patching happens there. The subsequent load uses the pre- computed and patched address. This mirrors how it's done in 11+, there we are dropping the C1_NEEDS_PATCHING decorator after resolving the address into a register w/ patch. > *) > src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp, > this is odd: > > 108 #ifdef AARCH64 > 109 // AArch64 expects double-size register. > 110 obj_reg = gen->new_pointer_register(); > 111 #else > 112 // x86 expects single-size register. > 113 obj_reg = gen->new_register(T_OBJECT); > 114 #endif > > I thought we eliminated it with: > https://hg.openjdk.java.net/jdk/jdk/rev/732 > > I appended: JDK-8238851: Shenandoah: C1: Resolve into registers of correct type to my list of changes. http://cr.openjdk.java.net/~rkennke/sfx-jdk8/webrev.04/ Re-run hotspot_gc_shenandoah on x86_64, all good. Roman From rkennke at redhat.com Mon May 25 14:01:32 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 May 2020 16:01:32 +0200 Subject: RFR (S) 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties In-Reply-To: <6968df00-1ff1-3790-7488-054a7b5a3ed7@redhat.com> References: <6968df00-1ff1-3790-7488-054a7b5a3ed7@redhat.com> Message-ID: Looks good! Thanks, Roman On Mon, 2020-05-25 at 15:13 +0200, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245726 > > JDK-8245720 would print most stuff in Capitalized Form. GC modes > already print in capitalized form. > Heuristics should do the same. Additionally, lifting the > is_diagnostic/is_experimental > implementations right into header makes it a bit more clean, and > matches what modes are doing. > > Webrev: > https://cr.openjdk.java.net/~shade/8245726/webrev.01/ > > Testing: hotspot_gc_shenandoah > From gnu.andrew at redhat.com Mon May 25 15:48:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 May 2020 16:48:22 +0100 Subject: [RFR] [8u] 8u262-b03 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b03: - JDK-8037866: Replace the Fun class in tests with lambdas - JDK-8146612: C2: Precedence edges specification violated - JDK-8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format - JDK-8209413: AArch64: NPE in clhsdb jstack command - JDK-8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 - JDK-8217368: AArch64: C2 recursive stack locking optimisation not triggered - JDK-8229888: (zipfs) Updating an existing zip file does not preserve original permissions - JDK-8230597: Update GIFlib library to the 5.2.1 - JDK-8230769: BufImg_SetupICM add ReleasePrimitiveArrayCritical call in early return - JDK-8233880: Support compilers with multi-digit major version numbers - JDK-8237512: AArch64: aarch64TestHook leaks a BufferBlob - JDK-8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed - JDK-8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set - JDK-8243059: Build fails when --with-vendor-name contains a comma - JDK-8243474: [TESTBUG] removed three tests of 0 bytes - JDK-8244461: [JDK 8u] Build fails with glibc 2.32 - JDK-8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result Changes in aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20: - [backport] 8221435: Shenandoah should not mark through weak roots - [backport] 8221629: Shenandoah: Cleanup class unloading logic - [backport] 8222992: Shenandoah: Pre-evacuate all roots - [backport] 8223215: Shenandoah: Support verifying subset of roots - [backport] 8223774: Shenandoah: Refactor ShenandoahRootProcessor and family - [backport] 8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots - [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle - [backport] 8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with --disable-precompiled-headers - [backport] 8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable - [backport] 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle - [backport] 8225014: Separate ShenandoahRootScanner method for object_iterate - [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah - [backport] 8225573: Shenandoah: Enhance ShenandoahVerifier to ensure roots to-space invariant - [backport] 8225590: Shenandoah: Refactor ShenandoahClassLoaderDataRoots API - [backport] 8226413: Shenandoah: Separate root scanner for SH::object_iterate() - [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts - [backport] 8231198: Shenandoah: heap walking should visit all roots most of the time - [backport] 8231244: Shenandoah: all-roots heap walking misses some weak roots - [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR - [backport] 8239786: Shenandoah: print per-cycle statistics - [backport] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata - [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings - [backport] 8240749: Shenandoah: refactor ShenandoahUtils - [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker - [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles - [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation - [backport] 8240873: Shenandoah: Short-cut arraycopy barriers - [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks - [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 - [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection - [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently - [backport] 8241093: Shenandoah: editorial changes in flag descriptions - [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation - [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread - [backport] 8241351: Shenandoah: fragmentation metrics overhaul - [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" - [backport] 8241520: Shenandoah: simplify region sequence numbers handling - [backport] 8241534: Shenandoah: region status should include update watermark - [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] 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java - [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved - [backport] 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier - [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap - [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::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] 8241926: Shenandoah: only print heap changes for operations that directly affect it - [backport] 8241983: Shenandoah: simplify FreeSet logging - [backport] 8241985: Shenandoah: simplify collectable garbage 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] 8242054: Shenandoah: New incremental-update mode - [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag - [backport] 8242082: Shenandoah: Purge Traversal mode - [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters - [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged - [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses - [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared - [backport] 8242130: Shenandoah: Simplify arraycopy-barrier dispatching - [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] 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name - [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set - [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods - [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods - [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() - [backport] 8242271: Shenandoah: add test to verify GC mode unlock - [backport] 8242273: Shenandoah: accept either SATB or IU barriers, but not both - [backport] 8242301: Shenandoah: Inline LRB runtime call - [backport] 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry - [backport] 8242353: Shenandoah: micro-optimize region liveness handling - [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache - [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically - [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle - [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs - [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data - [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end - [backport] 8243463: Shenandoah: ditch total_pause counters - [backport] 8243464: Shenandoah: print statistic counters in time order - [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters - [backport] 8243487: Shenandoah: make _num_phases illegal phase type - [backport] 8243494: Shenandoah: set counters once per cycle - [backport] 8243573: Shenandoah: rename GCParPhases and related code - [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 - [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly - [backport] 8244200: Shenandoah: build breakages after JDK-8241743 - [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles - [backport] 8244326: Shenandoah: global statistics should not accept bogus samples - [backport] 8244551: Shenandoah: Fix racy update of update_watermark - [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics - [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics - [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode - [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode - [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode - Fix slowdebug build after JDK-8230853 backport - Shenandoah: add root statistics for string dedup table/queues - Shenandoah: fix build failures after JDK-8244737 backport - Shenandoah: specialize String Table scans for better pause performance Main issues of note: jdk8u262-b03 was initially merged on top of aarch64-shenandoah-jdk8u262-b02 and a number of recent AArch64 backports, without the recent Shenandoah merge. This is represented by the aarch64-shenandoah-jdk8u262-b03 tag. aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 represents the merging of these two streams of development, bringing together the b03 changes and the Shenandoah merge. It also includes "Shenandoah: fix build failures after JDK-8244737 backport", which was not part of the aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 tag. Stats below are for the b03 merge: diffstat for root b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- b/common/autoconf/generated-configure.sh | 6 +++--- b/common/autoconf/toolchain.m4 | 2 +- b/make/common/JavaCompilation.gmk | 2 +- 5 files changed, 7 insertions(+), 6 deletions(-) diffstat for corba b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for jaxp b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for jaxws b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for langtools b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for nashorn b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for jdk b/.hgtags | 1 b/THIRD_PARTY_README | 2 b/make/CompileLaunchers.gmk | 2 b/src/macosx/bin/java_md_macosx.c | 2 b/src/share/bin/java.c | 12 b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java | 33 + b/src/share/javavm/export/jvm.h | 8 b/src/share/native/sun/awt/giflib/dgif_lib.c | 14 b/src/share/native/sun/awt/giflib/gif_err.c | 2 b/src/share/native/sun/awt/giflib/gif_hash.h | 2 b/src/share/native/sun/awt/giflib/gif_lib.h | 15 b/src/share/native/sun/awt/giflib/gif_lib_private.h | 2 b/src/share/native/sun/awt/giflib/gifalloc.c | 2 b/src/share/native/sun/awt/giflib/openbsd-reallocarray.c | 13 b/src/share/native/sun/awt/image/BufImgSurfaceData.c | 3 b/src/solaris/bin/java_md_solinux.c | 21 b/src/solaris/bin/java_md_solinux.h | 12 b/src/solaris/native/java/net/PlainDatagramSocketImpl.c | 1 b/src/solaris/native/java/net/PlainSocketImpl.c | 1 b/test/demo/zipfs/ZipFSPermissionsTest.java | 234 ++++++++++ b/test/demo/zipfs/ZipFSPermissionsTest.policy | 5 b/test/java/lang/ProcessBuilder/Basic.java | 200 +++----- b/test/java/nio/charset/StandardCharsets/Standard.java | 9 b/test/java/util/Collection/BiggernYours.java | 9 b/test/java/util/Collection/IteratorAtEnd.java | 18 b/test/java/util/Collection/MOAT.java | 121 ++--- b/test/java/util/Collections/AsLifoQueue.java | 10 b/test/java/util/NavigableMap/LockStep.java | 58 +- b/test/java/util/PriorityQueue/ForgetMeNot.java | 10 b/test/java/util/concurrent/BlockingQueue/Interrupt.java | 40 - b/test/java/util/concurrent/CyclicBarrier/Basic.java | 10 b/test/java/util/concurrent/Executors/Throws.java | 54 +- b/test/java/util/concurrent/FutureTask/Customized.java | 19 b/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java | 6 b/test/java/util/concurrent/ThreadPoolExecutor/ShutdownNowExecuteRace.java | 9 b/test/sun/nio/cs/FindOneCharEncoderBugs.java | 9 36 files changed, 573 insertions(+), 396 deletions(-) diffstat for hotspot b/.hgtags | 1 b/THIRD_PARTY_README | 2 b/src/share/vm/opto/gcm.cpp | 2 b/src/share/vm/opto/lcm.cpp | 9 +- b/src/share/vm/opto/node.cpp | 43 +++++----- b/src/share/vm/opto/node.hpp | 39 ++++++++- b/src/share/vm/prims/jvm.h | 8 - b/src/share/vm/runtime/java.hpp | 6 - b/src/share/vm/runtime/vm_version.cpp | 2 b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java | 7 - 10 files changed, 82 insertions(+), 37 deletions(-) Both tags have been 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 Mon May 25 19:06:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 21:06:10 +0200 Subject: RFR (S) 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8245754 ShenandoahAlwaysPreTouch flag dates back to the times when ShenandoahHeap used VirtualSpace for reserving/committing heap. To workaround single-threaded pretouch code in VirtualSpace, a new flag was needed: https://mail.openjdk.java.net/pipermail/shenandoah-dev/2016-October/000892.html That code is long gone now, and current Shenandoah just reserves/commits from OS directly. Therefore, this flag is no longer needed. It actually confuses logging in JDK-8245720. Fix: https://cr.openjdk.java.net/~shade/8245754/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release}; ad-hoc runs -- Thanks, -Aleksey From shade at redhat.com Mon May 25 19:10:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 21:10:12 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b03 Upstream Sync In-Reply-To: References: Message-ID: <7a789d97-8ca7-d881-bbf5-df709d1a2e60@redhat.com> On 5/25/20 5:48 PM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/nashorn/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/root/merge.changeset Looks good. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From shade at redhat.com Mon May 25 19:16:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 21:16:00 +0200 Subject: RFR (XS) 8245755: Shenandoah: missing logging for CWR Roots Message-ID: <7aadb05f-2736-a94a-4b46-5d2dff9d1c18@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8245755 JDK-8244953 introduced the Roots/Rendezvous split in CWR logging. Yet, there is no "Roots" counter in the gc+stats, because there is nothing that tracks it. Fix: diff -r 403587ab7d6e src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Mon May 25 21:02:37 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Mon May 25 21:14:26 2020 +0200 @@ -1852,12 +1852,13 @@ } }; void ShenandoahHeap::op_weak_roots() { if (is_concurrent_weak_root_in_progress()) { { + ShenandoahTimingsTracker t(ShenandoahPhaseTimings::conc_weak_roots_work); ShenandoahGCWorkerPhase worker_phase(ShenandoahPhaseTimings::conc_weak_roots_work); ShenandoahConcurrentWeakRootsEvacUpdateTask task(ShenandoahPhaseTimings::conc_weak_roots_work); workers()->run_task(&task); if (!ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) { set_concurrent_weak_root_in_progress(false); Testing: hotspot_gc_shenandoah, eyeballing gc+stats -- Thanks, -Aleksey From shade at redhat.com Mon May 25 19:28:58 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 21:28:58 +0200 Subject: RFR (XS) 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8245757 At present, enabling -XX:+AlwaysPreTouch implicitly disables uncommit and sets the heap size to Xmx. This is not coherent with the rest of OpenJDK garbage collectors that only pretouch when the actual commit happens. Shenandoah should do the same. It would still be recommended to set -Xmx == -Xms for AlwaysPreTouch to work without excess latencies. Webrev: https://cr.openjdk.java.net/~shade/8245757/webrev.01/ Testing: hotspot_gc_shenandoah; ad-hoc perf runs -- Thanks, -Aleksey From rkennke at redhat.com Mon May 25 20:23:41 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 May 2020 22:23:41 +0200 Subject: RFR (S) 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch In-Reply-To: References: Message-ID: Yes, makes sense and looks good! Thanks, Roman On Mon, 2020-05-25 at 21:06 +0200, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245754 > > ShenandoahAlwaysPreTouch flag dates back to the times when > ShenandoahHeap used VirtualSpace for > reserving/committing heap. To workaround single-threaded pretouch > code in VirtualSpace, a new flag > was needed: > > https://mail.openjdk.java.net/pipermail/shenandoah-dev/2016-October/000892.html > > That code is long gone now, and current Shenandoah just > reserves/commits from OS directly. > Therefore, this flag is no longer needed. It actually confuses > logging in JDK-8245720. > > Fix: > https://cr.openjdk.java.net/~shade/8245754/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release}; ad-hoc runs > From rkennke at redhat.com Mon May 25 20:24:21 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 May 2020 22:24:21 +0200 Subject: RFR (XS) 8245755: Shenandoah: missing logging for CWR Roots In-Reply-To: <7aadb05f-2736-a94a-4b46-5d2dff9d1c18@redhat.com> References: <7aadb05f-2736-a94a-4b46-5d2dff9d1c18@redhat.com> Message-ID: <76bfe1de5e35295add819dafc60cc5e7f93841c0.camel@redhat.com> Yes, looks good! Roman On Mon, 2020-05-25 at 21:16 +0200, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8245755 > > JDK-8244953 introduced the Roots/Rendezvous split in CWR logging. > Yet, there is no "Roots" counter > in the gc+stats, because there is nothing that tracks it. > > Fix: > > diff -r 403587ab7d6e > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Mon > May 25 21:02:37 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Mon > May 25 21:14:26 2020 +0200 > @@ -1852,12 +1852,13 @@ > } > }; > > void ShenandoahHeap::op_weak_roots() { > if (is_concurrent_weak_root_in_progress()) { > { > + ShenandoahTimingsTracker > t(ShenandoahPhaseTimings::conc_weak_roots_work); > ShenandoahGCWorkerPhase > worker_phase(ShenandoahPhaseTimings::conc_weak_roots_work); > ShenandoahConcurrentWeakRootsEvacUpdateTask > task(ShenandoahPhaseTimings::conc_weak_roots_work); > workers()->run_task(&task); > if > (!ShenandoahConcurrentRoots::should_do_concurrent_class_unloading()) > { > set_concurrent_weak_root_in_progress(false); > > Testing: hotspot_gc_shenandoah, eyeballing gc+stats > From rkennke at redhat.com Mon May 25 20:25:27 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 25 May 2020 22:25:27 +0200 Subject: RFR (XS) 8245757: Shenandoah: AlwaysPreTouch should not disable heap resizing or uncommits In-Reply-To: References: Message-ID: <9bdfe89d3958662e989566bbcd99668d6516848b.camel@redhat.com> Alright, looks good! Roman On Mon, 2020-05-25 at 21:28 +0200, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245757 > > At present, enabling -XX:+AlwaysPreTouch implicitly disables uncommit > and sets the heap size to Xmx. > This is not coherent with the rest of OpenJDK garbage collectors that > only pretouch when the actual > commit happens. Shenandoah should do the same. It would still be > recommended to set -Xmx == -Xms for > AlwaysPreTouch to work without excess latencies. > > Webrev: > https://cr.openjdk.java.net/~shade/8245757/webrev.01/ > > Testing: hotspot_gc_shenandoah; ad-hoc perf runs > From shade at redhat.com Tue May 26 07:50:21 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 09:50:21 +0200 Subject: RFR (S) 8245720: Shenandoah: improve configuration logging Message-ID: <9f9bce9f-201f-b094-0850-53e31bef2b6a@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8245720 As the follow up of JDK-8244817 for Shenandoah GC, it makes sense to enable Shenandoah to print similar info. Example output: [0.006s][info][gc] Using Shenandoah [0.006s][info][gc] Heuristics ergonomically sets -XX:+ExplicitGCInvokesConcurrent [0.006s][info][gc] Heuristics ergonomically sets -XX:+ShenandoahImplicitGCInvokesConcurrent [0.360s][info][gc,init] Version: 15-internal+0-adhoc.shade.jdk-jdk (fastdebug) [0.360s][info][gc,init] CPUs: 16 total, 16 available [0.360s][info][gc,init] Memory: 125G [0.360s][info][gc,init] Large Page Support: Disabled [0.360s][info][gc,init] NUMA Support: Disabled [0.360s][info][gc,init] Compressed Oops: Enabled (Zero based) [0.360s][info][gc,init] Heap Min Capacity: 1G [0.360s][info][gc,init] Heap Initial Capacity: 1G [0.360s][info][gc,init] Heap Max Capacity: 10G [0.360s][info][gc,init] Pre-touch: Disabled [0.360s][info][gc,init] Mode: Snapshot-At-The-Beginning (SATB) [0.360s][info][gc,init] Heuristics: Adaptive [0.360s][info][gc,init] Heap Region Count: 2560 [0.360s][info][gc,init] Heap Region Size: 4M [0.360s][info][gc,init] TLAB Size Max: 4M [0.360s][info][gc,init] Humongous Object Threshold: 4M [0.360s][info][gc,init] Reference Processing: Parallel discovery, Parallel processing [0.360s][info][gc,init] Parallel Workers: 8 [0.360s][info][gc,init] Concurrent Workers: 4 Ready I am thinking to just inline the upstream superclass InitLogger into ShenandoahInitLogger when backporting this to 11u and 8u. Webrev: https://cr.openjdk.java.net/~shade/8245720/webrev.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Tue May 26 08:00:50 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 26 May 2020 10:00:50 +0200 Subject: RFR (S) 8245720: Shenandoah: improve configuration logging In-Reply-To: <9f9bce9f-201f-b094-0850-53e31bef2b6a@redhat.com> References: <9f9bce9f-201f-b094-0850-53e31bef2b6a@redhat.com> Message-ID: <3a2cc1b7116eda89c94f677621b109ef9e1a47cc.camel@redhat.com> Hi Aleksey, On Tue, 2020-05-26 at 09:50 +0200, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245720 > > As the follow up of JDK-8244817 for Shenandoah GC, it makes sense to > enable Shenandoah to print > similar info. Example output: > > [0.006s][info][gc] Using Shenandoah > [0.006s][info][gc] Heuristics ergonomically sets > -XX:+ExplicitGCInvokesConcurrent > [0.006s][info][gc] Heuristics ergonomically sets > -XX:+ShenandoahImplicitGCInvokesConcurrent > [0.360s][info][gc,init] Version: 15-internal+0-adhoc.shade.jdk-jdk > (fastdebug) > [0.360s][info][gc,init] CPUs: 16 total, 16 available > [0.360s][info][gc,init] Memory: 125G > [0.360s][info][gc,init] Large Page Support: Disabled > [0.360s][info][gc,init] NUMA Support: Disabled > [0.360s][info][gc,init] Compressed Oops: Enabled (Zero based) > [0.360s][info][gc,init] Heap Min Capacity: 1G > [0.360s][info][gc,init] Heap Initial Capacity: 1G > [0.360s][info][gc,init] Heap Max Capacity: 10G > [0.360s][info][gc,init] Pre-touch: Disabled > [0.360s][info][gc,init] Mode: Snapshot-At-The-Beginning (SATB) > [0.360s][info][gc,init] Heuristics: Adaptive > [0.360s][info][gc,init] Heap Region Count: 2560 > [0.360s][info][gc,init] Heap Region Size: 4M > [0.360s][info][gc,init] TLAB Size Max: 4M > [0.360s][info][gc,init] Humongous Object Threshold: 4M > [0.360s][info][gc,init] Reference Processing: Parallel discovery, > Parallel processing > [0.360s][info][gc,init] Parallel Workers: 8 > [0.360s][info][gc,init] Concurrent Workers: 4 > Ready > I like this 'Ready', kinda retro thing as in: https://www.c64-wiki.de/images/2/28/fehlermeldung_syntax.png > I am thinking to just inline the upstream superclass InitLogger into > ShenandoahInitLogger when > backporting this to 11u and 8u. > > Webrev: > https://cr.openjdk.java.net/~shade/8245720/webrev.01/ > > Testing: hotspot_gc_shenandoah > Looks good! Thanks, Roman From shade at redhat.com Tue May 26 08:07:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 10:07:14 +0200 Subject: RFR (S) 8245720: Shenandoah: improve configuration logging In-Reply-To: <3a2cc1b7116eda89c94f677621b109ef9e1a47cc.camel@redhat.com> References: <9f9bce9f-201f-b094-0850-53e31bef2b6a@redhat.com> <3a2cc1b7116eda89c94f677621b109ef9e1a47cc.camel@redhat.com> Message-ID: <04f9ad62-0de5-b607-7a54-901893d121f4@redhat.com> On 5/26/20 10:00 AM, Roman Kennke wrote: >> [0.360s][info][gc,init] Parallel Workers: 8 >> [0.360s][info][gc,init] Concurrent Workers: 4 >> Ready > > I like this 'Ready', kinda retro thing as in: > https://www.c64-wiki.de/images/2/28/fehlermeldung_syntax.png Oh no, that's from the HelloWorld workload, it is not part of the GC logging. :) >> Webrev: >> https://cr.openjdk.java.net/~shade/8245720/webrev.01/ > > Looks good! Cheers, I'll push sometime today. -- Thanks, -Aleksey From shade at redhat.com Tue May 26 10:19:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 12:19:08 +0200 Subject: RFR (XS) 8245773: Shenandoah: Windows assertion failure after JDK-8245464 Message-ID: <57822705-0a7b-5f86-bf4a-032335e2eb3d@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8245773 JDK-8245464 made the accidental change that dropped the alignment to os::vm_allocation_granularity(), which fails on Windows. Argh. Simple fix: diff -r 5b77ebd1b4a6 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue May 26 09:43:55 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue May 26 12:16:05 2020 +0200 @@ -306,5 +306,5 @@ char* req_addr = (char*)addr; assert(is_aligned(req_addr, cset_align), "Should be aligned"); - ReservedSpace cset_rs(cset_size, os::vm_page_size(), false, req_addr); + ReservedSpace cset_rs(cset_size, cset_align, false, req_addr); if (cset_rs.is_reserved()) { assert(cset_rs.base() == req_addr, "Allocated where requested: " PTR_FORMAT ", " PTR_FORMAT, p2i(cset_rs.base()), addr); @@ -315,5 +315,5 @@ if (_collection_set == NULL) { - ReservedSpace cset_rs(cset_size, os::vm_page_size(), false); + ReservedSpace cset_rs(cset_size, cset_align, false); _collection_set = new ShenandoahCollectionSet(this, cset_rs, sh_rs.base()); } Testing: hotspot_gc_shenandoah {Linux, Windows} -- Thanks, -Aleksey From thomas.stuefe at gmail.com Tue May 26 10:28:18 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 26 May 2020 12:28:18 +0200 Subject: RFR (XS) 8245773: Shenandoah: Windows assertion failure after JDK-8245464 In-Reply-To: <57822705-0a7b-5f86-bf4a-032335e2eb3d@redhat.com> References: <57822705-0a7b-5f86-bf4a-032335e2eb3d@redhat.com> Message-ID: looks good, thank you! ..Thomas On Tue, May 26, 2020 at 12:20 PM Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8245773 > > JDK-8245464 made the accidental change that dropped the alignment to > os::vm_allocation_granularity(), which fails on Windows. Argh. > > Simple fix: > > diff -r 5b77ebd1b4a6 src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue May 26 > 09:43:55 2020 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp Tue May 26 > 12:16:05 2020 +0200 > @@ -306,5 +306,5 @@ > char* req_addr = (char*)addr; > assert(is_aligned(req_addr, cset_align), "Should be aligned"); > - ReservedSpace cset_rs(cset_size, os::vm_page_size(), false, > req_addr); > + ReservedSpace cset_rs(cset_size, cset_align, false, req_addr); > if (cset_rs.is_reserved()) { > assert(cset_rs.base() == req_addr, "Allocated where requested: " > PTR_FORMAT ", " > PTR_FORMAT, p2i(cset_rs.base()), addr); > @@ -315,5 +315,5 @@ > > if (_collection_set == NULL) { > - ReservedSpace cset_rs(cset_size, os::vm_page_size(), false); > + ReservedSpace cset_rs(cset_size, cset_align, false); > _collection_set = new ShenandoahCollectionSet(this, cset_rs, > sh_rs.base()); > } > > Testing: hotspot_gc_shenandoah {Linux, Windows} > > -- > Thanks, > -Aleksey > > From shade at redhat.com Tue May 26 11:09:40 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 13:09:40 +0200 Subject: RFR (XS) 8245773: Shenandoah: Windows assertion failure after JDK-8245464 In-Reply-To: References: <57822705-0a7b-5f86-bf4a-032335e2eb3d@redhat.com> Message-ID: On 5/26/20 12:28 PM, Thomas St?fe wrote: > looks good, thank you! No problem, pushed. -- Thanks, -Aleksey From rkennke at redhat.com Tue May 26 12:42:05 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 26 May 2020 14:42:05 +0200 Subject: [8] RFR: Parallel cleaning improvements In-Reply-To: References: Message-ID: <06fd1256f0c2c216731a52ec4eaacd66f55822db.camel@redhat.com> Looks good to me! Thanks, Roman On Mon, 2020-05-25 at 09:30 +0200, Aleksey Shipilev wrote: > In sh/jdk8, we have gc/shared/parallelCleaning.* that is only used by > Shenandoah. We did this a long > time ago thinking we would share this with G1. But, in later > releases, we have decided to have > gc/shenandoah/shenandoahParallelCleaning.* instead. sh/jdk11 has it, > jdk/jdk has it. sh/jdk8 should > do the same. > > Additionally, there are format specifier problems in > ~ShenandoahStringSymbolTableUnlinkTask, which > prevent it to build with C++11 enabled. Those are fixed in a separate > changeset. > > Webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/8u-parallel-cleaning/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From shade at redhat.com Tue May 26 12:45:58 2020 From: shade at redhat.com (shade at redhat.com) Date: Tue, 26 May 2020 12:45:58 +0000 Subject: hg: shenandoah/jdk8/hotspot: 2 new changesets Message-ID: <202005261245.04QCjwF7009284@aojmv0008.oracle.com> Changeset: aa45dd2b3ee3 Author: shade Date: 2020-05-26 14:45 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/aa45dd2b3ee3 Shenandoah: move parallelCleaning.* to shenandoah/ Reviewed-by: rkennke - src/share/vm/gc_implementation/shared/parallelCleaning.cpp - src/share/vm/gc_implementation/shared/parallelCleaning.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.hpp Changeset: b95b2bbb79e7 Author: shade Date: 2020-05-26 14:45 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b95b2bbb79e7 Shenandoah: fix formats in ShenandoahStringSymbolTableUnlinkTask Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.hpp From shade at redhat.com Tue May 26 14:40:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 16:40:11 +0200 Subject: RFR (S) 8245812: Shenandoah: compute root phase parallelism Message-ID: <37592ee3-caf0-0f14-8020-0b90321c5738@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8245812 Current gc+stats log says: [gc,stats] All times are wall-clock times, except per-root-class counters, that are sum over [gc,stats] all workers. Dividing the over the root stage time estimates parallelism. But we can actually compute it ourselves: diff -r 6a562866cbd0 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 09:44:17 2020 -0400 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 16:36:10 2020 +0200 @@ -35,10 +35,11 @@ #define SHENANDOAH_PHASE_NAME_FORMAT "%-28s" #define SHENANDOAH_S_TIME_FORMAT "%8.3lf" #define SHENANDOAH_US_TIME_FORMAT "%8.0lf" #define SHENANDOAH_US_WORKER_TIME_FORMAT "%3.0lf" +#define SHENANDOAH_PARALLELISM_FORMAT "%4.2lf" #define SHENANDOAH_PHASE_DECLARE_NAME(type, title) \ title, const char* ShenandoahPhaseTimings::_phase_names[] = { @@ -227,10 +228,16 @@ out->cr(); for (uint i = 0; i < _num_phases; i++) { double v = _cycle_data[i] * 1000000.0; if (v > 0) { out->print(SHENANDOAH_PHASE_NAME_FORMAT " " SHENANDOAH_US_TIME_FORMAT " us", _phase_names[i], v); + + if (is_worker_phase(Phase(i))) { + double total = _cycle_data[i + 1] * 1000000.0; + out->print(", parallelism: " SHENANDOAH_PARALLELISM_FORMAT "x", total / v); + } + if (_worker_data[i] != NULL) { out->print(", workers (us): "); for (uint c = 0; c < _max_workers; c++) { double tv = _worker_data[i]->get(c); if (tv != ShenandoahWorkerData::uninitialized()) { Would print like this, on a special CLDG torture test that is used to optimize CLDG walks: Pause Init Mark (G) 26558 us Pause Init Mark (N) 26357 us Make Parsable 7 us Update Region States 31 us Scan Roots 26267 us, parallelism: 3.63x S: 95442 us S: Thread Roots 159 us, workers (us): 41, 15, 15, 5, 17, ... S: Universe Roots 3 us, workers (us): 3, ---, ---, ---, ---, ... S: JNI Handles Roots 4 us, workers (us): 1, 0, 1, 1, 1, ... S: VM Global Roots 1 us, workers (us): 0, 0, 0, 0, 0, ... S: Synchronizer Roots 0 us, workers (us): 0, ---, ---, ---, ---, ... S: Management Roots 1 us, workers (us): 1, ---, ---, ---, ---, ... S: System Dict Roots 10 us, workers (us): ---, 10, ---, ---, ---, ... S: CLDG Roots 95263 us, workers (us): 11933, 11924, 11926, 11923, ... S: JVMTI Roots 0 us, workers (us): 0, ---, ---, ---, ---, ... Note it says ~3.6x parallelism, while there are 8 workers. This highlights the high setup costs for CLDG walk. Testing: hotspot_gc_shenandoah, eyeballing gc logs -- Thanks, -Aleksey From shade at redhat.com Tue May 26 14:44:30 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 16:44:30 +0200 Subject: RFR (XS) 8245814: Shenandoah: reconsider format specifiers for stats Message-ID: <0896d895-fa3d-927d-8941-4463e0df4ee9@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8245814 Current log is misplaced because "CWR: Resolved Table Roots" is larger than the format specifier for it. Let's bump the specifier lengths. Also, make sure the US_WORKER_TIME_FORMAT matches the "empty" slot. I did it while changing its length from 3 to 4, but ultimately decided to keep at 3. Fix: diff -r bdeba1590341 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 16:36:08 2020 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 16:42:43 2020 +0200 @@ -34,8 +34,9 @@ #include "utilities/ostream.hpp" -#define SHENANDOAH_PHASE_NAME_FORMAT "%-28s" +#define SHENANDOAH_PHASE_NAME_FORMAT "%-30s" #define SHENANDOAH_S_TIME_FORMAT "%8.3lf" #define SHENANDOAH_US_TIME_FORMAT "%8.0lf" #define SHENANDOAH_US_WORKER_TIME_FORMAT "%3.0lf" +#define SHENANDOAH_US_WORKER_NOTIME_FORMAT "%3s" #define SHENANDOAH_PARALLELISM_FORMAT "%4.2lf" @@ -244,5 +245,5 @@ out->print(SHENANDOAH_US_WORKER_TIME_FORMAT ", ", tv * 1000000.0); } else { - out->print("%3s, ", "---"); + out->print(SHENANDOAH_US_WORKER_NOTIME_FORMAT ", ", "---"); } } Testing: hotspot_gc_shenandoah, eyeballing GC logs. -- Thanks, -Aleksey From zgu at redhat.com Tue May 26 15:36:53 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 May 2020 11:36:53 -0400 Subject: [15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope Message-ID: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> Please review this patch that makes ShenandoahEvacOOMScope inline-able, also avoids calling ShenandoahHeap::heap() and Thread::current() if caller can provide them. The gain is not as noticeable as JDK-8245240 and JDK-8245288, but seems consistent. Bug: https://bugs.openjdk.java.net/browse/JDK-8245823 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.00/index.html Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Tue May 26 16:33:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 18:33:05 +0200 Subject: [15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope In-Reply-To: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> References: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> Message-ID: On 5/26/20 5:36 PM, Zhengyu Gu wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8245823 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.00/index.html Hm! I actually thought we optimized ShenandoahHeap::heap() enough not to matter [1]. Reverting heap() cache would seem to ditch some of these overloads: 131 inline ShenandoahEvacOOMScope(); 132 inline ShenandoahEvacOOMScope(Thread* t); 133 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap); 134 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap, Thread* t); 135 inline ~ShenandoahEvacOOMScope(); Thread:current() seems fine to pass, where available, and store locally. -- Thanks, -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8241743 From shade at redhat.com Tue May 26 17:50:32 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 19:50:32 +0200 Subject: RFR (S) 8245812: Shenandoah: compute root phase parallelism In-Reply-To: <37592ee3-caf0-0f14-8020-0b90321c5738@redhat.com> References: <37592ee3-caf0-0f14-8020-0b90321c5738@redhat.com> Message-ID: <13cd1cac-6161-07e2-65db-cb070233aaaa@redhat.com> On 5/26/20 4:40 PM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245812 > > Current gc+stats log says: > > [gc,stats] All times are wall-clock times, except per-root-class counters, that are sum over > [gc,stats] all workers. Dividing the over the root stage time estimates parallelism. > > But we can actually compute it ourselves: Actually, should test for (total > 0), on the off-chance it is uninitialized: diff -r 6a562866cbd0 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 09:44:17 2020 -0400 +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 19:49:45 2020 +0200 @@ -35,10 +35,11 @@ #define SHENANDOAH_PHASE_NAME_FORMAT "%-28s" #define SHENANDOAH_S_TIME_FORMAT "%8.3lf" #define SHENANDOAH_US_TIME_FORMAT "%8.0lf" #define SHENANDOAH_US_WORKER_TIME_FORMAT "%3.0lf" +#define SHENANDOAH_PARALLELISM_FORMAT "%4.2lf" #define SHENANDOAH_PHASE_DECLARE_NAME(type, title) \ title, const char* ShenandoahPhaseTimings::_phase_names[] = { @@ -227,10 +228,18 @@ out->cr(); for (uint i = 0; i < _num_phases; i++) { double v = _cycle_data[i] * 1000000.0; if (v > 0) { out->print(SHENANDOAH_PHASE_NAME_FORMAT " " SHENANDOAH_US_TIME_FORMAT " us", _phase_names[i], v); + + if (is_worker_phase(Phase(i))) { + double total = _cycle_data[i + 1] * 1000000.0; + if (total > 0) { + out->print(", parallelism: " SHENANDOAH_PARALLELISM_FORMAT "x", total / v); + } + } + if (_worker_data[i] != NULL) { out->print(", workers (us): "); for (uint c = 0; c < _max_workers; c++) { double tv = _worker_data[i]->get(c); if (tv != ShenandoahWorkerData::uninitialized()) { -- Thanks, -Aleksey From zgu at redhat.com Tue May 26 17:57:06 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 May 2020 13:57:06 -0400 Subject: [15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope In-Reply-To: References: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> Message-ID: <027ce930-d7cf-dc9d-4ad6-601914c36eef@redhat.com> > Hm! I actually thought we optimized ShenandoahHeap::heap() enough not to matter [1]. Reverting > heap() cache would seem to ditch some of these overloads: > > 131 inline ShenandoahEvacOOMScope(); > 132 inline ShenandoahEvacOOMScope(Thread* t); > 133 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap); > 134 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap, Thread* t); > 135 inline ~ShenandoahEvacOOMScope(); > > Thread:current() seems fine to pass, where available, and store locally. Okay, updated: http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.01/index.html -Zhengyu From zgu at redhat.com Tue May 26 18:00:32 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 May 2020 14:00:32 -0400 Subject: RFR (S) 8245812: Shenandoah: compute root phase parallelism In-Reply-To: <13cd1cac-6161-07e2-65db-cb070233aaaa@redhat.com> References: <37592ee3-caf0-0f14-8020-0b90321c5738@redhat.com> <13cd1cac-6161-07e2-65db-cb070233aaaa@redhat.com> Message-ID: Looks good. -Zhengyu On 5/26/20 1:50 PM, Aleksey Shipilev wrote: > On 5/26/20 4:40 PM, Aleksey Shipilev wrote: >> RFE: >> https://bugs.openjdk.java.net/browse/JDK-8245812 >> >> Current gc+stats log says: >> >> [gc,stats] All times are wall-clock times, except per-root-class counters, that are sum over >> [gc,stats] all workers. Dividing the over the root stage time estimates parallelism. >> >> But we can actually compute it ourselves: > > Actually, should test for (total > 0), on the off-chance it is uninitialized: > > diff -r 6a562866cbd0 src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 09:44:17 2020 -0400 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Tue May 26 19:49:45 2020 +0200 > @@ -35,10 +35,11 @@ > > #define SHENANDOAH_PHASE_NAME_FORMAT "%-28s" > #define SHENANDOAH_S_TIME_FORMAT "%8.3lf" > #define SHENANDOAH_US_TIME_FORMAT "%8.0lf" > #define SHENANDOAH_US_WORKER_TIME_FORMAT "%3.0lf" > +#define SHENANDOAH_PARALLELISM_FORMAT "%4.2lf" > > #define SHENANDOAH_PHASE_DECLARE_NAME(type, title) \ > title, > > const char* ShenandoahPhaseTimings::_phase_names[] = { > @@ -227,10 +228,18 @@ > out->cr(); > for (uint i = 0; i < _num_phases; i++) { > double v = _cycle_data[i] * 1000000.0; > if (v > 0) { > out->print(SHENANDOAH_PHASE_NAME_FORMAT " " SHENANDOAH_US_TIME_FORMAT " us", _phase_names[i], v); > + > + if (is_worker_phase(Phase(i))) { > + double total = _cycle_data[i + 1] * 1000000.0; > + if (total > 0) { > + out->print(", parallelism: " SHENANDOAH_PARALLELISM_FORMAT "x", total / v); > + } > + } > + > if (_worker_data[i] != NULL) { > out->print(", workers (us): "); > for (uint c = 0; c < _max_workers; c++) { > double tv = _worker_data[i]->get(c); > if (tv != ShenandoahWorkerData::uninitialized()) { > From shade at redhat.com Tue May 26 18:00:49 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 20:00:49 +0200 Subject: [15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope In-Reply-To: <027ce930-d7cf-dc9d-4ad6-601914c36eef@redhat.com> References: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> <027ce930-d7cf-dc9d-4ad6-601914c36eef@redhat.com> Message-ID: <6d1bf514-cd46-2be9-cfba-2339ad57dee4@redhat.com> On 5/26/20 7:57 PM, Zhengyu Gu wrote: >> Hm! I actually thought we optimized ShenandoahHeap::heap() enough not to matter [1]. Reverting >> heap() cache would seem to ditch some of these overloads: >> >> 131 inline ShenandoahEvacOOMScope(); >> 132 inline ShenandoahEvacOOMScope(Thread* t); >> 133 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap); >> 134 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap, Thread* t); >> 135 inline ~ShenandoahEvacOOMScope(); >> >> Thread:current() seems fine to pass, where available, and store locally. > > Okay, updated: > http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.01/index.html Looks fine to me. Roman might want to take a look. Nit: Excess spacing at L126 here: 124 class ShenandoahEvacOOMScope : public StackObj { 125 private: 126 Thread* const _thread; -- Thanks, -Aleksey From zgu at redhat.com Tue May 26 19:28:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 May 2020 15:28:28 -0400 Subject: [15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope In-Reply-To: <6d1bf514-cd46-2be9-cfba-2339ad57dee4@redhat.com> References: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> <027ce930-d7cf-dc9d-4ad6-601914c36eef@redhat.com> <6d1bf514-cd46-2be9-cfba-2339ad57dee4@redhat.com> Message-ID: <1d86bd2e-20d4-0ccd-f03d-eed455065b79@redhat.com> On 5/26/20 2:00 PM, Aleksey Shipilev wrote: > On 5/26/20 7:57 PM, Zhengyu Gu wrote: >>> Hm! I actually thought we optimized ShenandoahHeap::heap() enough not to matter [1]. Reverting >>> heap() cache would seem to ditch some of these overloads: >>> >>> 131 inline ShenandoahEvacOOMScope(); >>> 132 inline ShenandoahEvacOOMScope(Thread* t); >>> 133 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap); >>> 134 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap, Thread* t); >>> 135 inline ~ShenandoahEvacOOMScope(); >>> >>> Thread:current() seems fine to pass, where available, and store locally. >> >> Okay, updated: >> http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.01/index.html > > Looks fine to me. Roman might want to take a look. Sure. > > Nit: Excess spacing at L126 here: > > 124 class ShenandoahEvacOOMScope : public StackObj { > 125 private: > 126 Thread* const _thread; > Will fix before push. Thanks, -Zhengyu From zgu at redhat.com Tue May 26 19:51:52 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 May 2020 15:51:52 -0400 Subject: [15] RFR 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots Message-ID: <31df7964-151e-46bd-18a2-5c90f93a1490@redhat.com> We have diagnostic flag "ShenandoahConcurrentScanCodeRoots" default to true for a long period of time without any issues, let's remove it. Bug: https://bugs.openjdk.java.net/browse/JDK-8245825 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245825/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From zgu at redhat.com Wed May 27 00:42:05 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 26 May 2020 20:42:05 -0400 Subject: [15] RFR 8245827: Shenandoah: Cleanup Shenandoah code root iterators and root scanner Message-ID: ShenandoahCsetCodeRootsIterator and ShenandoahCSetRootScanner are only relevant to Traversal GC, which was removed by JDK-8242082, they should be removed as well. After removal, we can rename ShenandoahAllCodeRootsIterator and ShenandoahAllRootScanner back to ShenandoahCodeRootsIterator and ShenandoahRootScanner, respectively. Bug: https://bugs.openjdk.java.net/browse/JDK-8245827 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245827/webrev.00/index.html Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Wed May 27 07:24:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 09:24:14 +0200 Subject: [15] RFR 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots In-Reply-To: <31df7964-151e-46bd-18a2-5c90f93a1490@redhat.com> References: <31df7964-151e-46bd-18a2-5c90f93a1490@redhat.com> Message-ID: On 5/26/20 9:51 PM, Zhengyu Gu wrote: > We have diagnostic flag "ShenandoahConcurrentScanCodeRoots" default to > true for a long period of time without any issues, let's remove it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245825 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245825/webrev.00/ Looks good! -- Thanks, -Aleksey From shade at redhat.com Wed May 27 08:58:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 10:58:37 +0200 Subject: [15] RFR 8245827: Shenandoah: Cleanup Shenandoah code root iterators and root scanner In-Reply-To: References: Message-ID: <794a904c-80ec-e3e0-88af-761c4e1ea1e7@redhat.com> On 5/27/20 2:42 AM, Zhengyu Gu wrote: > ShenandoahCsetCodeRootsIterator and ShenandoahCSetRootScanner are only > relevant to Traversal GC, which was removed by JDK-8242082, they should > be removed as well. > > After removal, we can rename ShenandoahAllCodeRootsIterator and > ShenandoahAllRootScanner back to ShenandoahCodeRootsIterator and > ShenandoahRootScanner, respectively. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245827 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245827/webrev.00/index.html Looks good! For the code that is moved around, there were no actual semantic changes, right? I haven't checked that part closely. -- Thanks, -Aleksey From shade at redhat.com Wed May 27 09:22:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 11:22:48 +0200 Subject: RFC: Pick up jdk-11.0.8+5 to sh/jdk11 Message-ID: <1114b4bb-fc0b-307d-1092-390e440efba1@redhat.com> Upstream had published 11.0.8+5, let's pick it up to sh/jdk11. Merge is trivial. I would tag it shenandoah-jdk-11.0.8+5 right away. Testing: hotspot_gc_shenandoah {fastdebug, release} -- Thanks, -Aleksey From shade at redhat.com Wed May 27 09:30:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 11:30:31 +0200 Subject: RFR (S) 8245478: Implementation: JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production) Message-ID: <686d1fcf-01b0-0722-9a2e-f54ad9656d61@redhat.com> Hi, JEP: https://openjdk.java.net/jeps/379 Impl: https://bugs.openjdk.java.net/browse/JDK-8245478 CSR: https://bugs.openjdk.java.net/browse/JDK-8245479 Webrev: https://cr.openjdk.java.net/~shade/8245478/webrev.01/ Along with flag changes, I also enabled back the tests that assume Shenandoah is "product", like we have in sh/jdk11 and sh/jdk8 trees. Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Wed May 27 10:30:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 12:30:05 +0200 Subject: [14] RFR (S) 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics Message-ID: <03be4712-1159-dd78-2706-6ebd22f5ed4a@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8244732 https://hg.openjdk.java.net/jdk/jdk/rev/1c6c963683e2 Context is a bit different, so I re-made the actual moves, and applied the rest of the hunks automatically. 14u webrev: https://cr.openjdk.java.net/~shade/8244732/webrev.14u.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Wed May 27 10:31:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 12:31:50 +0200 Subject: [14] RFR (S) 8244737: Shenandoah: move mode code to gc/shenandoah/mode Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8244737 https://hg.openjdk.java.net/jdk/jdk/rev/a8dd9e32110b Again, the context is a bit different, so I re-made the actual moves, and applied the rest of the hunks automatically. 14u webrev: https://cr.openjdk.java.net/~shade/8244737/webrev.14u.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Wed May 27 10:33:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 12:33:12 +0200 Subject: [14] RFR (S) 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode Message-ID: <9a82ec91-aa0a-643d-2839-5bf9f013ae64@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8244740 https://hg.openjdk.java.net/jdk/jdk/rev/9fb4e20c6975 Once again, context is a bit different, so I re-made the actual rename, and applied the rest of the hunks automatically. 14u webrev: https://cr.openjdk.java.net/~shade/8244740/webrev.01/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed May 27 11:10:32 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 13:10:32 +0200 Subject: RFR (XS) 8245814: Shenandoah: reconsider format specifiers for stats In-Reply-To: <0896d895-fa3d-927d-8941-4463e0df4ee9@redhat.com> References: <0896d895-fa3d-927d-8941-4463e0df4ee9@redhat.com> Message-ID: Ok, looks good! Roman On Tue, 2020-05-26 at 16:44 +0200, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245814 > > Current log is misplaced because "CWR: Resolved Table Roots" is > larger than the format specifier for > it. Let's bump the specifier lengths. Also, make sure the > US_WORKER_TIME_FORMAT matches the "empty" > slot. I did it while changing its length from 3 to 4, but ultimately > decided to keep at 3. > > Fix: > > diff -r bdeba1590341 > src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp > --- > a/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp T > ue May 26 16:36:08 2020 +0200 > +++ > b/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp T > ue May 26 16:42:43 2020 +0200 > @@ -34,8 +34,9 @@ > #include "utilities/ostream.hpp" > > -#define SHENANDOAH_PHASE_NAME_FORMAT "%-28s" > +#define SHENANDOAH_PHASE_NAME_FORMAT "%-30s" > #define SHENANDOAH_S_TIME_FORMAT "%8.3lf" > #define SHENANDOAH_US_TIME_FORMAT "%8.0lf" > #define SHENANDOAH_US_WORKER_TIME_FORMAT "%3.0lf" > +#define SHENANDOAH_US_WORKER_NOTIME_FORMAT "%3s" > #define SHENANDOAH_PARALLELISM_FORMAT "%4.2lf" > > @@ -244,5 +245,5 @@ > out->print(SHENANDOAH_US_WORKER_TIME_FORMAT ", ", tv * > 1000000.0); > } else { > - out->print("%3s, ", "---"); > + out->print(SHENANDOAH_US_WORKER_NOTIME_FORMAT ", ", "--- > "); > } > } > > Testing: hotspot_gc_shenandoah, eyeballing GC logs. > From rkennke at redhat.com Wed May 27 11:18:52 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 13:18:52 +0200 Subject: [15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope In-Reply-To: <027ce930-d7cf-dc9d-4ad6-601914c36eef@redhat.com> References: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> <027ce930-d7cf-dc9d-4ad6-601914c36eef@redhat.com> Message-ID: <7b99bef9838659db19704abd593bc91fd41c122e.camel@redhat.com> On Tue, 2020-05-26 at 13:57 -0400, Zhengyu Gu wrote: > > Hm! I actually thought we optimized ShenandoahHeap::heap() enough > > not to matter [1]. Reverting > > heap() cache would seem to ditch some of these overloads: > > > > 131 inline ShenandoahEvacOOMScope(); > > 132 inline ShenandoahEvacOOMScope(Thread* t); > > 133 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap); > > 134 inline ShenandoahEvacOOMScope(ShenandoahHeap* heap, Thread* > > t); > > 135 inline ~ShenandoahEvacOOMScope(); > > > > Thread:current() seems fine to pass, where available, and store > > locally. > > Okay, updated: > http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.01/index.html > > -Zhengyu Looks good in general. + void register_thread_to_protocol(Thread* t); + void unregister_thread_to_protocol(Thread* t); It would have to be 'unregister_thread_from_protocol' but then I think we can just do 'register_thread' and 'unregister_thread' instead? Also, why not inline register_thread() and unregister_thread() too? Those appear to be the common paths in mutator-LRB, and should only account for a few instructions? It may be worth passing thread from compiled-code into mutator-LRB, we already keep it permanently in a register, and it may be relevant for tiny-object-evacs. But that would be a future change. Roman From rkennke at redhat.com Wed May 27 11:21:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 13:21:31 +0200 Subject: RFR (S) 8245478: Implementation: JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production) In-Reply-To: <686d1fcf-01b0-0722-9a2e-f54ad9656d61@redhat.com> References: <686d1fcf-01b0-0722-9a2e-f54ad9656d61@redhat.com> Message-ID: Looks good to me! Thanks, Roman On Wed, 2020-05-27 at 11:30 +0200, Aleksey Shipilev wrote: > Hi, > > JEP: https://openjdk.java.net/jeps/379 > Impl: https://bugs.openjdk.java.net/browse/JDK-8245478 > CSR: https://bugs.openjdk.java.net/browse/JDK-8245479 > > Webrev: > https://cr.openjdk.java.net/~shade/8245478/webrev.01/ > > Along with flag changes, I also enabled back the tests that assume > Shenandoah is "product", like we > have in sh/jdk11 and sh/jdk8 trees. > > Testing: hotspot_gc_shenandoah > From rkennke at redhat.com Wed May 27 11:20:56 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 13:20:56 +0200 Subject: RFC: Pick up jdk-11.0.8+5 to sh/jdk11 In-Reply-To: <1114b4bb-fc0b-307d-1092-390e440efba1@redhat.com> References: <1114b4bb-fc0b-307d-1092-390e440efba1@redhat.com> Message-ID: <21b94cedbbfee67b272d49c8b19f4537a6346915.camel@redhat.com> Please go ahead! Thanks, Roman On Wed, 2020-05-27 at 11:22 +0200, Aleksey Shipilev wrote: > Upstream had published 11.0.8+5, let's pick it up to sh/jdk11. > > Merge is trivial. I would tag it shenandoah-jdk-11.0.8+5 right away. > > Testing: hotspot_gc_shenandoah {fastdebug, release} > From rkennke at redhat.com Wed May 27 11:22:24 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 13:22:24 +0200 Subject: [14] RFR (S) 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics In-Reply-To: <03be4712-1159-dd78-2706-6ebd22f5ed4a@redhat.com> References: <03be4712-1159-dd78-2706-6ebd22f5ed4a@redhat.com> Message-ID: <818717774f1c5c7800cf0109a87cee7f330d3d6c.camel@redhat.com> Looks good to me! Thanks, Roman On Wed, 2020-05-27 at 12:30 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8244732 > https://hg.openjdk.java.net/jdk/jdk/rev/1c6c963683e2 > > Context is a bit different, so I re-made the actual moves, and > applied the rest of the hunks > automatically. 14u webrev: > https://cr.openjdk.java.net/~shade/8244732/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Wed May 27 11:23:12 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 13:23:12 +0200 Subject: [14] RFR (S) 8244737: Shenandoah: move mode code to gc/shenandoah/mode In-Reply-To: References: Message-ID: Yes, looks good! Thank you! Roman On Wed, 2020-05-27 at 12:31 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8244737 > https://hg.openjdk.java.net/jdk/jdk/rev/a8dd9e32110b > > Again, the context is a bit different, so I re-made the actual moves, > and applied the rest of the > hunks automatically. 14u webrev: > https://cr.openjdk.java.net/~shade/8244737/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Wed May 27 11:23:38 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 13:23:38 +0200 Subject: [14] RFR (S) 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode In-Reply-To: <9a82ec91-aa0a-643d-2839-5bf9f013ae64@redhat.com> References: <9a82ec91-aa0a-643d-2839-5bf9f013ae64@redhat.com> Message-ID: <7f4f28ccfe98d7790389ac7749d520f223554368.camel@redhat.com> Looks good, thank you! Roman On Wed, 2020-05-27 at 12:33 +0200, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8244740 > https://hg.openjdk.java.net/jdk/jdk/rev/9fb4e20c6975 > > Once again, context is a bit different, so I re-made the actual > rename, and applied the rest of the > hunks automatically. 14u webrev: > https://cr.openjdk.java.net/~shade/8244740/webrev.01/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From zgu at redhat.com Wed May 27 12:00:42 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 May 2020 08:00:42 -0400 Subject: [15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope In-Reply-To: <7b99bef9838659db19704abd593bc91fd41c122e.camel@redhat.com> References: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> <027ce930-d7cf-dc9d-4ad6-601914c36eef@redhat.com> <7b99bef9838659db19704abd593bc91fd41c122e.camel@redhat.com> Message-ID: <033a8eae-9882-65ce-d7bf-f5df24006b59@redhat.com> Hi Roman, >> >> Okay, updated: >> http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.01/index.html >> >> -Zhengyu > > Looks good in general. > > + void register_thread_to_protocol(Thread* t); > + void unregister_thread_to_protocol(Thread* t); > > It would have to be 'unregister_thread_from_protocol' but then I think > we can just do 'register_thread' and 'unregister_thread' instead? > Sure, will rename before push. > Also, why not inline register_thread() and unregister_thread() too? > Those appear to be the common paths in mutator-LRB, and should only > account for a few instructions? This patch is really intended to address nesting scopes, to shred a few nano seconds from code root evacuation. I did not study barrier cases, so let's experiment that in separate CR, Okay? Thanks, -Zhengyu > > It may be worth passing thread from compiled-code into mutator-LRB, we > already keep it permanently in a register, and it may be relevant for > tiny-object-evacs. But that would be a future change. > > Roman > From shade at redhat.com Wed May 27 12:04:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 14:04:16 +0200 Subject: RFR (S) 8245942: Shenandoah: x86_32 builds fail after JDK-8245594 Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8245942 JDK-8245594 removed some volatile-qualified members, so now x86_32 build fails. I believe we just turn the affected classes trivially copyable as well, like it was done for ShenandoahVerifierTask in JDK-8245594. Fix: https://cr.openjdk.java.net/~shade/8245942/webrev.01/ Kim, does that match original intent with JDK-8245594? Testing: hotspot_gc_shenandoah {x86_64, x86_32} -- Thanks, -Aleksey From rkennke at redhat.com Wed May 27 12:04:05 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 14:04:05 +0200 Subject: RFR: 8245955: Shenandoah: Remove LRB/is_redundant optimization Message-ID: Just before expanding LRBs in C2, we check whether or not the LRB is actually used for anything useful. This optimization is a bit odd, it doesn't really follow the usual pattern for such things (it should be done by overwriting Ideal/Identity in the consuming node, and the LRB would be eliminated when it has no users left). Also, the optimization doesn't actually seem to have any positive effect anymore. It used to be significant when we had to deal with null-checks, but this is gone. The only other thing left is OptimizeStaticFinals, which is already covered by C2 because it inlines such fields as constants. Also, this blocks an improvement to ensure that there's no safepoints between loads and LRBs because eliminating the LRB can leave from-space oops in local variables. I've run SPECjvm2008 and SPECjbb2015, and have seen no regressions. Some workloads even seem to benefit (in the range 1-2%) from this change, and it appears to be a stable, but I have no explanation yet why this should be the case. Bug: https://bugs.openjdk.java.net/browse/JDK-8245955 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8245955/webrev.00/ Testing: hotspot_gc_shenandoah, several runs of specjvm and specjbb without noticable regressions Roman From shade at redhat.com Wed May 27 12:04:47 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 14:04:47 +0200 Subject: RFC: Pick up jdk-11.0.8+5 to sh/jdk11 In-Reply-To: <21b94cedbbfee67b272d49c8b19f4537a6346915.camel@redhat.com> References: <1114b4bb-fc0b-307d-1092-390e440efba1@redhat.com> <21b94cedbbfee67b272d49c8b19f4537a6346915.camel@redhat.com> Message-ID: <6e08f7db-fe30-31b5-1bcc-91be6a584480@redhat.com> On 5/27/20 1:20 PM, Roman Kennke wrote: > Please go ahead! Cheers, pushed. -- -Aleksey From rkennke at redhat.com Wed May 27 12:04:49 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 27 May 2020 14:04:49 +0200 Subject: [15] RFR 8245823: Shenandoah: inline/optimize ShenandoahEvacOOMScope In-Reply-To: <033a8eae-9882-65ce-d7bf-f5df24006b59@redhat.com> References: <2693f3c3-3cec-cb8f-76c0-5559073d30a1@redhat.com> <027ce930-d7cf-dc9d-4ad6-601914c36eef@redhat.com> <7b99bef9838659db19704abd593bc91fd41c122e.camel@redhat.com> <033a8eae-9882-65ce-d7bf-f5df24006b59@redhat.com> Message-ID: <80d5b4da46466c08eb927caa0643e34cfedba3f5.camel@redhat.com> Hi Zhengyu, Hi Roman, > > > > Okay, updated: > > > http://cr.openjdk.java.net/~zgu/JDK-8245823/webrev.01/index.html > > > > > > -Zhengyu > > > > Looks good in general. > > > > + void register_thread_to_protocol(Thread* t); > > + void unregister_thread_to_protocol(Thread* t); > > > > It would have to be 'unregister_thread_from_protocol' but then I > > think > > we can just do 'register_thread' and 'unregister_thread' instead? > > > > Sure, will rename before push. > > > > Also, why not inline register_thread() and unregister_thread() too? > > Those appear to be the common paths in mutator-LRB, and should only > > account for a few instructions? > > This patch is really intended to address nesting scopes, to shred a > few > nano seconds from code root evacuation. I did not study barrier > cases, > so let's experiment that in separate CR, Okay? > Sure, ok then! Roman From shade at redhat.com Wed May 27 12:04:39 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 27 May 2020 12:04:39 +0000 Subject: hg: shenandoah/jdk11: 21 new changesets Message-ID: <202005271204.04RC4fFq004913@aojmv0008.oracle.com> Changeset: 568a1e923d62 Author: pli Date: 2020-01-15 13:24 +0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/568a1e923d62 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint Reviewed-by: aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp Changeset: 65ae87d8ea16 Author: ihse Date: 2020-05-19 13:55 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/65ae87d8ea16 8217404: --with-jvm-features doesn't work when multiple features are explicitly disabled Reviewed-by: vlivanov, kbarrett ! make/autoconf/hotspot.m4 Changeset: a0815b0dea2f Author: never Date: 2020-03-24 13:12 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/a0815b0dea2f 8241458: [JVMCI] add mark value to expose CodeOffsets::Frame_Complete Reviewed-by: kvn ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 31b293651039 Author: goetz Date: 2020-05-20 08:49 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/31b293651039 Merge Changeset: e59927e23d82 Author: phh Date: 2020-05-23 11:50 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/e59927e23d82 8245649: Revert 8245397 backport of 8230591 Summary: Revert 8245397 backport of 8230591 Reviewed-by: clanger ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp Changeset: 2ed4d6faf812 Author: kvn Date: 2019-01-14 13:45 -0800 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/2ed4d6faf812 8216151: [Graal] Module jdk.internal.vm.compiler.management has not been granted accessClassInPackage.org.graalvm.compiler.debug Summary: update default.policy based on latest changes in jdk.internal.vm.compiler.management Reviewed-by: thartmann, alanb, mchung ! src/java.base/share/lib/security/default.policy Changeset: ef0465dc6c1b Author: mbaesken Date: 2018-08-29 10:11 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/ef0465dc6c1b 8210147: adjust some WSAGetLastError usages in windows network coding Reviewed-by: clanger, stuefe ! src/java.base/windows/native/libnet/Inet4AddressImpl.c ! src/java.base/windows/native/libnet/Inet6AddressImpl.c ! src/java.base/windows/native/libnet/SocketInputStream.c Changeset: 344cbd1b4811 Author: joehw Date: 2020-04-10 17:00 +0000 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/344cbd1b4811 8242470: Update Xerces to Version 2.12.1 Reviewed-by: lancea, naoto ! src/java.xml/share/legal/xerces.md Changeset: 1eda161713ef Author: never Date: 2020-04-02 11:20 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/1eda161713ef 8191930: [Graal] emits unparseable XML into compile log Reviewed-by: kvn ! src/hotspot/share/compiler/compileTask.cpp Changeset: 13bbe01732af Author: dtitov Date: 2019-07-17 11:23 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/13bbe01732af 8206179: com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java fails with Committed virtual memory size illegal value Reviewed-by: sspitsyn, cjplummer ! test/jdk/com/sun/management/OperatingSystemMXBean/GetCommittedVirtualMemorySize.java Changeset: 034273afe17f Author: rhalade Date: 2020-04-30 15:21 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/034273afe17f 8225068: Remove DocuSign root certificate that is expiring in May 2020 Reviewed-by: mullan - make/data/cacerts/keynectisrootca ! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java Changeset: 8e1307b5901d Author: epavlova Date: 2019-06-12 12:31 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/8e1307b5901d 8225622: [AOT] runtime/SharedArchiveFile/TestInterpreterMethodEntries.java crashed with AOTed java.base Reviewed-by: kvn ! test/hotspot/jtreg/runtime/SharedArchiveFile/TestInterpreterMethodEntries.java Changeset: 330a9e3e79fc Author: eosterlund Date: 2019-02-05 20:06 +0100 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/330a9e3e79fc 8216541: CompiledICHolders of VM locked unloaded nmethods are released too late Reviewed-by: kvn, thartmann ! src/hotspot/share/code/compiledIC.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/compiledMethod.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/runtime/sweeper.cpp ! src/hotspot/share/runtime/sweeper.hpp Changeset: 098febb51a14 Author: mdoerr Date: 2020-05-19 15:11 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/098febb51a14 8245047: [PPC64] C2: ReverseBytes + Load always match to unordered Load (acquire semantics missing) Summary: Introduce separate nodes with acquire semantics which match ReverseBytes + Load.acquire. Reviewed-by: shade, lucy ! src/hotspot/cpu/ppc/ppc.ad Changeset: 794c8849eaa0 Author: erikj Date: 2020-05-14 06:58 -0700 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/794c8849eaa0 8244951: Missing entitlements for hardened runtime Reviewed-by: ihse ! make/common/NativeCompilation.gmk + make/data/macosxsigning/default.plist - make/data/macosxsigning/entitlements.plist + make/data/macosxsigning/java.plist + make/data/macosxsigning/jspawnhelper.plist Changeset: 7b57f54ddbcf Author: chagedorn Date: 2019-09-10 08:43 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/7b57f54ddbcf 8225653: Provide more information when hitting SIGILL from HaltNode Summary: Add information string for each HaltNode which is printed if hit at runtime. Reviewed-by: vlivanov, thartmann ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/main.cpp ! src/hotspot/share/adlc/output_c.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/rootnode.cpp ! src/hotspot/share/opto/rootnode.hpp Changeset: c053548bfc39 Author: chagedorn Date: 2019-10-10 10:27 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/c053548bfc39 8231720: Some perf regressions after 8225653 Summary: Fixed emitting of unused assembly code in 8225653??? which had a negative impact on performance in tight loops. Reviewed-by: kvn, thartmann ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 8df1a601187c Author: xliu Date: 2020-05-12 10:59 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/8df1a601187c 8022574: remove HaltNode code after uncommon trap calls Reviewed-by: thartmann, mdoerr, simonis ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/output_c.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/rootnode.cpp ! src/hotspot/share/opto/rootnode.hpp Changeset: 90ce1674f838 Author: goetz Date: 2020-05-27 09:33 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/90ce1674f838 Added tag jdk-11.0.8+5 for changeset 8df1a601187c ! .hgtags Changeset: e1b150e28f67 Author: shade Date: 2020-05-27 09:58 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/e1b150e28f67 Merge ! .hgtags ! make/autoconf/hotspot.m4 - make/data/cacerts/keynectisrootca - make/data/macosxsigning/entitlements.plist ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/share/adlc/output_c.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.hpp Changeset: 820874c60e61 Author: shade Date: 2020-05-27 09:58 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/820874c60e61 Added tag shenandoah-jdk-11.0.8+5 for changeset e1b150e28f67 ! .hgtags From zgu at redhat.com Wed May 27 12:57:21 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 May 2020 08:57:21 -0400 Subject: [15] RFR 8245827: Shenandoah: Cleanup Shenandoah code root iterators and root scanner In-Reply-To: <794a904c-80ec-e3e0-88af-761c4e1ea1e7@redhat.com> References: <794a904c-80ec-e3e0-88af-761c4e1ea1e7@redhat.com> Message-ID: <3b8ab62a-3cb9-ab28-c5c9-ffe0580da5f1@redhat.com> Hi Aleksey, >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245827 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245827/webrev.00/index.html > > Looks good! Thanks. > > For the code that is moved around, there were no actual semantic changes, right? I haven't checked > that part closely. > Other than moving code around, also de-templatized ShenandoahCodeRootIterator and ShenandoahRootScanner (which were the reasons to move code around). Okay? Thanks, -Zhengyu From shade at redhat.com Wed May 27 13:11:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 15:11:48 +0200 Subject: [15] RFR 8245827: Shenandoah: Cleanup Shenandoah code root iterators and root scanner In-Reply-To: <3b8ab62a-3cb9-ab28-c5c9-ffe0580da5f1@redhat.com> References: <794a904c-80ec-e3e0-88af-761c4e1ea1e7@redhat.com> <3b8ab62a-3cb9-ab28-c5c9-ffe0580da5f1@redhat.com> Message-ID: <0208e07a-2074-5022-a028-fe811838f01e@redhat.com> On 5/27/20 2:57 PM, Zhengyu Gu wrote: > Other than moving code around, also de-templatized > ShenandoahCodeRootIterator and ShenandoahRootScanner (which were the > reasons to move code around). > > Okay? Yes. -- Thanks, -Aleksey From zgu at redhat.com Wed May 27 14:56:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 May 2020 10:56:28 -0400 Subject: [15] RFR 8245880: Shenandoah: should not mark all code roots if class unloading is enabled Message-ID: <9f872145-316e-7b11-8edf-2819b203252b@redhat.com> Currently, concurrent code root scanning marks all code cache, no matter if class unloading is enabled, which is wrong. When class unloading is enabled, only on-stack code roots should be marked. Bug: https://bugs.openjdk.java.net/browse/JDK-8245880 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245880/webrev.00/ Test: hotspot_gc_shenandoah tier1 with Shenandoah Thanks, -Zhengyu From zgu at redhat.com Wed May 27 15:11:43 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 May 2020 11:11:43 -0400 Subject: [15] RFR 8245880: Shenandoah: should not mark all code roots if class unloading is enabled In-Reply-To: <9f872145-316e-7b11-8edf-2819b203252b@redhat.com> References: <9f872145-316e-7b11-8edf-2819b203252b@redhat.com> Message-ID: <6e9b9d5d-e10a-29f7-af27-45d8eb17d789@redhat.com> Sorry, seems that we check class unloading flag in concurrent_scan_code_roots(), which is not optimal, I will change synopsis and send out new webrev. Thanks, -Zhengyu On 5/27/20 10:56 AM, Zhengyu Gu wrote: > Currently, concurrent code root scanning marks all code cache, no matter > if class unloading is enabled, which is wrong. > > When class unloading is enabled, only on-stack code roots should be marked. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245880 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245880/webrev.00/ > > Test: > ? hotspot_gc_shenandoah > ? tier1 with Shenandoah > > > Thanks, > > -Zhengyu From shade at redhat.com Wed May 27 16:53:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 May 2020 18:53:37 +0200 Subject: RFR: 8245955: Shenandoah: Remove LRB/is_redundant optimization In-Reply-To: References: Message-ID: <2ce530e9-90a8-8876-5f15-b7e5d23e9e07@redhat.com> On 5/27/20 2:04 PM, Roman Kennke wrote: > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8245955/webrev.00/ It looks good. Let me run some targeted tests too. -- Thanks, -Aleksey From kdnilsen at amazon.com Wed May 27 20:15:49 2020 From: kdnilsen at amazon.com (Nilsen, Kelvin) Date: Wed, 27 May 2020 20:15:49 +0000 Subject: RFC: Instrumentation to Help Understand Shenandoah Performance and Latency Message-ID: <35BE8496-E5D7-420D-8E90-2C7A099A162C@amazon.com> In trying to understand Shenandoah performance under different workload conditions, it would be useful to have some additional GC logging output. Perhaps this is already available. Please let me know if there is a way to capture this information currently. The information that would be of value includes: 1. Number of GC pacing pauses imposed on thread A 2. Total number of accumulated ms of pacing pauses imposed on thread A 3. ?Number of "slow" paths taken through the reference load barrier for thread A. Of these: a) How many required thread A to copy the referenced object? b) How many total bytes of data were copied? c) How many times did thread A have to abandon its copy of the referenced object? d) How many total bytes of data were abandoned? 4. Can my application thread "know" about transitions between GC phases? Would be nice if a thread could ask : a) What is the sequence number of the most recently initiated GC cycle? b) What is the current phase of GC within this cycle? As I study performance of certain critical code components, I might want to ask at the start of the code for all of this information about a particular thread, and then ask for the relevant information updates at the of the critical code. For my purposes, these metrics are primarily for use during "research" on performance of particular workloads and of particular alternative GC implementation approaches. I would personally be satisfied if these metrics were only available in a JVM that is compiled "with instrumentation". Whether it might be appropriate to deploy "production releases" with this instrumentation in place would depend on how much performance overhead it incurs. I am suggesting that these metrics might be gathered on a per-thread basis to reduce synchronization overheads. The results of individual threads can be accumulated by user code when desired. Each thread accumulates its thread-local data into a global accumulator, using synchronization to coordinate access to the global accumulator. From mathiske at amazon.com Wed May 27 20:34:12 2020 From: mathiske at amazon.com (Mathiske, Bernd) Date: Wed, 27 May 2020 20:34:12 +0000 Subject: Instrumentation to Help Understand Shenandoah Performance and Latency In-Reply-To: <35BE8496-E5D7-420D-8E90-2C7A099A162C@amazon.com> References: <35BE8496-E5D7-420D-8E90-2C7A099A162C@amazon.com> Message-ID: <770104F3-98ED-479D-B694-0BE342E48C3F@amazon.com> Yes, that is a good idea. I like the specific data points. We probably need those data per interval, not just as totals. For extra credit, we could even output them as JMX metrics and show them in JMC and iGraph. But let's start with the GC log. I am finding that there is already some stuff there and that it is hinting at the right insertion points in some cases. See for example "ShenandoahAllocationTrace" and what it connects to. (Hehe, I am now reading Shen code top to bottom and came across this first as it's under A.) Bernd ?On 5/27/20, 1:15 PM, "Nilsen, Kelvin" wrote: In trying to understand Shenandoah performance under different workload conditions, it would be useful to have some additional GC logging output. Perhaps this is already available. Please let me know if there is a way to capture this information currently. The information that would be of value includes: 1. Number of GC pacing pauses imposed on thread A 2. Total number of accumulated ms of pacing pauses imposed on thread A 3. Number of "slow" paths taken through the reference load barrier for thread A. Of these: a) How many required thread A to copy the referenced object? b) How many total bytes of data were copied? c) How many times did thread A have to abandon its copy of the referenced object? d) How many total bytes of data were abandoned? 4. Can my application thread "know" about transitions between GC phases? Would be nice if a thread could ask : a) What is the sequence number of the most recently initiated GC cycle? b) What is the current phase of GC within this cycle? As I study performance of certain critical code components, I might want to ask at the start of the code for all of this information about a particular thread, and then ask for the relevant information updates at the of the critical code. For my purposes, these metrics are primarily for use during "research" on performance of particular workloads and of particular alternative GC implementation approaches. I would personally be satisfied if these metrics were only available in a JVM that is compiled "with instrumentation". Whether it might be appropriate to deploy "production releases" with this instrumentation in place would depend on how much performance overhead it incurs. I am suggesting that these metrics might be gathered on a per-thread basis to reduce synchronization overheads. The results of individual threads can be accumulated by user code when desired. Each thread accumulates its thread-local data into a global accumulator, using synchronization to coordinate access to the global accumulator. From gnu.andrew at redhat.com Thu May 28 06:43:38 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2020 07:43:38 +0100 Subject: [RFR] [8u] 8u262-b04 Upstream Sync Message-ID: <051aff48-3f65-8f0e-8643-c7bd5574a251@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b04: - JDK-8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() - JDK-8067796: (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null - JDK-8076475: Misuses of strncpy/strncat - JDK-8148886: SEGV in sun.java2d.marlin.Renderer._endRendering - JDK-8171934: ObjectSizeCalculator.getEffectiveMemoryLayoutSpecification() does not recognize OpenJDK's HotSpot VM - JDK-8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE - JDK-8243539: Copyright info (Year) should be updated for fix of 8241638 - JDK-8244777: ClassLoaderStats VM Op uses constant hash value Main issues of note: None, clean merge. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + b/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diffstat for jdk b/.hgtags | 1 b/make/CompileLaunchers.gmk | 2 b/src/macosx/bin/java_md_macosx.c | 2 b/src/share/bin/java.c | 2 b/src/share/classes/sun/java2d/ReentrantContext.java | 43 ++ b/src/share/classes/sun/java2d/ReentrantContextProvider.java | 169 ++++++++ b/src/share/classes/sun/java2d/ReentrantContextProviderCLQ.java | 89 ++++ b/src/share/classes/sun/java2d/ReentrantContextProviderTL.java | 123 ++++++ b/src/share/classes/sun/java2d/marlin/ByteArrayCache.java | 9 b/src/share/classes/sun/java2d/marlin/FloatArrayCache.java | 9 b/src/share/classes/sun/java2d/marlin/IntArrayCache.java | 9 b/src/share/classes/sun/java2d/marlin/MarlinCache.java | 6 b/src/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java | 76 +-- b/src/share/classes/sun/java2d/marlin/RendererContext.java | 31 - b/src/share/classes/sun/java2d/marlin/Version.java | 4 b/src/share/classes/sun/java2d/pipe/AAShapePipe.java | 141 +++--- b/src/share/classes/sun/security/util/DerInputStream.java | 48 +- b/src/share/classes/sun/security/util/DerValue.java | 4 b/src/share/classes/sun/security/util/ObjectIdentifier.java | 2 b/src/solaris/bin/java_md_solinux.c | 2 b/src/solaris/bin/java_md_solinux.h | 2 b/src/solaris/classes/java/lang/UNIXProcess.java | 3 b/src/windows/classes/java/lang/ProcessImpl.java | 3 b/test/java/lang/ProcessBuilder/Basic.java | 51 ++ b/test/java/security/cert/X509Certificate/X509BadCertificate.java | 5 b/test/java/security/cert/X509Certificate/bad-cert-2.pem | 21 + b/test/sun/java2d/marlin/CrashPaintTest.java | 205 ++++++++++ 27 files changed, 889 insertions(+), 173 deletions(-) diffstat for hotspot b/.hgtags | 1 b/agent/src/os/bsd/libproc_impl.c | 7 b/agent/src/os/linux/libproc_impl.c | 7 b/agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java | 7 b/src/os/bsd/dtrace/libjvm_db.c | 19 +- b/src/os/bsd/vm/decoder_machO.cpp | 1 b/src/os/solaris/dtrace/libjvm_db.c | 19 +- b/src/share/tools/hsdis/hsdis.c | 1 b/src/share/vm/classfile/classLoaderStats.hpp | 13 + b/src/share/vm/compiler/compileBroker.hpp | 3 b/src/share/vm/compiler/disassembler.cpp | 1 b/src/share/vm/runtime/arguments.cpp | 17 - b/src/share/vm/utilities/ostream.cpp | 12 - b/src/share/vm/utilities/vmError.cpp | 9 - b/test/serviceability/sa/ClhsdbJstackXcompStress.java | 107 ++++++++++++ b/test/serviceability/sa/LingeredAppWithRecComputation.java | 67 +++++++ 16 files changed, 244 insertions(+), 47 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Thu May 28 07:52:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 09:52:24 +0200 Subject: RFR: 8245955: Shenandoah: Remove LRB/is_redundant optimization In-Reply-To: <2ce530e9-90a8-8876-5f15-b7e5d23e9e07@redhat.com> References: <2ce530e9-90a8-8876-5f15-b7e5d23e9e07@redhat.com> Message-ID: On 5/27/20 6:53 PM, Aleksey Shipilev wrote: > On 5/27/20 2:04 PM, Roman Kennke wrote: >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8245955/webrev.00/ > > It looks good. Let me run some targeted tests too. I have no complaints. Good to go in. -- Thanks, -Aleksey From shade at redhat.com Thu May 28 08:28:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 10:28:39 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b04 Upstream Sync In-Reply-To: <051aff48-3f65-8f0e-8643-c7bd5574a251@redhat.com> References: <051aff48-3f65-8f0e-8643-c7bd5574a251@redhat.com> Message-ID: <7b1b6f4b-c942-0609-5db9-80d1d4ae49c3@redhat.com> On 5/28/20 8:43 AM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/corba/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxp/merge.changeset Looks good. I notice separately that "jaxp" apparently has the tag: aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 ...that no other repos have? > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxws/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/langtools/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/nashorn/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/root/merge.changeset Looks good. > Ok to push? Yes. -- Thanks, -Aleksey From shade at redhat.com Thu May 28 10:11:30 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 12:11:30 +0200 Subject: [11] 2020-05-28, Bulk backports to sh/jdk11 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200528/webrev.01/ This backports a few easy changes to sh/jdk11: [backport] 8245812: Shenandoah: compute root phase parallelism [backport] 8245814: Shenandoah: reconsider format specifiers for stats [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch [backport] 8245461: Shenandoah: refine mode name()-s [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties [backport] 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From shade at redhat.com Thu May 28 10:14:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 12:14:02 +0200 Subject: [8] 2020-05-28, Bulk backports to sh/jdk8 Message-ID: https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200528/webrev.01/ This backports a few easy changes to sh/jdk8: [backport] 8245812: Shenandoah: compute root phase parallelism [backport] 8245814: Shenandoah: reconsider format specifiers for stats [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch [backport] 8245461: Shenandoah: refine mode name()-s [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties [backport] 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Thu May 28 10:21:20 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 28 May 2020 12:21:20 +0200 Subject: [11] 2020-05-28, Bulk backports to sh/jdk11 In-Reply-To: References: Message-ID: <3c0ba99599b38e5a54195cf9d2c601a17d11c74a.camel@redhat.com> Yes, looks good! Thank you! Roman On Thu, 2020-05-28 at 12:11 +0200, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk11-20200528/webrev.01/ > > This backports a few easy changes to sh/jdk11: > [backport] 8245812: Shenandoah: compute root phase parallelism > [backport] 8245814: Shenandoah: reconsider format specifiers for > stats > [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings > constructor arguments > [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch > [backport] 8245461: Shenandoah: refine mode name()-s > [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics > names and properties > [backport] 8245825: Shenandoah: Remove diagnostic flag > ShenandoahConcurrentScanCodeRoots > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From rkennke at redhat.com Thu May 28 10:22:42 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 28 May 2020 12:22:42 +0200 Subject: [8] 2020-05-28, Bulk backports to sh/jdk8 In-Reply-To: References: Message-ID: <23105ebfce09b55e04f079439ae5f0b026ab5afa.camel@redhat.com> Looks good! Thank you! Roman On Thu, 2020-05-28 at 12:14 +0200, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/backports/jdk8u-20200528/webrev.01/ > > This backports a few easy changes to sh/jdk8: > [backport] 8245812: Shenandoah: compute root phase parallelism > [backport] 8245814: Shenandoah: reconsider format specifiers for > stats > [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings > constructor arguments > [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch > [backport] 8245461: Shenandoah: refine mode name()-s > [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics > names and properties > [backport] 8245825: Shenandoah: Remove diagnostic flag > ShenandoahConcurrentScanCodeRoots > > Testing: hotspot_gc_shenandoah {fastdebug,release} > From shade at redhat.com Thu May 28 10:25:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 12:25:06 +0200 Subject: [11] 2020-05-28, Bulk backports to sh/jdk11 In-Reply-To: <3c0ba99599b38e5a54195cf9d2c601a17d11c74a.camel@redhat.com> References: <3c0ba99599b38e5a54195cf9d2c601a17d11c74a.camel@redhat.com> Message-ID: On 5/28/20 12:21 PM, Roman Kennke wrote: > Yes, looks good! Thank you! Cheers, pushed. -- -Aleksey From shade at redhat.com Thu May 28 10:25:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 12:25:23 +0200 Subject: [8] 2020-05-28, Bulk backports to sh/jdk8 In-Reply-To: <23105ebfce09b55e04f079439ae5f0b026ab5afa.camel@redhat.com> References: <23105ebfce09b55e04f079439ae5f0b026ab5afa.camel@redhat.com> Message-ID: <983b07ea-2503-60ef-bb60-24576c15aa93@redhat.com> On 5/28/20 12:22 PM, Roman Kennke wrote: > Looks good! Thank you! Cheers, pushed. -- -Aleksey From shade at redhat.com Thu May 28 10:24:23 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 28 May 2020 10:24:23 +0000 Subject: hg: shenandoah/jdk11: 7 new changesets Message-ID: <202005281024.04SAOOUC003371@aojmv0008.oracle.com> Changeset: be19eefd995f Author: shade Date: 2020-05-27 09:22 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/be19eefd995f [backport] 8245812: Shenandoah: compute root phase parallelism Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Changeset: bc9bf08f6152 Author: shade Date: 2020-05-27 15:57 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/bc9bf08f6152 [backport] 8245814: Shenandoah: reconsider format specifiers for stats Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp Changeset: b3bd470317e3 Author: shade Date: 2020-05-20 15:24 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/b3bd470317e3 [backport] 8245463: Shenandoah: refine ShenandoahPhaseTimings constructor arguments Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp Changeset: 8238805e04e8 Author: shade Date: 2020-05-26 09:30 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/8238805e04e8 [backport] 8245754: Shenandoah: ditch ShenandoahAlwaysPreTouch Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 5b07ffca85b7 Author: shade Date: 2020-05-20 15:24 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/5b07ffca85b7 [backport] 8245461: Shenandoah: refine mode name()-s Reviewed-by: zgu ! src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.hpp ! src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.hpp Changeset: 266d026bbe8d Author: shade Date: 2020-05-26 09:30 +0200 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/266d026bbe8d [backport] 8245726: Shenandoah: lift/cleanup ShenandoahHeuristics names and properties Reviewed-by: rkennke ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.hpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp Changeset: b389c86379ca Author: zgu Date: 2020-05-27 08:53 -0400 URL: https://hg.openjdk.java.net/shenandoah/jdk11/rev/b389c86379ca [backport] 8245825: Shenandoah: Remove diagnostic flag ShenandoahConcurrentScanCodeRoots Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp From zgu at redhat.com Thu May 28 16:14:21 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 28 May 2020 12:14:21 -0400 Subject: RFR (S) 8245478: Implementation: JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production) In-Reply-To: References: <686d1fcf-01b0-0722-9a2e-f54ad9656d61@redhat.com> Message-ID: Looks good to me too. Thanks, -Zhengyu On 5/27/20 7:21 AM, Roman Kennke wrote: > Looks good to me! > > Thanks, > Roman > > On Wed, 2020-05-27 at 11:30 +0200, Aleksey Shipilev wrote: >> Hi, >> >> JEP: https://openjdk.java.net/jeps/379 >> Impl: https://bugs.openjdk.java.net/browse/JDK-8245478 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8245479 >> >> Webrev: >> https://cr.openjdk.java.net/~shade/8245478/webrev.01/ >> >> Along with flag changes, I also enabled back the tests that assume >> Shenandoah is "product", like we >> have in sh/jdk11 and sh/jdk8 trees. >> >> Testing: hotspot_gc_shenandoah >> > From zgu at redhat.com Thu May 28 16:20:11 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 28 May 2020 12:20:11 -0400 Subject: RFR (S) 8245942: Shenandoah: x86_32 builds fail after JDK-8245594 In-Reply-To: References: Message-ID: <6907275a-91a2-e3f4-4ae3-e40fc5b98220@redhat.com> Good to me. -Zhengyu On 5/27/20 8:04 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8245942 > > JDK-8245594 removed some volatile-qualified members, so now x86_32 build fails. I believe we just > turn the affected classes trivially copyable as well, like it was done for ShenandoahVerifierTask in > JDK-8245594. > > Fix: > https://cr.openjdk.java.net/~shade/8245942/webrev.01/ > > Kim, does that match original intent with JDK-8245594? > > Testing: hotspot_gc_shenandoah {x86_64, x86_32} > From shade at redhat.com Thu May 28 17:06:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 19:06:01 +0200 Subject: RFR (S) 8245478: Implementation: JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production) In-Reply-To: References: <686d1fcf-01b0-0722-9a2e-f54ad9656d61@redhat.com> Message-ID: <50fa55a5-9ab7-729e-13a2-aa0271f92182@redhat.com> Thanks! Pushed. On 5/28/20 6:14 PM, Zhengyu Gu wrote: > Looks good to me too. > > Thanks, > > On 5/27/20 7:21 AM, Roman Kennke wrote: >> Looks good to me! >> >> On Wed, 2020-05-27 at 11:30 +0200, Aleksey Shipilev wrote: >>> JEP: https://openjdk.java.net/jeps/379 >>> Impl: https://bugs.openjdk.java.net/browse/JDK-8245478 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8245479 >>> >>> Webrev: >>> https://cr.openjdk.java.net/~shade/8245478/webrev.01/ -- -Aleksey From shade at redhat.com Thu May 28 17:07:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 19:07:06 +0200 Subject: RFR (S) 8245942: Shenandoah: x86_32 builds fail after JDK-8245594 In-Reply-To: <6907275a-91a2-e3f4-4ae3-e40fc5b98220@redhat.com> References: <6907275a-91a2-e3f4-4ae3-e40fc5b98220@redhat.com> Message-ID: <07746416-42b4-4111-4b4b-70ae819b2f8b@redhat.com> On 5/28/20 6:20 PM, Zhengyu Gu wrote: > Good to me. Thanks, pushed. >> Kim, does that match original intent with JDK-8245594? Kim, if you think that was incorrect, ping me. -- Thanks, -Aleksey From kim.barrett at oracle.com Thu May 28 22:21:03 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 28 May 2020 18:21:03 -0400 Subject: RFR (S) 8245942: Shenandoah: x86_32 builds fail after JDK-8245594 In-Reply-To: <07746416-42b4-4111-4b4b-70ae819b2f8b@redhat.com> References: <6907275a-91a2-e3f4-4ae3-e40fc5b98220@redhat.com> <07746416-42b4-4111-4b4b-70ae819b2f8b@redhat.com> Message-ID: <58393A62-2529-46F0-80AC-88CB7C7466F5@oracle.com> > On May 28, 2020, at 1:07 PM, Aleksey Shipilev wrote: > > On 5/28/20 6:20 PM, Zhengyu Gu wrote: >> Good to me. > > Thanks, pushed. > >>> Kim, does that match original intent with JDK-8245594? > > Kim, if you think that was incorrect, ping me. Sorry for not noticing this thread sooner. And for not noticing the problem in the first place. Yes, this looks fine. From raell at web.de Fri May 29 00:17:03 2020 From: raell at web.de (raell at web.de) Date: Fri, 29 May 2020 02:17:03 +0200 Subject: Concurrent marking of root objects Message-ID: Hi, this isn't a real question, but more kind of an idea. After Shenandoah has made evacuation of root objects concurrent in JDK 14, I wonder if it shouldn't be possible to mark root objects concurrently, as well? To my understanding, the SATB barrier is already able to detect reference changes on root objects. So, at least from the SATB barrier point of view, it shouldn't be much of a difference if root objects are marked in a STW phase or concurrently. Regards Ralph From zgu at redhat.com Fri May 29 00:47:40 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 28 May 2020 20:47:40 -0400 Subject: Concurrent marking of root objects In-Reply-To: References: Message-ID: Hi Ralph, I am working on moving some root marking into concurrent phase. https://bugs.openjdk.java.net/browse/JDK-8245961 ZGC also has concurrent thread stack marking (https://github.com/openjdk/zgc/commit/d9abea0cc6df148a3781600dfe6bfcc1a4a1873c#diff-a6bc76531aecc703472f887d4e162b94), hopefully, will mature in near future. After that, remaining STW roots are quite small. -Zhengyu On 5/28/20 8:17 PM, raell at web.de wrote: > Hi, > > this isn't a real question, but more kind of an idea. After Shenandoah has made evacuation > of root objects concurrent in JDK 14, I wonder if it shouldn't be possible to mark root > objects concurrently, as well? To my understanding, the SATB barrier is already able > to detect reference changes on root objects. So, at least from the SATB barrier point of view, > it shouldn't be much of a difference if root objects are marked in a STW phase or concurrently. > > Regards > Ralph > From shade at redhat.com Fri May 29 07:01:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 29 May 2020 09:01:04 +0200 Subject: RFR (S) 8245942: Shenandoah: x86_32 builds fail after JDK-8245594 In-Reply-To: <58393A62-2529-46F0-80AC-88CB7C7466F5@oracle.com> References: <6907275a-91a2-e3f4-4ae3-e40fc5b98220@redhat.com> <07746416-42b4-4111-4b4b-70ae819b2f8b@redhat.com> <58393A62-2529-46F0-80AC-88CB7C7466F5@oracle.com> Message-ID: <6f3d398c-6327-7f76-8f9a-f9451baed271@redhat.com> On 5/29/20 12:21 AM, Kim Barrett wrote: >> On May 28, 2020, at 1:07 PM, Aleksey Shipilev wrote: >>>> Kim, does that match original intent with JDK-8245594? >> >> Kim, if you think that was incorrect, ping me. > > Sorry for not noticing this thread sooner. And for not noticing the problem > in the first place. Yes, this looks fine. Thanks! The failure is quite obscure, TBH, and not detectable in most configs, so no hard feelings. -- -Aleksey From shade at redhat.com Fri May 29 07:15:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 29 May 2020 09:15:14 +0200 Subject: Shenandoah 11.0.8+ release candidate Message-ID: Hi, We are pleased to announce that most of the recent bugfixes and improvements have been backported to Shenandoah 11u tree. That tree is based on upstream OpenJDK 11.0.8+ project, and Shenandoah-enabled downstream distributions should be released at the same time with 11.0.8 release, in mid-July. Since we do not expect very active 11u work until that release happens, what we have in Shenandoah 11u tree is now the Release Candidate. Please test! Next 1..3 weeks are the perfect time to identify problems with it and put in critical fixes that would land in July release. As usual, you can try it by: a) Building from source yourself: https://hg.openjdk.java.net/shenandoah/jdk11/ b) Taking our nightly builds: https://builds.shipilev.net/openjdk-shenandoah-jdk11/ c) Using the Docker containers with nightly builds: shipilev/openjdk-shenandoah:11 Enjoy! -- Thanks, -Aleksey From shade at redhat.com Fri May 29 07:23:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 29 May 2020 09:23:12 +0200 Subject: Shenandoah JDK15 status: not experimental anymore Message-ID: <8d4464fb-004f-fbf3-2356-f2dc4b018740@redhat.com> Hi, We are pleased to announce that JEP 379 [1] was integrated into jdk/jdk (which would soon fork to JDK 15), and therefore Shenandoah is no longer formally experimental in head JDKs. As mentioned in JEP 379, it does not affect Shenandoah 11u and 8u backports, where the same JVM options were already non-experimental. This is already in our nightlies: $ curl https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-latest-linux-x86_64-release.tar.xz | tar xJf - $ jdk/bin/java -XX:+UseShenandoahGC -Xlog:gc -version [0.003s][info][gc] Using Shenandoah $ docker run --rm -it shipilev/openjdk java -XX:+UseShenandoahGC -Xlog:gc -version [0.003s][info][gc] Using Shenandoah Enjoy! -- Thanks, -Aleksey [1] https://openjdk.java.net/jeps/379 From zgu at redhat.com Fri May 29 12:21:42 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 29 May 2020 08:21:42 -0400 Subject: [15] RFR 8245880: Shenandoah: check class unloading flag early in concurrent code root scan In-Reply-To: <9f872145-316e-7b11-8edf-2819b203252b@redhat.com> References: <9f872145-316e-7b11-8edf-2819b203252b@redhat.com> Message-ID: <6c52b179-5b1f-2bb0-a287-76a088484571@redhat.com> Please review this minor improvement. If class unloading is enabled, there is no need to claim code cache. Bug: https://bugs.openjdk.java.net/browse/JDK-8245880 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245880/webrev.01/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From raell at web.de Fri May 29 15:18:25 2020 From: raell at web.de (raell at web.de) Date: Fri, 29 May 2020 17:18:25 +0200 Subject: Concurrent marking of root objects In-Reply-To: References: Message-ID: Hi Zhengyu, cool. Thank you very much for the information. Regards Ralph ? ? On 5/29/20 8:47 PM, zgu at redhat.com wrote: > Hi Ralph, > > I am working on moving some root marking into concurrent phase. > https://bugs.openjdk.java.net/browse/JDK-8245961 > > ZGC also has concurrent thread stack marking > (https://github.com/openjdk/zgc/commit/d9abea0cc6df148a3781600dfe6bfcc1a4a1873c#diff-a6bc76531aecc703472f887d4e162b94[https://github.com/openjdk/zgc/commit/d9abea0cc6df148a3781600dfe6bfcc1a4a1873c#diff-a6bc76531aecc703472f887d4e162b94]), > hopefully, will mature in near future. > > After that, remaining STW roots are quite small. > -Zhengyu > On 5/28/20 8:17 PM, raell at web.de wrote: >> Hi, >> >> this isn't a real question, but more kind of an idea. After Shenandoah has made evacuation >> of root objects concurrent in JDK 14, I wonder if it shouldn't be possible to mark root >> objects concurrently, as well? To my understanding, the SATB barrier is already able >> to detect reference changes on root objects. So, at least from the SATB barrier point of view, >> it shouldn't be much of a difference if root objects are marked in a STW phase or concurrently. >> >> Regards >> Ralph >> ? From zgu at redhat.com Fri May 29 16:57:13 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 29 May 2020 12:57:13 -0400 Subject: [15] RFR 8246162: Shenandoah: full GC does not mark code roots when class unloading is off Message-ID: When class unloading is off, Shenandoah should mark through code roots. In normal cycle, this is done during concurrent marking phase. However, full GC does not execute concurrent marking phase, we should piggyback code root marking in final mark. Bug: https://bugs.openjdk.java.net/browse/JDK-8246162 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246162/webrev.00/ Test: hotspot_gc_shenandoah Thanks, -Zhengyu From shade at redhat.com Fri May 29 17:10:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 29 May 2020 19:10:02 +0200 Subject: [15] RFR 8246162: Shenandoah: full GC does not mark code roots when class unloading is off In-Reply-To: References: Message-ID: <32aa1536-d863-2daa-551d-f8bf627c1e3e@redhat.com> On 5/29/20 6:57 PM, Zhengyu Gu wrote: > When class unloading is off, Shenandoah should mark through code roots. > In normal cycle, this is done during concurrent marking phase. However, > full GC does not execute concurrent marking phase, we should piggyback > code root marking in final mark. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246162 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8246162/webrev.00/ Looks good! -- Thanks, -Aleksey From shade at redhat.com Fri May 29 17:11:29 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 29 May 2020 19:11:29 +0200 Subject: [15] RFR 8245880: Shenandoah: check class unloading flag early in concurrent code root scan In-Reply-To: <6c52b179-5b1f-2bb0-a287-76a088484571@redhat.com> References: <9f872145-316e-7b11-8edf-2819b203252b@redhat.com> <6c52b179-5b1f-2bb0-a287-76a088484571@redhat.com> Message-ID: <922680cd-fee8-4b9b-1c81-3c254c245c7e@redhat.com> On 5/29/20 2:21 PM, Zhengyu Gu wrote: > Please review this minor improvement. If class unloading is enabled, > there is no need to claim code cache. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245880 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8245880/webrev.01/ Looks good! -- Thanks, -Aleksey From gnu.andrew at redhat.com Fri May 29 18:43:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 29 May 2020 19:43:10 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b04 Upstream Sync In-Reply-To: <7b1b6f4b-c942-0609-5db9-80d1d4ae49c3@redhat.com> References: <051aff48-3f65-8f0e-8643-c7bd5574a251@redhat.com> <7b1b6f4b-c942-0609-5db9-80d1d4ae49c3@redhat.com> Message-ID: <7eaa7483-afd2-ced8-439f-ebada44ef0fe@redhat.com> On 28/05/2020 09:28, Aleksey Shipilev wrote: > On 5/28/20 8:43 AM, Andrew Hughes wrote: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/corba/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxp/merge.changeset > > Looks good. I notice separately that "jaxp" apparently has the tag: > aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 > > ...that no other repos have? > They all have it (it's the first tag for the recent Shenandoah merge), but it's (rightly) placed below aarch64-shenandoah-jdk8u262-b02 in the other repos. Is Mercurial the only VCS where you have to manually merge such metadata? I'll push this and fix that up in the merge of b05. 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