From tschatzl at openjdk.java.net Wed Jun 1 10:56:39 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 1 Jun 2022 10:56:39 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? > > Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. > > G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. > The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://doi.org/10.1145%2F1029873.1029879)). > > This mechanism has several drawbacks: > > * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage > * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region > > The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". > > That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. > > This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: > > * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. > * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://github.com/openjdk/jdk/pull/8884) and exploited in this change. This removes a few 100 LOC of changes :) > > Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. > > Let me describe the relation of tams and pb during the various phases in gc: > > Young-only gcs (and initial state): > `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap > > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ > | > tams, pb, tars > > During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. > Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ > | | > pb tams > > From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. > > Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. > > Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. > Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ ^ > | | | > tams pb (tars) > > As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. > > Evacuation failure handling: evacuation failure handling has been modified to accomodate this: > > * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. > * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. > > Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. > > Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: ayang review2; more cleanup of unnecessary changes, asserts ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8957/files - new: https://git.openjdk.java.net/jdk/pull/8957/files/331fb52c..d3a7a96f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8957&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8957&range=01-02 Stats: 44 lines in 4 files changed: 1 ins; 11 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/8957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8957/head:pull/8957 PR: https://git.openjdk.java.net/jdk/pull/8957 From duke at openjdk.java.net Wed Jun 1 12:50:10 2022 From: duke at openjdk.java.net (tqxia) Date: Wed, 1 Jun 2022 12:50:10 GMT Subject: RFR: 8287558: Remove remset coarsening stats during g1 remset summary printing Message-ID: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> Remset summary printing prints coarsening statistics in addition to remset summaries; that information is either duplicated with "Coarsening (recent)" printouts (with gc+remset=debug) at GC start or all-zeros at GC end. Given that Remset summary printing is enabled with gc+remset=trace which covers the recent/all coarsening statistics, the coarsening statistics during remset summary are somewhat duplicate (or useless for the after-gc one). Remove the coarsening statistics from the remset summaries. ------------- Commit messages: - 8287558: Remove remset coarsening stats during g1 remset summary printing Changes: https://git.openjdk.java.net/jdk/pull/8971/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8971&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287558 Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8971.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8971/head:pull/8971 PR: https://git.openjdk.java.net/jdk/pull/8971 From duke at openjdk.java.net Wed Jun 1 13:03:34 2022 From: duke at openjdk.java.net (tqxia) Date: Wed, 1 Jun 2022 13:03:34 GMT Subject: RFR: 8287558: Remove remset coarsening stats during g1 remset summary printing In-Reply-To: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> References: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> Message-ID: On Wed, 1 Jun 2022 12:43:38 GMT, tqxia wrote: > Remset summary printing prints coarsening statistics in addition to remset summaries; that information is either duplicated with "Coarsening (recent)" printouts (with gc+remset=debug) at GC start or all-zeros at GC end. > > Given that Remset summary printing is enabled with gc+remset=trace which covers the recent/all coarsening statistics, the coarsening statistics during remset summary are somewhat duplicate (or useless for the after-gc one). > > Remove the coarsening statistics from the remset summaries. I think "Concurrent refinement threads times" and "Sampling task time" in "After GC RS summary" also have similar issues: they are all-zeros because the data does not get changed in the last GC cycle. A possible way to fix this adding an additional flag to differentiate between "Before GC RS summary" and "After GC RS summary", I can include this fix in the current PR, if that is OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/8971 From iwalulya at openjdk.java.net Wed Jun 1 15:30:26 2022 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Wed, 1 Jun 2022 15:30:26 GMT Subject: RFR: 8278598: AlignmentReserve is repeatedly reinitialized In-Reply-To: References: Message-ID: On Fri, 20 May 2022 12:54:33 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes initialization of `AlignmentReserve` a one-time thing; after looking at the suggested change and the code I opted to use a static in `CollectedHeap` that can be queried by its users (`PLAB` and `ThreadLocalAllocBuffer`). This seemed nicer to me. > > Testing: gha, running gcbasher with all collectors (notice that there is an assert in the getter that checks for initialization before retrieval, so this should be sufficient) > > Thanks, > Thomas Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8808 From daniel.daugherty at oracle.com Wed Jun 1 17:43:59 2022 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 1 Jun 2022 13:43:59 -0400 Subject: Concurrent heap monitoring In-Reply-To: <1653689549469.91000@amazon.com> References: <1653083191904.40109@amazon.com> <1653689549469.91000@amazon.com> Message-ID: <857be0fe-c8c9-fcaf-d5ed-28a2655252e6@oracle.com> Hi William, How does this proposal interact with JVM/TI or with: ??? JEP 331: Low-Overhead Heap Profiling http://openjdk.java.net/jeps/331 ??? JDK-8171119 JEP 331: Low-Overhead Heap Profiling https://bugs.openjdk.java.net/browse/JDK-8171119 ??? JDK-8203394 Implementation of JEP 331: Low-Overhead Heap Profiling https://bugs.openjdk.java.net/browse/JDK-8203394 Dan On 5/27/22 6:12 PM, Kemper, William wrote: > > The feature is independent from GCs, but it is aware of GC activity > and it may be preempted by the GC at any time (which causes the loss > of any work in progress). We have only tested it with G1, but we > expect it to work with Parallel and Serial collectors. It is meant to > stay out of the way of GC, but?it is not yet aware of the?concurrent > phases of G1, Shenandoah and ZGC, so there is more work to be done here. > > > Thank you for the questions, > > William > > > ------------------------------------------------------------------------ > *From:* Volker Simonis > *Sent:* Saturday, May 21, 2022 12:49 AM > *To:* Kemper, William > *Cc:* serviceability-dev > *Subject:* RE: [EXTERNAL]Concurrent heap monitoring > > *CAUTION*: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > This sounds very interesting. Does this feature work with every GC or? > does the implementation depend on specific GCs (and if the latter, > which GCs does your prototype currently support). > > Kemper, William schrieb am Fr., 20. Mai 2022, 23:46: > > Taking a heap dump is a stop the world event. Garbage collection > events can provide heap utilization information only after a cycle > completes. We've found that detailed heap occupancy data (such as > heap inspections provide) are too expensive to use for production > monitoring.? Similarly, we find that heap statistics generated > from collection cycles?may come too late and may not provide > enough detail (young collections do not reflect the state of the > old generation). We have developed a /prototype/ feature to > provide detailed heap metrics /concurrently//, without barriers./ > It therefore provides only an estimate as changes to the object > graph may cause it to miss objects. We would like to hear the > thoughts of serviceability experts on such a thing. It is only at > the proof of concept phase, but it is able to run popular > benchmarks (specjbb, dacapo) with minimal overhead and the > estimates are sufficiently accurate for our use cases (monitoring > heap and object?growth rates). > > > Thank you for reading, > > William > From manc at openjdk.java.net Thu Jun 2 00:46:46 2022 From: manc at openjdk.java.net (Man Cao) Date: Thu, 2 Jun 2022 00:46:46 GMT Subject: RFR: 8287704: Small logging clarification about shrunk bytes after heap shrinkage Message-ID: Hi all, Could anyone review this minor improvement on logging, about heap shrinkage? I'm sponsoring colleague Jonathan Joo for this change. ------------- Commit messages: - Merge branch 'master' into JDK-8287704 - 8287704: Small logging clarification about shrunk bytes after heap shrinkage Changes: https://git.openjdk.java.net/jdk/pull/8983/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8983&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287704 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8983.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8983/head:pull/8983 PR: https://git.openjdk.java.net/jdk/pull/8983 From tschatzl at openjdk.java.net Thu Jun 2 13:10:34 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 2 Jun 2022 13:10:34 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v4] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? > > Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. > > G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. > The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://doi.org/10.1145%2F1029873.1029879)). > > This mechanism has several drawbacks: > > * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage > * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region > > The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". > > That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. > > This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: > > * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. > * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://github.com/openjdk/jdk/pull/8884) and exploited in this change. This removes a few 100 LOC of changes :) > > Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. > > Let me describe the relation of tams and pb during the various phases in gc: > > Young-only gcs (and initial state): > `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap > > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ > | > tams, pb, tars > > During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. > Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ > | | > pb tams > > From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. > > Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. > > Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. > Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ ^ > | | | > tams pb (tars) > > As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. > > Evacuation failure handling: evacuation failure handling has been modified to accomodate this: > > * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. > * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. > > Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. > > Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: ayang, iwalulya review: cleanups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8957/files - new: https://git.openjdk.java.net/jdk/pull/8957/files/d3a7a96f..281633d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8957&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8957&range=02-03 Stats: 63 lines in 9 files changed: 11 ins; 16 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/8957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8957/head:pull/8957 PR: https://git.openjdk.java.net/jdk/pull/8957 From tschatzl at openjdk.java.net Thu Jun 2 13:18:22 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 2 Jun 2022 13:18:22 GMT Subject: RFR: 8287704: Small logging clarification about shrunk bytes after heap shrinkage In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 00:39:01 GMT, Man Cao wrote: > Hi all, > > Could anyone review this minor improvement on logging, about heap shrinkage? I'm sponsoring colleague Jonathan Joo for this change. Lgtm ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8983 From tschatzl at openjdk.java.net Thu Jun 2 13:18:24 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 2 Jun 2022 13:18:24 GMT Subject: RFR: 8287558: Remove remset coarsening stats during g1 remset summary printing In-Reply-To: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> References: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> Message-ID: On Wed, 1 Jun 2022 12:43:38 GMT, tqxia wrote: > Remset summary printing prints coarsening statistics in addition to remset summaries; that information is either duplicated with "Coarsening (recent)" printouts (with gc+remset=debug) at GC start or all-zeros at GC end. > > Given that Remset summary printing is enabled with gc+remset=trace which covers the recent/all coarsening statistics, the coarsening statistics during remset summary are somewhat duplicate (or useless for the after-gc one). > > Remove the coarsening statistics from the remset summaries. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8971 From zgu at openjdk.java.net Thu Jun 2 16:30:53 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 2 Jun 2022 16:30:53 GMT Subject: RFR: 8287686: Add assertion to ensure that disarm value offset < 128 Message-ID: Please review this trivial patch to ensure disarm value offset is less than 128. At least on x86_64, nmethod entry barrier encodes disarmed value offset as disp8 immed, overflowing the value can result crashes, see [JDK-8244420](https://bugs.openjdk.java.net/browse/JDK-8244420) for details. Test: - [x] jdk_loom and hotspot_loom on Linux x86_64 ------------- Commit messages: - 8287686: Add assertion to ensure that disarm value offset < 128 Changes: https://git.openjdk.java.net/jdk/pull/8977/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8977&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287686 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8977.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8977/head:pull/8977 PR: https://git.openjdk.java.net/jdk/pull/8977 From tschatzl at openjdk.java.net Thu Jun 2 17:19:39 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 2 Jun 2022 17:19:39 GMT Subject: RFR: 8278598: AlignmentReserve is repeatedly reinitialized In-Reply-To: References: Message-ID: <2W2G5-KTUiZQ_QaBDOANhfxWzQ_1ZGjfUmmMCozMgzA=.be87ec8f-df68-4676-90eb-b6c8e78b8992@github.com> On Wed, 1 Jun 2022 15:26:30 GMT, Ivan Walulya wrote: >> Hi all, >> >> can I have reviews for this change that makes initialization of `AlignmentReserve` a one-time thing; after looking at the suggested change and the code I opted to use a static in `CollectedHeap` that can be queried by its users (`PLAB` and `ThreadLocalAllocBuffer`). This seemed nicer to me. >> >> Testing: gha, running gcbasher with all collectors (notice that there is an assert in the getter that checks for initialization before retrieval, so this should be sufficient) >> >> Thanks, >> Thomas > > Lgtm! Thanks @walulyai @albertnetymk for your reviews ------------- PR: https://git.openjdk.java.net/jdk/pull/8808 From tschatzl at openjdk.java.net Thu Jun 2 17:19:40 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 2 Jun 2022 17:19:40 GMT Subject: Integrated: 8278598: AlignmentReserve is repeatedly reinitialized In-Reply-To: References: Message-ID: On Fri, 20 May 2022 12:54:33 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes initialization of `AlignmentReserve` a one-time thing; after looking at the suggested change and the code I opted to use a static in `CollectedHeap` that can be queried by its users (`PLAB` and `ThreadLocalAllocBuffer`). This seemed nicer to me. > > Testing: gha, running gcbasher with all collectors (notice that there is an assert in the getter that checks for initialization before retrieval, so this should be sufficient) > > Thanks, > Thomas This pull request has now been integrated. Changeset: 1fcbaa41 Author: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/1fcbaa411628c46ca6980942b6f6a5ef7062e16f Stats: 37 lines in 5 files changed: 15 ins; 14 del; 8 mod 8278598: AlignmentReserve is repeatedly reinitialized Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.java.net/jdk/pull/8808 From manc at openjdk.java.net Thu Jun 2 18:14:41 2022 From: manc at openjdk.java.net (Man Cao) Date: Thu, 2 Jun 2022 18:14:41 GMT Subject: Integrated: 8287704: Small logging clarification about shrunk bytes after heap shrinkage In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 00:39:01 GMT, Man Cao wrote: > Hi all, > > Could anyone review this minor improvement on logging, about heap shrinkage? I'm sponsoring colleague Jonathan Joo for this change. This pull request has now been integrated. Changeset: ccec5d1e Author: Man Cao URL: https://git.openjdk.java.net/jdk/commit/ccec5d1e8529c8211cc678d8acc8d37fe461cb51 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8287704: Small logging clarification about shrunk bytes after heap shrinkage Co-authored-by: Jonathan Joo Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/8983 From zgu at openjdk.java.net Thu Jun 2 19:17:54 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 2 Jun 2022 19:17:54 GMT Subject: RFR: 8287734: Shenandoah: Consolidate marking closures Message-ID: Shenandoah used to have different marking closures that mark metadata or not. With Loom, marking closures always mark metadata, so they can be consolidated. Test: - [x] hotspot_gc_shenandoah - [x] jdk_loom + ShenandoahGC - [x] hotspot_loom + ShenandoahGC ------------- Commit messages: - Update - v0 Changes: https://git.openjdk.java.net/jdk/pull/9000/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9000&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287734 Stats: 46 lines in 2 files changed: 0 ins; 39 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/9000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9000/head:pull/9000 PR: https://git.openjdk.java.net/jdk/pull/9000 From shade at openjdk.java.net Fri Jun 3 05:54:31 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 3 Jun 2022 05:54:31 GMT Subject: RFR: 8287734: Shenandoah: Consolidate marking closures In-Reply-To: References: Message-ID: <8bUr_BAC3ux5oM87a-IU31Iji_Fx5wtHtppI80hze70=.f5d79f07-a6aa-425a-b0db-5d2ce830c459@github.com> On Thu, 2 Jun 2022 17:29:04 GMT, Zhengyu Gu wrote: > Shenandoah used to have different marking closures that mark metadata or not. With Loom, marking closures always mark metadata, so they can be consolidated. > > Test: > > - [x] hotspot_gc_shenandoah > - [x] jdk_loom + ShenandoahGC > - [x] hotspot_loom + ShenandoahGC Nice, looks good. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9000 From tschatzl at openjdk.java.net Fri Jun 3 07:34:22 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 3 Jun 2022 07:34:22 GMT Subject: RFR: 8287558: Remove remset coarsening stats during g1 remset summary printing In-Reply-To: References: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> Message-ID: On Wed, 1 Jun 2022 13:00:03 GMT, tqxia wrote: > I think "Concurrent refinement threads times" and "Sampling task time" in "After GC RS summary" also have similar issues: they are all-zeros because the data does not get changed in the last GC cycle. > > A possible way to fix this adding an additional flag to differentiate between "Before GC RS summary" and "After GC RS summary", I can include this fix in the current PR, if that is OK. Let's keep separate issues separate. I filed https://bugs.openjdk.java.net/browse/JDK-8287771 ------------- PR: https://git.openjdk.java.net/jdk/pull/8971 From tschatzl at openjdk.java.net Fri Jun 3 07:43:34 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 3 Jun 2022 07:43:34 GMT Subject: RFR: 8287686: Add assertion to ensure that disarm value offset < 128 In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 18:06:52 GMT, Zhengyu Gu wrote: > Please review this trivial patch to ensure disarm value offset is less than 128. > > At least on x86_64, nmethod entry barrier encodes disarmed value offset as disp8 immed, overflowing the value can result crashes, see [JDK-8244420](https://bugs.openjdk.java.net/browse/JDK-8244420) for details. > > Test: > > - [x] jdk_loom and hotspot_loom on Linux x86_64 Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8977 From shade at openjdk.java.net Fri Jun 3 07:49:35 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 3 Jun 2022 07:49:35 GMT Subject: RFR: 8287686: Add assertion to ensure that disarm value offset < 128 In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 18:06:52 GMT, Zhengyu Gu wrote: > Please review this trivial patch to ensure disarm value offset is less than 128. > > At least on x86_64, nmethod entry barrier encodes disarmed value offset as disp8 immed, overflowing the value can result crashes, see [JDK-8244420](https://bugs.openjdk.java.net/browse/JDK-8244420) for details. > > Test: > > - [x] jdk_loom and hotspot_loom on Linux x86_64 Looks fine. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8977 From zgu at openjdk.java.net Fri Jun 3 12:21:52 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 3 Jun 2022 12:21:52 GMT Subject: RFR: 8287686: Add assertion to ensure that disarm value offset < 128 In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 07:40:16 GMT, Thomas Schatzl wrote: >> Please review this trivial patch to ensure disarm value offset is less than 128. >> >> At least on x86_64, nmethod entry barrier encodes disarmed value offset as disp8 immed, overflowing the value can result crashes, see [JDK-8244420](https://bugs.openjdk.java.net/browse/JDK-8244420) for details. >> >> Test: >> >> - [x] jdk_loom and hotspot_loom on Linux x86_64 > > Marked as reviewed by tschatzl (Reviewer). Thanks, @tschatzl @shipilev ------------- PR: https://git.openjdk.java.net/jdk/pull/8977 From zgu at openjdk.java.net Fri Jun 3 12:21:54 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 3 Jun 2022 12:21:54 GMT Subject: Integrated: 8287686: Add assertion to ensure that disarm value offset < 128 In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 18:06:52 GMT, Zhengyu Gu wrote: > Please review this trivial patch to ensure disarm value offset is less than 128. > > At least on x86_64, nmethod entry barrier encodes disarmed value offset as disp8 immed, overflowing the value can result crashes, see [JDK-8244420](https://bugs.openjdk.java.net/browse/JDK-8244420) for details. > > Test: > > - [x] jdk_loom and hotspot_loom on Linux x86_64 This pull request has now been integrated. Changeset: a75299c3 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/a75299c3ab95f1e43d5628b14e6e5deaa1ed5f70 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8287686: Add assertion to ensure that disarm value offset < 128 Reviewed-by: tschatzl, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/8977 From tschatzl at openjdk.java.net Fri Jun 3 12:29:27 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 3 Jun 2022 12:29:27 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v5] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? > > Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. > > G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. > The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://doi.org/10.1145%2F1029873.1029879)). > > This mechanism has several drawbacks: > > * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage > * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region > > The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". > > That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. > > This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: > > * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. > * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://github.com/openjdk/jdk/pull/8884) and exploited in this change. This removes a few 100 LOC of changes :) > > Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. > > Let me describe the relation of tams and pb during the various phases in gc: > > Young-only gcs (and initial state): > `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap > > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ > | > tams, pb, tars > > During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. > Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ > | | > pb tams > > From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. > > Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. > > Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. > Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ ^ > | | | > tams pb (tars) > > As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. > > Evacuation failure handling: evacuation failure handling has been modified to accomodate this: > > * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. > * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. > > Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. > > Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - More cleanups - Minor renaming to conform to existing nomenclature ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8957/files - new: https://git.openjdk.java.net/jdk/pull/8957/files/281633d3..1acc4fcb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8957&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8957&range=03-04 Stats: 27 lines in 6 files changed: 10 ins; 6 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/8957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8957/head:pull/8957 PR: https://git.openjdk.java.net/jdk/pull/8957 From zgu at openjdk.java.net Fri Jun 3 12:34:44 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 3 Jun 2022 12:34:44 GMT Subject: Integrated: 8287734: Shenandoah: Consolidate marking closures In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 17:29:04 GMT, Zhengyu Gu wrote: > Shenandoah used to have different marking closures that mark metadata or not. With Loom, marking closures always mark metadata, so they can be consolidated. > > Test: > > - [x] hotspot_gc_shenandoah > - [x] jdk_loom + ShenandoahGC > - [x] hotspot_loom + ShenandoahGC This pull request has now been integrated. Changeset: 34bb0a5e Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/34bb0a5e6e9c91e037fbbe87382e8275b2435a3f Stats: 46 lines in 2 files changed: 0 ins; 39 del; 7 mod 8287734: Shenandoah: Consolidate marking closures Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/9000 From duke at openjdk.java.net Fri Jun 3 14:34:18 2022 From: duke at openjdk.java.net (tqxia) Date: Fri, 3 Jun 2022 14:34:18 GMT Subject: RFR: 8287558: Remove remset coarsening stats during g1 remset summary printing In-Reply-To: References: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> Message-ID: On Fri, 3 Jun 2022 07:30:43 GMT, Thomas Schatzl wrote: > > I think "Concurrent refinement threads times" and "Sampling task time" in "After GC RS summary" also have similar issues: they are all-zeros because the data does not get changed in the last GC cycle. > > A possible way to fix this adding an additional flag to differentiate between "Before GC RS summary" and "After GC RS summary", I can include this fix in the current PR, if that is OK. > > Let's keep separate issues separate. I filed https://bugs.openjdk.java.net/browse/JDK-8287771 Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/8971 From iwalulya at openjdk.java.net Fri Jun 3 14:39:38 2022 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Fri, 3 Jun 2022 14:39:38 GMT Subject: RFR: 8287558: Remove remset coarsening stats during g1 remset summary printing In-Reply-To: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> References: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> Message-ID: On Wed, 1 Jun 2022 12:43:38 GMT, tqxia wrote: > Remset summary printing prints coarsening statistics in addition to remset summaries; that information is either duplicated with "Coarsening (recent)" printouts (with gc+remset=debug) at GC start or all-zeros at GC end. > > Given that Remset summary printing is enabled with gc+remset=trace which covers the recent/all coarsening statistics, the coarsening statistics during remset summary are somewhat duplicate (or useless for the after-gc one). > > Remove the coarsening statistics from the remset summaries. Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8971 From tschatzl at openjdk.java.net Fri Jun 3 14:57:47 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 3 Jun 2022 14:57:47 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v6] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? > > Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. > > G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. > The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://doi.org/10.1145%2F1029873.1029879)). > > This mechanism has several drawbacks: > > * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage > * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region > > The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". > > That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. > > This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: > > * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. > * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://github.com/openjdk/jdk/pull/8884) and exploited in this change. This removes a few 100 LOC of changes :) > > Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. > > Let me describe the relation of tams and pb during the various phases in gc: > > Young-only gcs (and initial state): > `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap > > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ > | > tams, pb, tars > > During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. > Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ > | | > pb tams > > From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. > > Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. > > Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. > Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ ^ > | | | > tams pb (tars) > > As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. > > Evacuation failure handling: evacuation failure handling has been modified to accomodate this: > > * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. > * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. > > Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. > > Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Re-add skipping of scanning for remembered sets if unnecessary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8957/files - new: https://git.openjdk.java.net/jdk/pull/8957/files/1acc4fcb..5f497f3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8957&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8957&range=04-05 Stats: 24 lines in 3 files changed: 15 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8957/head:pull/8957 PR: https://git.openjdk.java.net/jdk/pull/8957 From zgu at openjdk.java.net Fri Jun 3 19:08:04 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 3 Jun 2022 19:08:04 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures Message-ID: ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated. Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated. Test: - [x] hotspot_gc_shenandoah ------------- Commit messages: - 8287805: Shenandoah: consolidate evacuate-update-root closures - Merge branch 'master' into consolidate_evac_root_closures - v0 - v0 Changes: https://git.openjdk.java.net/jdk/pull/9023/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9023&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287805 Stats: 70 lines in 4 files changed: 7 ins; 30 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/9023.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9023/head:pull/9023 PR: https://git.openjdk.java.net/jdk/pull/9023 From duke at openjdk.java.net Sat Jun 4 03:50:38 2022 From: duke at openjdk.java.net (tqxia) Date: Sat, 4 Jun 2022 03:50:38 GMT Subject: RFR: 8287558: Remove remset coarsening stats during g1 remset summary printing In-Reply-To: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> References: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> Message-ID: On Wed, 1 Jun 2022 12:43:38 GMT, tqxia wrote: > Remset summary printing prints coarsening statistics in addition to remset summaries; that information is either duplicated with "Coarsening (recent)" printouts (with gc+remset=debug) at GC start or all-zeros at GC end. > > Given that Remset summary printing is enabled with gc+remset=trace which covers the recent/all coarsening statistics, the coarsening statistics during remset summary are somewhat duplicate (or useless for the after-gc one). > > Remove the coarsening statistics from the remset summaries. Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8971 From duke at openjdk.java.net Sat Jun 4 04:38:37 2022 From: duke at openjdk.java.net (tqxia) Date: Sat, 4 Jun 2022 04:38:37 GMT Subject: Integrated: 8287558: Remove remset coarsening stats during g1 remset summary printing In-Reply-To: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> References: <9S8zC9ulsBQyQIJzz09h2hPY9SqPcmxZiiq-APhyOtA=.d2f44e72-ec22-4697-ba90-76e3c7c9e7d2@github.com> Message-ID: On Wed, 1 Jun 2022 12:43:38 GMT, tqxia wrote: > Remset summary printing prints coarsening statistics in addition to remset summaries; that information is either duplicated with "Coarsening (recent)" printouts (with gc+remset=debug) at GC start or all-zeros at GC end. > > Given that Remset summary printing is enabled with gc+remset=trace which covers the recent/all coarsening statistics, the coarsening statistics during remset summary are somewhat duplicate (or useless for the after-gc one). > > Remove the coarsening statistics from the remset summaries. This pull request has now been integrated. Changeset: 308c068b Author: tqxia Committer: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/308c068b36528bcbbcca6e45de6949cb9ee7ae13 Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod 8287558: Remove remset coarsening stats during g1 remset summary printing Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.java.net/jdk/pull/8971 From zgu at openjdk.java.net Mon Jun 6 23:38:23 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Mon, 6 Jun 2022 23:38:23 GMT Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom Message-ID: Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it. Test: - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64 - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 - [x] hotspot_gc_shenandoah on AArch64 ------------- Commit messages: - 8287818: Shenandoah: adapt nmethod arming from Loom - Merge branch 'master' into migrate_nmethod_arming_shenandoah - v0 Changes: https://git.openjdk.java.net/jdk/pull/9048/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9048&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287818 Stats: 53 lines in 5 files changed: 4 ins; 41 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/9048.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9048/head:pull/9048 PR: https://git.openjdk.java.net/jdk/pull/9048 From lmesnik at openjdk.java.net Tue Jun 7 05:41:28 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 7 Jun 2022 05:41:28 GMT Subject: RFR: 8287887: Remove finalization testing from =?UTF-8?B?dm1UZXN0YmFzZS9nYy9nY3Rlc3RzL1BoYW50b21SZWZlcmVuY2UvcGhhbnRvbTAwMS9waGFudG9tMDAxLmphdmHwn46y?= Message-ID: Test vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java? have verification of finalize() method which is unstable and might fail with -Xcomp. The finalization is deprecated for removal in https://bugs.openjdk.org/browse/JDK-8274609 and going to be removed. So the easiest fix would be just to remove the check. ------------- Commit messages: - 8287887 Changes: https://git.openjdk.java.net/jdk/pull/9053/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9053&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287887 Stats: 30 lines in 1 file changed: 0 ins; 30 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/9053.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9053/head:pull/9053 PR: https://git.openjdk.java.net/jdk/pull/9053 From kbarrett at openjdk.java.net Tue Jun 7 13:21:03 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 7 Jun 2022 13:21:03 GMT Subject: RFR: 8287887: Remove finalization testing from vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 05:35:45 GMT, Leonid Mesnik wrote: > Test > vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java? > have verification of finalize() method which is unstable and might fail with -Xcomp. > > The finalization is deprecated for removal in https://bugs.openjdk.org/browse/JDK-8274609 and going to be removed. > > So the easiest fix would be just to remove the check. I think this change is premature. finalization is deprecated for removal, but removal is expected to take a while. Until then I think we should continue testing that the interaction works as expected. ------------- PR: https://git.openjdk.java.net/jdk/pull/9053 From tschatzl at openjdk.java.net Tue Jun 7 15:59:42 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 7 Jun 2022 15:59:42 GMT Subject: RFR: 8287887: Remove finalization testing from vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 05:35:45 GMT, Leonid Mesnik wrote: > Test > vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java? > have verification of finalize() method which is unstable and might fail with -Xcomp. > > The finalization is deprecated for removal in https://bugs.openjdk.org/browse/JDK-8274609 and going to be removed. > > So the easiest fix would be just to remove the check. Agree; finalization will likely stay for quite a bit, and this removal seems premature. Maybe not run this test with -Xcomp if that test often fails with it? ------------- PR: https://git.openjdk.java.net/jdk/pull/9053 From lmesnik at openjdk.java.net Tue Jun 7 18:33:28 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 7 Jun 2022 18:33:28 GMT Subject: RFR: 8287887: Remove finalization testing from vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 05:35:45 GMT, Leonid Mesnik wrote: > Test > vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java? > have verification of finalize() method which is unstable and might fail with -Xcomp. > > The finalization is deprecated for removal in https://bugs.openjdk.org/browse/JDK-8274609 and going to be removed. > > So the easiest fix would be just to remove the check. Let's postpone this fix until finalization is removed. Test failed in ATR only so just keep bug to track this problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/9053 From lmesnik at openjdk.java.net Tue Jun 7 18:33:29 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Tue, 7 Jun 2022 18:33:29 GMT Subject: Withdrawn: 8287887: Remove finalization testing from vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 05:35:45 GMT, Leonid Mesnik wrote: > Test > vmTestbase/gc/gctests/PhantomReference/phantom001/phantom001.java? > have verification of finalize() method which is unstable and might fail with -Xcomp. > > The finalization is deprecated for removal in https://bugs.openjdk.org/browse/JDK-8274609 and going to be removed. > > So the easiest fix would be just to remove the check. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/9053 From duke at openjdk.java.net Tue Jun 7 23:25:46 2022 From: duke at openjdk.java.net (duke) Date: Tue, 7 Jun 2022 23:25:46 GMT Subject: Withdrawn: 8256265: G1: Improve parallelism in regions that failed evacuation In-Reply-To: References: Message-ID: On Wed, 12 Jan 2022 09:03:45 GMT, Hamlin Li wrote: > Currently G1 assigns a thread per failed evacuated region. This can in effect serialize the whole process as often (particularly with region pinning) there is only one region to fix up. > > This patch tries to improve parallelism when walking over the regions in chunks > > Latest implementation scans regions in chunks to bring parallelism, it's based on JDK-8278917 which changes to uses prev bitmap to mark evacuation failure objs. > > Here's the summary of performance data based on latest implementation, basically, it brings better and stable performance than baseline at "Post Evacuate Cleanup 1/remove self forwardee" phase. (Although some regression is spotted when calculate the results in geomean, becuase one pause time from baseline is far too small than others.) > > The performance benefit trend is: > - pause time (Post Evacuate Cleanup 1) is decreased from 76.79% to 2.28% for average time, from 71.61% to 3.04% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=8) > - pause time (Post Evacuate Cleanup 1) is decreased from 63.84% to 15.16% for average time, from 55.41% to 12.45% for geomean, when G1EvacuationFailureALotCSetPercent is changed from 2 to 90 (-XX:ParallelGCThreads=) > ( Other common Evacuation Failure configurations are: > -XX:+G1EvacuationFailureALot -XX:G1EvacuationFailureALotInterval=0 -XX:G1EvacuationFailureALotCount=0 ) > > For more detailed performance data, please check the related bug. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7047 From manc at openjdk.java.net Wed Jun 8 18:20:14 2022 From: manc at openjdk.java.net (Man Cao) Date: Wed, 8 Jun 2022 18:20:14 GMT Subject: RFR: 8288052: Small logging clarification during failed heap shrinkage Message-ID: Hi all, Could anyone review this trivial logging clarification in G1CollectedHeap::shrink_helper()? I'm sponsoring colleague Jonathan Joo for this change. ------------- Commit messages: - 8288052: Small logging clarification during failed heap shrinkage Changes: https://git.openjdk.java.net/jdk/pull/9092/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9092&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288052 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/9092.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9092/head:pull/9092 PR: https://git.openjdk.java.net/jdk/pull/9092 From tschatzl at openjdk.java.net Wed Jun 8 19:37:26 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 8 Jun 2022 19:37:26 GMT Subject: RFR: 8288052: Small logging clarification during failed heap shrinkage In-Reply-To: References: Message-ID: On Wed, 8 Jun 2022 18:12:56 GMT, Man Cao wrote: > Hi all, > > Could anyone review this trivial logging clarification in G1CollectedHeap::shrink_helper()? I'm sponsoring colleague Jonathan Joo for this change. lgtm and trivial ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9092 From tschatzl at openjdk.java.net Wed Jun 8 19:46:35 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 8 Jun 2022 19:46:35 GMT Subject: RFR: 8288052: Small logging clarification during failed heap shrinkage In-Reply-To: References: Message-ID: On Wed, 8 Jun 2022 18:12:56 GMT, Man Cao wrote: > Hi all, > > Could anyone review this trivial logging clarification in G1CollectedHeap::shrink_helper()? I'm sponsoring colleague Jonathan Joo for this change. lgtm and trivial ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/9092 From manc at openjdk.java.net Wed Jun 8 20:22:35 2022 From: manc at openjdk.java.net (Man Cao) Date: Wed, 8 Jun 2022 20:22:35 GMT Subject: Integrated: 8288052: Small logging clarification during failed heap shrinkage In-Reply-To: References: Message-ID: <6Xox9si45wkwZe1UXN6gctRshY_En5fd5y20drSOieY=.dcd8bc1d-144d-4a8a-ae1b-ebab8ffa6f95@github.com> On Wed, 8 Jun 2022 18:12:56 GMT, Man Cao wrote: > Hi all, > > Could anyone review this trivial logging clarification in G1CollectedHeap::shrink_helper()? I'm sponsoring colleague Jonathan Joo for this change. This pull request has now been integrated. Changeset: 130ce7c6 Author: Man Cao URL: https://git.openjdk.java.net/jdk/commit/130ce7c6b8998764f1a9ce5d5c6d60f053511991 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8288052: Small logging clarification during failed heap shrinkage Co-authored-by: Jonathan Joo Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/9092 From duke at openjdk.java.net Thu Jun 9 14:22:45 2022 From: duke at openjdk.java.net (tqxia) Date: Thu, 9 Jun 2022 14:22:45 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times Message-ID: In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. Remove the printing of these unnecessary values in the after gc summary. ------------- Commit messages: - 8287771: Remove useless G1 After GC summary refinement and sampling thread times Changes: https://git.openjdk.org/jdk/pull/9106/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287771 Stats: 20 lines in 5 files changed: 5 ins; 3 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/9106.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9106/head:pull/9106 PR: https://git.openjdk.org/jdk/pull/9106 From duke at openjdk.java.net Thu Jun 9 14:43:54 2022 From: duke at openjdk.java.net (tqxia) Date: Thu, 9 Jun 2022 14:43:54 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v2] In-Reply-To: References: Message-ID: > In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. > > Remove the printing of these unnecessary values in the after gc summary. tqxia has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8287771: Remove useless G1 After GC summary refinement and sampling thread times ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9106/files - new: https://git.openjdk.org/jdk/pull/9106/files/f8d1c1ad..a2c7dde2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9106&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9106&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9106.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9106/head:pull/9106 PR: https://git.openjdk.org/jdk/pull/9106 From jiefu at openjdk.java.net Fri Jun 10 11:24:50 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 10 Jun 2022 11:24:50 GMT Subject: RFR: 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs Message-ID: Hi all, Please review this trivial patch. runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs due to 'VerifyDuringGC' is diagnostic. So let's move `-XX:+UnlockDiagnosticVMOptions` before 'VerifyDuringGC' to fix it. Thanks. Best regards, Jie ------------- Commit messages: - 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs Changes: https://git.openjdk.org/jdk/pull/9125/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9125&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288203 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9125.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9125/head:pull/9125 PR: https://git.openjdk.org/jdk/pull/9125 From shade at openjdk.java.net Fri Jun 10 11:32:04 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 10 Jun 2022 11:32:04 GMT Subject: RFR: 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 11:14:22 GMT, Jie Fu wrote: > Hi all, > > Please review this trivial patch. > runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs due to 'VerifyDuringGC' is diagnostic. > So let's move `-XX:+UnlockDiagnosticVMOptions` before 'VerifyDuringGC' to fix it. > > Thanks. > Best regards, > Jie Looks fine and trivial. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9125 From jiefu at openjdk.java.net Fri Jun 10 11:43:09 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 10 Jun 2022 11:43:09 GMT Subject: RFR: 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs In-Reply-To: References: Message-ID: <7Kypg7ucLM388RWW9YTcsUXMWYRbT4Ab0garYjdmJcE=.b772fb7d-0294-4d8c-bd40-03d04a4c4b07@github.com> On Fri, 10 Jun 2022 11:29:00 GMT, Aleksey Shipilev wrote: > Looks fine and trivial. Thanks @shipilev for your review. ------------- PR: https://git.openjdk.org/jdk/pull/9125 From jiefu at openjdk.java.net Fri Jun 10 11:43:10 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 10 Jun 2022 11:43:10 GMT Subject: Integrated: 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs In-Reply-To: References: Message-ID: On Fri, 10 Jun 2022 11:14:22 GMT, Jie Fu wrote: > Hi all, > > Please review this trivial patch. > runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs due to 'VerifyDuringGC' is diagnostic. > So let's move `-XX:+UnlockDiagnosticVMOptions` before 'VerifyDuringGC' to fix it. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: 5d0e8b69 Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/5d0e8b698144a83025c6912520097f24128858f7 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8288203: runtime/ClassUnload/UnloadTestWithVerifyDuringGC.java fails with release VMs Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/9125 From duke at openjdk.java.net Mon Jun 13 14:30:15 2022 From: duke at openjdk.java.net (duke) Date: Mon, 13 Jun 2022 14:30:15 GMT Subject: Withdrawn: 8284811: Shrink critical section of JNICritical_lock In-Reply-To: References: Message-ID: On Wed, 13 Apr 2022 08:29:29 GMT, Albert Mingkun Yang wrote: > This refactoring around gc-locker consists of two commits: > > 1. Remove `_debug_jni_lock_count` because `verify_critical_count` already verifies #threads in critical regions. `_debug_jni_lock_count` doesn't introduce anything new. > > 2. Shrink the critical section associated with `JNICritical_lock` to accesses to `_needs_gc` and nothing else. > > Test: tier1-6 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8218 From tschatzl at openjdk.java.net Tue Jun 14 09:05:00 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 14 Jun 2022 09:05:00 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v2] In-Reply-To: References: Message-ID: <-qk6gFMbwpv4VOKuBSbQc3J4XPFbMZf8iK0eiQscKRU=.2f33fda7-57ca-400a-8225-84853a0c7465@github.com> On Thu, 9 Jun 2022 14:43:54 GMT, tqxia wrote: >> In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. >> >> Remove the printing of these unnecessary values in the after gc summary. > > tqxia has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8287771: Remove useless G1 After GC summary refinement and sampling thread times Looks good apart from the parameter name. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2806: > 2804: G1HeapPrinterMark::G1HeapPrinterMark(G1CollectedHeap* g1h) : _g1h(g1h), _heap_transition(g1h) { > 2805: // This summary needs to be printed before incrementing total collections. > 2806: _g1h->rem_set()->print_periodic_summary_info("Before GC RS summary", _g1h->total_collections(), true); Suggestion: _g1h->rem_set()->print_periodic_summary_info("Before GC RS summary", _g1h->total_collections(), true /* include_vtimes */); For bool parameters we often add the parameter name for clarity. src/hotspot/share/gc/g1/g1RemSet.cpp line 1766: > 1764: } > 1765: > 1766: void G1RemSet::print_periodic_summary_info(const char* header, uint period_count, bool include_vtimes) { Suggestion: void G1RemSet::print_periodic_summary_info(const char* header, uint period_count, bool show_thread_times) { I think the suggested parameter name is more clear than the original one. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9106 From kbarrett at openjdk.java.net Wed Jun 15 02:56:42 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 15 Jun 2022 02:56:42 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v2] In-Reply-To: References: Message-ID: On Thu, 9 Jun 2022 14:43:54 GMT, tqxia wrote: >> In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. >> >> Remove the printing of these unnecessary values in the after gc summary. > > tqxia has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8287771: Remove useless G1 After GC summary refinement and sampling thread times Looks good, apart from the parameter name, where I agree with @tschatzl . ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9106 From kbarrett at openjdk.java.net Wed Jun 15 03:01:37 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 15 Jun 2022 03:01:37 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v2] In-Reply-To: References: Message-ID: <81GBmnM-X19nBuHr3AbuG9QjjeLYq6ihJ-nptFzJ6r8=.b4f8833a-dd5e-42ca-bd44-de31f03b3eb9@github.com> On Thu, 9 Jun 2022 14:43:54 GMT, tqxia wrote: >> In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. >> >> Remove the printing of these unnecessary values in the after gc summary. > > tqxia has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8287771: Remove useless G1 After GC summary refinement and sampling thread times An alternative to the new bool argument to print_on would be to add a new function print_vtimes_on, and call it in the appropriate places before calling print_on. Just tossing the idea out there. ------------- PR: https://git.openjdk.org/jdk/pull/9106 From tschatzl at openjdk.java.net Wed Jun 15 09:33:04 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 15 Jun 2022 09:33:04 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v7] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? > > Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. > > G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. > The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://doi.org/10.1145%2F1029873.1029879)). > > This mechanism has several drawbacks: > > * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage > * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region > > The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". > > That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. > > This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: > > * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. > * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://github.com/openjdk/jdk/pull/8884) and exploited in this change. This removes a few 100 LOC of changes :) > > Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. > > Let me describe the relation of tams and pb during the various phases in gc: > > Young-only gcs (and initial state): > `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap > > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ > | > tams, pb, tars > > During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. > Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ > | | > pb tams > > From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. > > Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. > > Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. > Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ ^ > | | | > tams pb (tars) > > As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. > > Evacuation failure handling: evacuation failure handling has been modified to accomodate this: > > * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. > * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. > > Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. > > Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - full gc before verification - More log messages fix compilation... ayang comments Some cleanup aborted full collection fix Minor changes More cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8957/files - new: https://git.openjdk.org/jdk/pull/8957/files/5f497f3d..afba8ff8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=05-06 Stats: 183 lines in 17 files changed: 65 ins; 68 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/8957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8957/head:pull/8957 PR: https://git.openjdk.org/jdk/pull/8957 From tschatzl at openjdk.java.net Wed Jun 15 09:44:40 2022 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 15 Jun 2022 09:44:40 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v7] In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 09:33:04 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? >> >> Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. >> >> G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. >> The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://doi.org/10.1145%2F1029873.1029879)). >> >> This mechanism has several drawbacks: >> >> * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage >> * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region >> >> The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". >> >> That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. >> >> This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: >> >> * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. >> * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://github.com/openjdk/jdk/pull/8884) and exploited in this change. This removes a few 100 LOC of changes :) >> >> Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. >> >> Let me describe the relation of tams and pb during the various phases in gc: >> >> Young-only gcs (and initial state): >> `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap >> >> >> bottom top >> | | >> v v >> +---------------------+ >> | | >> +---------------------| >> ^ >> | >> tams, pb, tars >> >> During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. >> Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. >> >> bottom top >> | | >> v v >> +---------------------+ >> | | >> +---------------------| >> ^ ^ >> | | >> pb tams >> >> From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. >> >> Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. >> >> Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. >> Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. >> >> bottom top >> | | >> v v >> +---------------------+ >> | | >> +---------------------| >> ^ ^ ^ >> | | | >> tams pb (tars) >> >> As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. >> >> Evacuation failure handling: evacuation failure handling has been modified to accomodate this: >> >> * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. >> * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. >> >> Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. >> >> Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - full gc before verification > - More log messages > > fix compilation... > > ayang comments > > Some cleanup > > aborted full collection fix > > Minor changes > > More cleanup Some comments about the latest commits while searching for a bug that has been found out to actually not be caused by this change (but occurs more often): [997354d](https://github.com/openjdk/jdk/pull/8957/commits/997354de28a0f739e5ab97b2181badc3557862f8): - moved `G1BlockOffsetTablePart::update` to `HeapRegion::update` as suggested by @albertnetymk - renamed `G1CollectedHeap::is_marked_next()` to `G1CollectedHeap::is_marked()`, i.e. removing the obsolete `next` suffix - merged `HeapRegion::live_bytes` and `HeapRegion::max_live_bytes()` as they were equivalent - moved collector state change whether we are clearing the bitmap from Remark to Cleanup phase - added assertion about assumption that in `HeapRegion::note_self_forwarding_removal_start`, outside of the concurrent start pause, TAMS must be `bottom` (thanks @albertnetymk for the suggestion) - renamed `HeapRegion::obj_is_scrubbed` to `obj_is_filler` and made it private (again, suggested by @albertnetymk ) - optimized `Heapregion:: - factored out a few `byte_size(bottom(), top())` calls which are equivalent to the existing `HeapRegion::used()` call - optimized `HeapRegion::oops_on_memregion_iterate_in_unparsable` - some documentation update afba8ff8e827f09e3da071bbcbf141bb92d41f52: - improved verification before full gc (still a bit buggy, but not because of it, but because of an oversight earlier) - removed debug code - (introduced debug code) ------------- PR: https://git.openjdk.org/jdk/pull/8957 From duke at openjdk.java.net Wed Jun 15 14:54:07 2022 From: duke at openjdk.java.net (tqxia) Date: Wed, 15 Jun 2022 14:54:07 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v2] In-Reply-To: <-qk6gFMbwpv4VOKuBSbQc3J4XPFbMZf8iK0eiQscKRU=.2f33fda7-57ca-400a-8225-84853a0c7465@github.com> References: <-qk6gFMbwpv4VOKuBSbQc3J4XPFbMZf8iK0eiQscKRU=.2f33fda7-57ca-400a-8225-84853a0c7465@github.com> Message-ID: On Mon, 13 Jun 2022 14:44:04 GMT, Thomas Schatzl wrote: >> tqxia has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8287771: Remove useless G1 After GC summary refinement and sampling thread times > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2806: > >> 2804: G1HeapPrinterMark::G1HeapPrinterMark(G1CollectedHeap* g1h) : _g1h(g1h), _heap_transition(g1h) { >> 2805: // This summary needs to be printed before incrementing total collections. >> 2806: _g1h->rem_set()->print_periodic_summary_info("Before GC RS summary", _g1h->total_collections(), true); > > Suggestion: > > _g1h->rem_set()->print_periodic_summary_info("Before GC RS summary", _g1h->total_collections(), true /* include_vtimes */); > > > For bool parameters we often add the parameter name for clarity. Got it. > src/hotspot/share/gc/g1/g1RemSet.cpp line 1766: > >> 1764: } >> 1765: >> 1766: void G1RemSet::print_periodic_summary_info(const char* header, uint period_count, bool include_vtimes) { > > Suggestion: > > void G1RemSet::print_periodic_summary_info(const char* header, uint period_count, bool show_thread_times) { > > > I think the suggested parameter name is more clear than the original one. Updated. ------------- PR: https://git.openjdk.org/jdk/pull/9106 From duke at openjdk.java.net Wed Jun 15 14:50:04 2022 From: duke at openjdk.java.net (tqxia) Date: Wed, 15 Jun 2022 14:50:04 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v3] In-Reply-To: References: Message-ID: > In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. > > Remove the printing of these unnecessary values in the after gc summary. tqxia has updated the pull request incrementally with one additional commit since the last revision: Update flag name to show_thread_times and add comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9106/files - new: https://git.openjdk.org/jdk/pull/9106/files/a2c7dde2..c09adf08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9106&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9106&range=01-02 Stats: 12 lines in 5 files changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9106.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9106/head:pull/9106 PR: https://git.openjdk.org/jdk/pull/9106 From duke at openjdk.java.net Wed Jun 15 15:06:56 2022 From: duke at openjdk.java.net (tqxia) Date: Wed, 15 Jun 2022 15:06:56 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v2] In-Reply-To: <81GBmnM-X19nBuHr3AbuG9QjjeLYq6ihJ-nptFzJ6r8=.b4f8833a-dd5e-42ca-bd44-de31f03b3eb9@github.com> References: <81GBmnM-X19nBuHr3AbuG9QjjeLYq6ihJ-nptFzJ6r8=.b4f8833a-dd5e-42ca-bd44-de31f03b3eb9@github.com> Message-ID: On Wed, 15 Jun 2022 02:58:15 GMT, Kim Barrett wrote: > An alternative to the new bool argument to print_on would be to add a new function print_vtimes_on, and call it in the appropriate places before calling print_on. Just tossing the idea out there. Thanks for the suggestion. After playing with the code a little bit more, I guess I will stick with the new flag for now for 2 reasons: 1. There is some shared calculation before printing thread times and printing other rem set information. 2. Since print_on(or print_thread_times_on) will be a method on G1RemSetSummary, in order to invoke it in G1HeapPrinterMark(where the decision is made), we probably need to create another wrapper for it on G1RemSet. ------------- PR: https://git.openjdk.org/jdk/pull/9106 From dcubed at openjdk.java.net Wed Jun 15 19:46:53 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 19:46:53 GMT Subject: Integrated: 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 Message-ID: A trivial fix to ProblemList gc/stress/TestStressG1Humongous.java on windows-x64. ------------- Commit messages: - 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 Changes: https://git.openjdk.org/jdk19/pull/23/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=23&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288526 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/23.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/23/head:pull/23 PR: https://git.openjdk.org/jdk19/pull/23 From psandoz at openjdk.java.net Wed Jun 15 19:46:53 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 15 Jun 2022 19:46:53 GMT Subject: Integrated: 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 19:34:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList gc/stress/TestStressG1Humongous.java on windows-x64. Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/23 From dcubed at openjdk.java.net Wed Jun 15 19:46:53 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 19:46:53 GMT Subject: Integrated: 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 In-Reply-To: References: Message-ID: On Wed, 15 Jun 2022 19:41:07 GMT, Paul Sandoz wrote: >> A trivial fix to ProblemList gc/stress/TestStressG1Humongous.java on windows-x64. > > Marked as reviewed by psandoz (Reviewer). @PaulSandoz - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk19/pull/23 From dcubed at openjdk.java.net Wed Jun 15 19:46:54 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 15 Jun 2022 19:46:54 GMT Subject: Integrated: 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 In-Reply-To: References: Message-ID: <2BRPmO9tZGXyA4HBWTy9IjxX8ulM706IQzt3ET5NjEI=.9b6ef0d7-a78c-478c-b020-0918ecc9e64b@github.com> On Wed, 15 Jun 2022 19:34:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList gc/stress/TestStressG1Humongous.java on windows-x64. This pull request has now been integrated. Changeset: 9254e129 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/9254e1299374b772c2ea12176a145fb0e91c7fbc Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64 Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk19/pull/23 From duke at openjdk.java.net Thu Jun 16 00:27:55 2022 From: duke at openjdk.java.net (tqxia) Date: Thu, 16 Jun 2022 00:27:55 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v4] In-Reply-To: References: Message-ID: > In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. > > Remove the printing of these unnecessary values in the after gc summary. tqxia has updated the pull request incrementally with one additional commit since the last revision: add comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9106/files - new: https://git.openjdk.org/jdk/pull/9106/files/c09adf08..d6662ab5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9106&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9106&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9106.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9106/head:pull/9106 PR: https://git.openjdk.org/jdk/pull/9106 From duke at openjdk.org Fri Jun 17 22:57:56 2022 From: duke at openjdk.org (duke) Date: Fri, 17 Jun 2022 22:57:56 GMT Subject: Withdrawn: 8284734: Undiscovered references if using ReferentBasedDiscovery In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 08:18:50 GMT, Albert Mingkun Yang wrote: > Small change of fixing a crash if using `ReferentBasedDiscovery`. > > Test: hotspot_gc This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8196 From tschatzl at openjdk.org Mon Jun 20 08:24:54 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 20 Jun 2022 08:24:54 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v4] In-Reply-To: References: Message-ID: On Thu, 16 Jun 2022 00:27:55 GMT, tqxia wrote: >> In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. >> >> Remove the printing of these unnecessary values in the after gc summary. > > tqxia has updated the pull request incrementally with one additional commit since the last revision: > > add comment Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9106 From duke at openjdk.org Mon Jun 20 12:50:07 2022 From: duke at openjdk.org (tqxia) Date: Mon, 20 Jun 2022 12:50:07 GMT Subject: RFR: 8287771: Remove useless G1 After GC summary refinement and sampling thread times [v4] In-Reply-To: References: Message-ID: <60YV1URuYVBpWruiergfBxujNzrpWV_WVdH81PL47bM=.0c6ee566-9562-448f-9ff0-b0309c94c02c@github.com> On Thu, 16 Jun 2022 00:27:55 GMT, tqxia wrote: >> In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. >> >> Remove the printing of these unnecessary values in the after gc summary. > > tqxia has updated the pull request incrementally with one additional commit since the last revision: > > add comment Thanks for the review! ------------- PR: https://git.openjdk.org/jdk/pull/9106 From duke at openjdk.org Mon Jun 20 13:01:10 2022 From: duke at openjdk.org (tqxia) Date: Mon, 20 Jun 2022 13:01:10 GMT Subject: Integrated: 8287771: Remove useless G1 After GC summary refinement and sampling thread times In-Reply-To: References: Message-ID: <5ZnHG50D8U8A7uDs377VrtnaiQEhFJmTDo1YUBXVn_o=.d11ed07e-e5de-469b-ae59-fece3c6577ce@github.com> On Thu, 9 Jun 2022 13:42:51 GMT, tqxia wrote: > In the "After GC summary" printed by gc+remset=trace and G1RemsetStatsSummaryPeriod > 1 we print refinement and sampling thread times. However during GC neither thread types are active, so it always prints zeros. > > Remove the printing of these unnecessary values in the after gc summary. This pull request has now been integrated. Changeset: 406cf611 Author: tqxia Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/406cf611d99e30052373aeab0f7bcbd0efd7177b Stats: 25 lines in 6 files changed: 9 ins; 3 del; 13 mod 8287771: Remove useless G1 After GC summary refinement and sampling thread times Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9106 From shade at openjdk.org Mon Jun 20 17:38:18 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jun 2022 17:38:18 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp Message-ID: When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/9219/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9219&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288754 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9219.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9219/head:pull/9219 PR: https://git.openjdk.org/jdk/pull/9219 From shade at openjdk.org Mon Jun 20 17:43:40 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jun 2022 17:43:40 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 17:30:40 GMT, Aleksey Shipilev wrote: > When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: Closed in favor of JDK 19 PR: https://urldefense.com/v3/__https://github.com/openjdk/jdk19/pull/47__;!!ACWV5N9M2RV99hQ!PXh3-9-7YXFaSkhGgrZIwOWROx1regl9TBEpzJL1gs7-ndke2_c2CAg9j3RF9dqLKhyD-ww3UvD5Wr1MnrAXbg0$ ------------- PR: https://git.openjdk.org/jdk/pull/9219 From shade at openjdk.org Mon Jun 20 17:43:40 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jun 2022 17:43:40 GMT Subject: Withdrawn: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 17:30:40 GMT, Aleksey Shipilev wrote: > When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9219 From shade at openjdk.org Mon Jun 20 17:48:16 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 20 Jun 2022 17:48:16 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp Message-ID: When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk19/pull/47/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=47&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288754 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/47.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/47/head:pull/47 PR: https://git.openjdk.org/jdk19/pull/47 From kbarrett at openjdk.org Mon Jun 20 18:50:07 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 20 Jun 2022 18:50:07 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 17:39:43 GMT, Aleksey Shipilev wrote: > When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: Looks good. > (This thing should be more reasonably handled when `ShouldNotReachHere()` is > somehow `nonreturn`-ed, but Hotspot style doc is still undecided on this). The problem with using `[[noreturn]]` for assert/guarantee/ShouldNotReachHere &etc is that they aren't currently noreturn, due to `Debugging` and (in non-product builds) `SuppressErrorAt`. I've sometimes wondered if anyone actually uses `SuppressErrorAt`. But I haven't pursued the question because of `Debugging`, which seems to be involved in dealing with error handler reentrancy or recursion or the like (I don't recall details). ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk19/pull/47 From ayang at openjdk.org Mon Jun 20 19:12:15 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 20 Jun 2022 19:12:15 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 17:39:43 GMT, Aleksey Shipilev wrote: > When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/47 From stefank at openjdk.org Tue Jun 21 12:17:05 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 21 Jun 2022 12:17:05 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: References: Message-ID: <9yLqZhCVL8UJznmv1P8jjrTK-QGaz62JrWvuoNt2p_Q=.f6b94570-32c3-4844-97da-d879f270e314@github.com> On Mon, 20 Jun 2022 18:47:16 GMT, Kim Barrett wrote: > Looks good. > > > (This thing should be more reasonably handled when `ShouldNotReachHere()` is > > somehow `nonreturn`-ed, but Hotspot style doc is still undecided on this). > > The problem with using `[[noreturn]]` for assert/guarantee/ShouldNotReachHere &etc is that they aren't currently noreturn, due to `Debugging` and (in non-product builds) `SuppressErrorAt`. I've sometimes wondered if anyone actually uses `SuppressErrorAt`. But I haven't pursued the question because of `Debugging`, which seems to be involved in dealing with error handler reentrancy or recursion or the like (I don't recall details). Also, see the discussion in https://bugs.openjdk.org/browse/JDK-8065585 ------------- PR: https://git.openjdk.org/jdk19/pull/47 From shade at openjdk.org Tue Jun 21 14:49:12 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jun 2022 14:49:12 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: <9yLqZhCVL8UJznmv1P8jjrTK-QGaz62JrWvuoNt2p_Q=.f6b94570-32c3-4844-97da-d879f270e314@github.com> References: <9yLqZhCVL8UJznmv1P8jjrTK-QGaz62JrWvuoNt2p_Q=.f6b94570-32c3-4844-97da-d879f270e314@github.com> Message-ID: On Tue, 21 Jun 2022 12:13:13 GMT, Stefan Karlsson wrote: >> Looks good. >> >>> (This thing should be more reasonably handled when `ShouldNotReachHere()` is >>> somehow `nonreturn`-ed, but Hotspot style doc is still undecided on this). >> >> The problem with using `[[noreturn]]` for assert/guarantee/ShouldNotReachHere >> &etc is that they aren't currently noreturn, due to `Debugging` and >> (in non-product builds) `SuppressErrorAt`. I've sometimes wondered if anyone >> actually uses `SuppressErrorAt`. But I haven't pursued the question because of >> `Debugging`, which seems to be involved in dealing with error handler >> reentrancy or recursion or the like (I don't recall details). > >> Looks good. >> >> > (This thing should be more reasonably handled when `ShouldNotReachHere()` is >> > somehow `nonreturn`-ed, but Hotspot style doc is still undecided on this). >> >> The problem with using `[[noreturn]]` for assert/guarantee/ShouldNotReachHere &etc is that they aren't currently noreturn, due to `Debugging` and (in non-product builds) `SuppressErrorAt`. I've sometimes wondered if anyone actually uses `SuppressErrorAt`. But I haven't pursued the question because of `Debugging`, which seems to be involved in dealing with error handler reentrancy or recursion or the like (I don't recall details). > > Also, see the discussion in https://bugs.openjdk.org/browse/JDK-8065585 @stefank, do you agree with this patch? ------------- PR: https://git.openjdk.org/jdk19/pull/47 From stefank at openjdk.org Tue Jun 21 15:17:57 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 21 Jun 2022 15:17:57 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 17:39:43 GMT, Aleksey Shipilev wrote: > When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: Marked as reviewed by stefank (Reviewer). Yes, that seems to be a good fix. I would have preferred to say "Unknown" instead of "ERROR", but that could be changed later if you want to push. ------------- PR: https://git.openjdk.org/jdk19/pull/47 From shade at openjdk.org Tue Jun 21 15:28:57 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jun 2022 15:28:57 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp [v2] In-Reply-To: References: Message-ID: > When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Unknown ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/47/files - new: https://git.openjdk.org/jdk19/pull/47/files/8312ecc1..1b603dfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=47&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=47&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/47.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/47/head:pull/47 PR: https://git.openjdk.org/jdk19/pull/47 From shade at openjdk.org Tue Jun 21 15:28:58 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jun 2022 15:28:58 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: References: Message-ID: On Mon, 20 Jun 2022 17:39:43 GMT, Aleksey Shipilev wrote: > When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: Oh, we can change that to `Unknown`, no problem there. ------------- PR: https://git.openjdk.org/jdk19/pull/47 From tschatzl at openjdk.org Tue Jun 21 16:14:34 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 21 Jun 2022 16:14:34 GMT Subject: RFR: 8288754: GCC 12 fails to build zReferenceProcessor.cpp [v2] In-Reply-To: References: Message-ID: On Tue, 21 Jun 2022 15:28:57 GMT, Aleksey Shipilev wrote: >> When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Unknown Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/47 From shade at openjdk.org Tue Jun 21 18:16:15 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 21 Jun 2022 18:16:15 GMT Subject: Integrated: 8288754: GCC 12 fails to build zReferenceProcessor.cpp In-Reply-To: References: Message-ID: <_pJIhZEtPpNSppQRAFXgOMGUlIeWUIaGikWG6FAs5ls=.8d132719-01dd-489e-8699-52811577185d@github.com> On Mon, 20 Jun 2022 17:39:43 GMT, Aleksey Shipilev wrote: > When compiling with GCC 12.1.1 (current in Fedora rawhide), the following warning-as-error is produced and breaks the build by default: This pull request has now been integrated. Changeset: 834d92dd Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk19/commit/834d92dd72257ab5d8c6759028098ac0867c5752 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8288754: GCC 12 fails to build zReferenceProcessor.cpp Reviewed-by: kbarrett, ayang, stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk19/pull/47 From ayang at openjdk.org Wed Jun 22 10:09:18 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 22 Jun 2022 10:09:18 GMT Subject: RFR: 8288947: G1: Consolidate per-region info query in G1CollectedHeap Message-ID: Simple change of removing `_humongous_reclaim_candidates`. Test: tier1-6 ------------- Commit messages: - g1-remove-humongous-table Changes: https://git.openjdk.org/jdk/pull/9233/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9233&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288947 Stats: 49 lines in 5 files changed: 4 ins; 37 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9233.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9233/head:pull/9233 PR: https://git.openjdk.org/jdk/pull/9233 From shade at openjdk.org Wed Jun 22 15:30:01 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Jun 2022 15:30:01 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures In-Reply-To: References: Message-ID: On Fri, 3 Jun 2022 19:00:01 GMT, Zhengyu Gu wrote: > ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated. > > Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated. > > Test: > > - [x] hotspot_gc_shenandoah Changes requested by shade (Reviewer). src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 95: > 93: class ShenandoahEvacuateUpdateRootClosureBase : public ShenandoahOopClosureBase { > 94: protected: > 95: ShenandoahHeap* const _heap; Here and later the indenting is a bit off: needs to be 2 spaces, not 4. src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 99: > 97: inline ShenandoahEvacuateUpdateRootClosureBase(); > 98: inline virtual void do_oop(oop* p); > 99: inline virtual void do_oop(narrowOop* p); Do we have to make these functions `virtual`? I supposed we do templated closures exactly to avoid any sort of virtual method dispatching. Maybe I am missing something here... src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp line 144: > 142: template > 143: void ShenandoahEvacuateUpdateRootClosureBase::do_oop(oop* p) { > 144: do_oop_work(p, Thread::current()); Not fond of calling `Thread::current()` on this hotpath. From the code, it looks like we only need it when actually calling `_heap->evacuate_object()`, can we move it there? Related: is `ShenandoahContextEvacuateUpdateRootsClosure::_thread` used now? Can we use it on some paths too? ------------- PR: https://git.openjdk.org/jdk/pull/9023 From shade at openjdk.org Wed Jun 22 15:32:36 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 22 Jun 2022 15:32:36 GMT Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 23:29:10 GMT, Zhengyu Gu wrote: > Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it. > > Test: > > - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64 > - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 > - [x] hotspot_gc_shenandoah on AArch64 Looks mostly fine to me, but I have questions. src/hotspot/share/gc/shenandoah/shenandoahBarrierSetNMethod.cpp line 72: > 70: ShenandoahNMethod::disarm_nmethod(nm); > 71: return true; > 72: } Nit: missing newline. src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 129: > 127: > 128: void ShenandoahCodeRoots::arm_nmethods() { > 129: BarrierSet::barrier_set()->barrier_set_nmethod()->arm_all_nmethods(); Question: in `ShenandoahBarrierSet::on_thread_attach`, we check `barrier_set_nmethod() != NULL`, do we need to do the same check here, or? ------------- PR: https://git.openjdk.org/jdk/pull/9048 From duke at openjdk.org Thu Jun 23 16:31:38 2022 From: duke at openjdk.org (duke) Date: Thu, 23 Jun 2022 16:31:38 GMT Subject: Withdrawn: 8281254: GCs with survivor spaces report Init > Max through MXBeans In-Reply-To: References: Message-ID: On Fri, 4 Feb 2022 09:02:35 GMT, Aleksey Shipilev wrote: > See the discussion in the bug. This realistically affects only Serial and Parallel. My first attempt was to push through `initial_size` to generations properly, but it is too intrusive to my liking. The current patch "just" caps the initial to max. > > Additional testing: > - [x] New regression test now passes on all GCs > - [x] Linux x86_64 `hotspot:tier1` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/7341 From zgu at openjdk.org Thu Jun 23 17:49:50 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 23 Jun 2022 17:49:50 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v2] In-Reply-To: References: Message-ID: <0CN3S9po38Sr2FT3cjroUSWIHhd5tM1QikiBIQTVvec=.9f49a85f-e200-4da8-9f6a-e7ebd5881143@github.com> > ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated. > > Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated. > > Test: > > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Review feedback - Merge branch 'master' into JDK-8287805-evac-updt-closures - 8287805: Shenandoah: consolidate evacuate-update-root closures - Merge branch 'master' into consolidate_evac_root_closures - v0 - v0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9023/files - new: https://git.openjdk.org/jdk/pull/9023/files/c3a41277..427c3a45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=00-01 Stats: 64291 lines in 1573 files changed: 35441 ins; 15195 del; 13655 mod Patch: https://git.openjdk.org/jdk/pull/9023.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9023/head:pull/9023 PR: https://git.openjdk.org/jdk/pull/9023 From zgu at openjdk.org Thu Jun 23 17:54:45 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 23 Jun 2022 17:54:45 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 15:26:09 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Review feedback >> - Merge branch 'master' into JDK-8287805-evac-updt-closures >> - 8287805: Shenandoah: consolidate evacuate-update-root closures >> - Merge branch 'master' into consolidate_evac_root_closures >> - v0 >> - v0 > > src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 99: > >> 97: inline ShenandoahEvacuateUpdateRootClosureBase(); >> 98: inline virtual void do_oop(oop* p); >> 99: inline virtual void do_oop(narrowOop* p); > > Do we have to make these functions `virtual`? I supposed we do templated closures exactly to avoid any sort of virtual method dispatching. Maybe I am missing something here... Fixed > src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp line 144: > >> 142: template >> 143: void ShenandoahEvacuateUpdateRootClosureBase::do_oop(oop* p) { >> 144: do_oop_work(p, Thread::current()); > > Not fond of calling `Thread::current()` on this hotpath. From the code, it looks like we only need it when actually calling `_heap->evacuate_object()`, can we move it there? > > Related: is `ShenandoahContextEvacuateUpdateRootsClosure::_thread` used now? Can we use it on some paths too? My mistake, fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9023 From zgu at openjdk.org Thu Jun 23 18:07:58 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 23 Jun 2022 18:07:58 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v3] In-Reply-To: References: Message-ID: <2WEjdZmJPwCTHO7oIxcWBzF__aK9_Thz7Qfig1CweAA=.da88a7dd-d252-49ff-b7dd-e92d6e95dbab@github.com> > ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated. > > Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated. > > Test: > > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Remove unused impl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9023/files - new: https://git.openjdk.org/jdk/pull/9023/files/427c3a45..689335bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=01-02 Stats: 11 lines in 2 files changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9023.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9023/head:pull/9023 PR: https://git.openjdk.org/jdk/pull/9023 From zgu at openjdk.org Thu Jun 23 18:08:00 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 23 Jun 2022 18:08:00 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v3] In-Reply-To: References: Message-ID: <5QcrbCR00EiXj26otV3Iy6eRcsUHT81iYl9Jdlv8-X8=.0cbde552-718b-4ed0-a776-fa9d7ab56d44@github.com> On Thu, 23 Jun 2022 17:52:14 GMT, Zhengyu Gu wrote: >> src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 99: >> >>> 97: inline ShenandoahEvacuateUpdateRootClosureBase(); >>> 98: inline virtual void do_oop(oop* p); >>> 99: inline virtual void do_oop(narrowOop* p); >> >> Do we have to make these functions `virtual`? I supposed we do templated closures exactly to avoid any sort of virtual method dispatching. Maybe I am missing something here... > > Fixed Removed `virtual` keyword ------------- PR: https://git.openjdk.org/jdk/pull/9023 From zgu at openjdk.org Thu Jun 23 18:33:54 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 23 Jun 2022 18:33:54 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v3] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 15:24:25 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused impl > > src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp line 95: > >> 93: class ShenandoahEvacuateUpdateRootClosureBase : public ShenandoahOopClosureBase { >> 94: protected: >> 95: ShenandoahHeap* const _heap; > > Here and later the indenting is a bit off: needs to be 2 spaces, not 4. Fixed ------------- PR: https://git.openjdk.org/jdk/pull/9023 From zgu at openjdk.org Thu Jun 23 19:02:53 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 23 Jun 2022 19:02:53 GMT Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2] In-Reply-To: References: Message-ID: > Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it. > > Test: > > - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64 > - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 > - [x] hotspot_gc_shenandoah on AArch64 Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Add a newline - Merge branch 'master' into 8287818-nmethod-arming - 8287818: Shenandoah: adapt nmethod arming from Loom - Merge branch 'master' into migrate_nmethod_arming_shenandoah - v0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9048/files - new: https://git.openjdk.org/jdk/pull/9048/files/30a2f41b..b4ef6d63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9048&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9048&range=00-01 Stats: 64264 lines in 1573 files changed: 35422 ins; 15195 del; 13647 mod Patch: https://git.openjdk.org/jdk/pull/9048.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9048/head:pull/9048 PR: https://git.openjdk.org/jdk/pull/9048 From zgu at openjdk.org Thu Jun 23 19:02:56 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 23 Jun 2022 19:02:56 GMT Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2] In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 15:26:29 GMT, Aleksey Shipilev wrote: >> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Add a newline >> - Merge branch 'master' into 8287818-nmethod-arming >> - 8287818: Shenandoah: adapt nmethod arming from Loom >> - Merge branch 'master' into migrate_nmethod_arming_shenandoah >> - v0 > > src/hotspot/share/gc/shenandoah/shenandoahBarrierSetNMethod.cpp line 72: > >> 70: ShenandoahNMethod::disarm_nmethod(nm); >> 71: return true; >> 72: } > > Nit: missing newline. Fixed > src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 129: > >> 127: >> 128: void ShenandoahCodeRoots::arm_nmethods() { >> 129: BarrierSet::barrier_set()->barrier_set_nmethod()->arm_all_nmethods(); > > Question: in `ShenandoahBarrierSet::on_thread_attach`, we check `barrier_set_nmethod() != NULL`, do we need to do the same check here, or? Only in `passive` mode, Shenandoah does not install nmethod barrier, but `passive` mode never calls `arm_nmethod()`, etc. nmethod entry barrier related methods. ------------- PR: https://git.openjdk.org/jdk/pull/9048 From tschatzl at openjdk.org Thu Jun 23 21:01:04 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 23 Jun 2022 21:01:04 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code Message-ID: Hi all, can I have reviews for this change that specializes `G1BlockOffsetTablePart::block_size` with a variant used for card aligned addresses including some cleanup of comments? This saves some unnecessary lookup of the block size of the object found as for refinement the start address is always aligned. Testing: tier1, gha Thanks, Thomas ------------- Commit messages: - Fix whitespace - Cleanup - 8287555: Tighten G1BlockOffsetTable::block_start() code Changes: https://git.openjdk.org/jdk/pull/9059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287555 Stats: 41 lines in 5 files changed: 28 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9059.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9059/head:pull/9059 PR: https://git.openjdk.org/jdk/pull/9059 From ayang at openjdk.org Thu Jun 23 21:23:53 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 23 Jun 2022 21:23:53 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code In-Reply-To: References: Message-ID: On Tue, 7 Jun 2022 11:46:47 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that specializes `G1BlockOffsetTablePart::block_size` with a variant used for card aligned addresses including some cleanup of comments? This saves some unnecessary lookup of the block size of the object found as for refinement the start address is always aligned. > > Testing: tier1, gha > > Thanks, > Thomas src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp line 166: > 164: // Returns the address of the start of the block containing "addr", assuming that > 165: // the given address is card-aligned. > 166: inline HeapWord* block_start_aligned(const void* addr) const; I am not sure introducing another API is really that necessary. What I have in mind is sth like: void block_start(const void* addr) { if (card_aligned(addr)) { fast_path } else { slow_path } assert_post-cond } I don't think the cost of if-check will be observable. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Fri Jun 24 06:54:54 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 24 Jun 2022 06:54:54 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 21:19:58 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> can I have reviews for this change that specializes `G1BlockOffsetTablePart::block_size` with a variant used for card aligned addresses including some cleanup of comments? This saves some unnecessary lookup of the block size of the object found as for refinement the start address is always aligned. >> >> Testing: tier1, gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp line 166: > >> 164: // Returns the address of the start of the block containing "addr", assuming that >> 165: // the given address is card-aligned. >> 166: inline HeapWord* block_start_aligned(const void* addr) const; > > I am not sure introducing another API is really that necessary. What I have in mind is sth like: > > > void block_start(const void* addr) { > if (card_aligned(addr)) { > fast_path > } else { > slow_path > } > assert_post-cond > } > > > I don't think the cost of if-check will be observable. I had something like that, but the "not observable" part was not that clear in my results (i.e. during garbage collection; "not clear" as in it seems to be slower) so I only optimized the part where this can be statically determined for now. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Fri Jun 24 08:42:53 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 24 Jun 2022 08:42:53 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 06:50:32 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp line 166: >> >>> 164: // Returns the address of the start of the block containing "addr", assuming that >>> 165: // the given address is card-aligned. >>> 166: inline HeapWord* block_start_aligned(const void* addr) const; >> >> I am not sure introducing another API is really that necessary. What I have in mind is sth like: >> >> >> void block_start(const void* addr) { >> if (card_aligned(addr)) { >> fast_path >> } else { >> slow_path >> } >> assert_post-cond >> } >> >> >> I don't think the cost of if-check will be observable. > > I had something like that, but the "not observable" part was not that clear in my results (i.e. during garbage collection; "not clear" as in it seems to be slower) so I only optimized the part where this can be statically determined for now. CPU resources like branch prediction/speculative execution aren't free either, and this is a very performance sensitive area of code. I'm planning to revisit this again for the card scanning code which in 99% of cases takes the aligned path. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From shade at openjdk.org Fri Jun 24 08:47:58 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 24 Jun 2022 08:47:58 GMT Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2] In-Reply-To: References: Message-ID: <5YeCHWQ7ep4_r14cG96WcKfzp0Bs-AMqfu0KYnYvuiM=.3fcc24de-24a8-472e-8a8b-4508107a2970@github.com> On Thu, 23 Jun 2022 19:02:53 GMT, Zhengyu Gu wrote: >> Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it. >> >> Test: >> >> - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64 >> - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 >> - [x] hotspot_gc_shenandoah on AArch64 > > Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Add a newline > - Merge branch 'master' into 8287818-nmethod-arming > - 8287818: Shenandoah: adapt nmethod arming from Loom > - Merge branch 'master' into migrate_nmethod_arming_shenandoah > - v0 Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9048 From shade at openjdk.org Fri Jun 24 08:48:01 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 24 Jun 2022 08:48:01 GMT Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v2] In-Reply-To: References: Message-ID: On Thu, 23 Jun 2022 18:58:45 GMT, Zhengyu Gu wrote: >> src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 129: >> >>> 127: >>> 128: void ShenandoahCodeRoots::arm_nmethods() { >>> 129: BarrierSet::barrier_set()->barrier_set_nmethod()->arm_all_nmethods(); >> >> Question: in `ShenandoahBarrierSet::on_thread_attach`, we check `barrier_set_nmethod() != NULL`, do we need to do the same check here, or? > > Only in `passive` mode, Shenandoah does not install nmethod barrier, but `passive` mode never calls `arm_nmethod()`, etc. nmethod entry barrier related methods. All right, would you mind adding at least the assert here, so that we don't have a spurious SEGV if that was ever violated? ------------- PR: https://git.openjdk.org/jdk/pull/9048 From aturbanov at openjdk.org Fri Jun 24 09:27:22 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 24 Jun 2022 09:27:22 GMT Subject: RFR: 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent Message-ID: Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes. The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. For example, the following code: Object node = tree.getLastSelectedPathComponent(); if (node != null && node instanceof SimpleTreeNode) { showInspector((SimpleTreeNode)node); } Can be simplified to: Object node = tree.getLastSelectedPathComponent(); if (node instanceof SimpleTreeNode simpleNode) { showInspector(simpleNode); } See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) ------------- Commit messages: - 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent Changes: https://git.openjdk.org/jdk/pull/9272/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9272&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289126 Stats: 62 lines in 18 files changed: 0 ins; 13 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/9272.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9272/head:pull/9272 PR: https://git.openjdk.org/jdk/pull/9272 From ayang at openjdk.org Fri Jun 24 12:08:45 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 24 Jun 2022 12:08:45 GMT Subject: RFR: 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 09:19:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > > For example, the following code: > > Object node = tree.getLastSelectedPathComponent(); > if (node != null && node instanceof SimpleTreeNode) { > showInspector((SimpleTreeNode)node); > } > > Can be simplified to: > > Object node = tree.getLastSelectedPathComponent(); > if (node instanceof SimpleTreeNode simpleNode) { > showInspector(simpleNode); > } > > > See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9272 From shade at openjdk.org Fri Jun 24 17:47:55 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 24 Jun 2022 17:47:55 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v3] In-Reply-To: <2WEjdZmJPwCTHO7oIxcWBzF__aK9_Thz7Qfig1CweAA=.da88a7dd-d252-49ff-b7dd-e92d6e95dbab@github.com> References: <2WEjdZmJPwCTHO7oIxcWBzF__aK9_Thz7Qfig1CweAA=.da88a7dd-d252-49ff-b7dd-e92d6e95dbab@github.com> Message-ID: On Thu, 23 Jun 2022 18:07:58 GMT, Zhengyu Gu wrote: >> ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated. >> >> Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated. >> >> Test: >> >> - [x] hotspot_gc_shenandoah > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused impl I still dislike the fact we are calling `Thread::current()` on hotpath. I think we can do better. Consider this modification on top of your current PR: http://cr.openjdk.java.net/~shade/8287805/thread-1.patch -- does that look better? ------------- PR: https://git.openjdk.org/jdk/pull/9023 From cjplummer at openjdk.org Fri Jun 24 18:11:40 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 24 Jun 2022 18:11:40 GMT Subject: RFR: 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 09:19:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > > For example, the following code: > > Object node = tree.getLastSelectedPathComponent(); > if (node != null && node instanceof SimpleTreeNode) { > showInspector((SimpleTreeNode)node); > } > > Can be simplified to: > > Object node = tree.getLastSelectedPathComponent(); > if (node instanceof SimpleTreeNode simpleNode) { > showInspector(simpleNode); > } > > > See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9272 From cjplummer at openjdk.org Fri Jun 24 18:18:53 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 24 Jun 2022 18:18:53 GMT Subject: RFR: 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 09:19:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > > For example, the following code: > > Object node = tree.getLastSelectedPathComponent(); > if (node != null && node instanceof SimpleTreeNode) { > showInspector((SimpleTreeNode)node); > } > > Can be simplified to: > > Object node = tree.getLastSelectedPathComponent(); > if (node instanceof SimpleTreeNode simpleNode) { > showInspector(simpleNode); > } > > > See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) I noticed you have 3 tier1 JDI tests timing out on all platforms. I don't see this in another PR I just reviewed. I know you didn't change JDI, but am wondering why this is happening in your PR. ------------- PR: https://git.openjdk.org/jdk/pull/9272 From aturbanov at openjdk.org Fri Jun 24 18:41:53 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 24 Jun 2022 18:41:53 GMT Subject: RFR: 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 18:15:26 GMT, Chris Plummer wrote: >I noticed you have 3 tier1 JDI tests timing out on all platforms. I don't see this in another PR I just reviewed. I know you didn't change JDI, but am wondering why this is happening in your PR. See [JDK-8289129](https://bugs.openjdk.org/browse/JDK-8289129): [JDK-8287281](https://bugs.openjdk.org/browse/JDK-8287281) is the cause. ------------- PR: https://git.openjdk.org/jdk/pull/9272 From tschatzl at openjdk.org Fri Jun 24 18:56:26 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 24 Jun 2022 18:56:26 GMT Subject: RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 Message-ID: Hi all, can I have reviews for this change that fixes an assertion failure when trying to add annotations to the hs_err file? The `block_start` API from `CollectedHeap` assumes that useful values for all given addresses is returned, not asserting/crashing like some method deeper in the call chain does since [JDK-8270540](https://bugs.openjdk.org/browse/JDK-8270540), resulting in somewhat scrambled hs_err files and additional stack frames to look at in the debugger. Testing: local compilation, gha, tier1-3 Thanks, Thomas ------------- Commit messages: - Return the original value for addresses > top in G1CollectedHeap::block_start instead of crashing Changes: https://git.openjdk.org/jdk19/pull/68/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=68&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289093 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/68.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/68/head:pull/68 PR: https://git.openjdk.org/jdk19/pull/68 From ayang at openjdk.org Fri Jun 24 22:15:56 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 24 Jun 2022 22:15:56 GMT Subject: RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 In-Reply-To: References: Message-ID: <4cEnQDr8t7oT83U8Xoifmw-G43lO3WxqoQRFVbAFpO8=.8ecb08f7-1b0c-4665-b166-f599bfaf8162@github.com> On Fri, 24 Jun 2022 12:04:49 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes an assertion failure when trying to add annotations to the hs_err file? > > The `block_start` API from `CollectedHeap` assumes that useful values for all given addresses is returned, not asserting/crashing like some method deeper in the call chain does since [JDK-8270540](https://bugs.openjdk.org/browse/JDK-8270540), resulting in somewhat scrambled hs_err files and additional stack frames to look at in the debugger. > > Testing: local compilation, gha, tier1-3 > > Thanks, > Thomas src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2355: > 2353: // outside of the allocated area. > 2354: if (addr >= hr->top()) { > 2355: return hr->top(); In the caller, `block_is_obj` from `if (p != NULL && CollectedHeapT::heap()->block_is_obj(p)) {` would choke on `top` as well, right? Returning `nullptr` makes more sense to me. ------------- PR: https://git.openjdk.org/jdk19/pull/68 From kbarrett at openjdk.org Sat Jun 25 00:19:46 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 25 Jun 2022 00:19:46 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 08:38:04 GMT, Thomas Schatzl wrote: >> I had something like that, but the "not observable" part was not that clear in my results (i.e. during garbage collection; "not clear" as in it seems to be slower) so I only optimized the part where this can be statically determined for now. > > CPU resources like branch prediction/speculative execution aren't free either, and this is a very performance sensitive area of code. > I'm planning to revisit this again for the card scanning code which in 99% of cases takes the aligned path. Then why not just card-align addr and always use the fast path code? ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Sat Jun 25 19:56:02 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Sat, 25 Jun 2022 19:56:02 GMT Subject: RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 In-Reply-To: <4cEnQDr8t7oT83U8Xoifmw-G43lO3WxqoQRFVbAFpO8=.8ecb08f7-1b0c-4665-b166-f599bfaf8162@github.com> References: <4cEnQDr8t7oT83U8Xoifmw-G43lO3WxqoQRFVbAFpO8=.8ecb08f7-1b0c-4665-b166-f599bfaf8162@github.com> Message-ID: On Fri, 24 Jun 2022 22:12:16 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> can I have reviews for this change that fixes an assertion failure when trying to add annotations to the hs_err file? >> >> The `block_start` API from `CollectedHeap` assumes that useful values for all given addresses is returned, not asserting/crashing like some method deeper in the call chain does since [JDK-8270540](https://bugs.openjdk.org/browse/JDK-8270540), resulting in somewhat scrambled hs_err files and additional stack frames to look at in the debugger. >> >> Testing: local compilation, gha, tier1-3 >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2355: > >> 2353: // outside of the allocated area. >> 2354: if (addr >= hr->top()) { >> 2355: return hr->top(); > > In the caller, `block_is_obj` from `if (p != NULL && CollectedHeapT::heap()->block_is_obj(p)) {` would choke on `top` as well, right? Returning `nullptr` makes more sense to me. Or fixing `block_is_obj`... ------------- PR: https://git.openjdk.org/jdk19/pull/68 From tschatzl at openjdk.org Sat Jun 25 19:56:03 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Sat, 25 Jun 2022 19:56:03 GMT Subject: RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 In-Reply-To: References: <4cEnQDr8t7oT83U8Xoifmw-G43lO3WxqoQRFVbAFpO8=.8ecb08f7-1b0c-4665-b166-f599bfaf8162@github.com> Message-ID: On Sat, 25 Jun 2022 19:51:05 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2355: >> >>> 2353: // outside of the allocated area. >>> 2354: if (addr >= hr->top()) { >>> 2355: return hr->top(); >> >> In the caller, `block_is_obj` from `if (p != NULL && CollectedHeapT::heap()->block_is_obj(p)) {` would choke on `top` as well, right? Returning `nullptr` makes more sense to me. > > Or fixing `block_is_obj`... Originally the method returned `nullptr`, but I'm not sure this is the best option, but probably the best for this change. ------------- PR: https://git.openjdk.org/jdk19/pull/68 From aturbanov at openjdk.org Mon Jun 27 07:32:57 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 27 Jun 2022 07:32:57 GMT Subject: Integrated: 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 09:19:33 GMT, Andrey Turbanov wrote: > Update code checks both non-null and instance of a class in jdk.hotspot.agent module classes. > The checks and explicit casts could also be replaced with pattern matching for the instanceof operator. > > For example, the following code: > > Object node = tree.getLastSelectedPathComponent(); > if (node != null && node instanceof SimpleTreeNode) { > showInspector((SimpleTreeNode)node); > } > > Can be simplified to: > > Object node = tree.getLastSelectedPathComponent(); > if (node instanceof SimpleTreeNode simpleNode) { > showInspector(simpleNode); > } > > > See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422) This pull request has now been integrated. Changeset: 7905788e Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/7905788e969727c81eea4397f0d9b918cdb5286a Stats: 62 lines in 18 files changed: 0 ins; 13 del; 49 mod 8289126: Cleanup unnecessary null comparison before instanceof check in jdk.hotspot.agent Reviewed-by: ayang, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/9272 From tschatzl at openjdk.org Mon Jun 27 08:31:01 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 27 Jun 2022 08:31:01 GMT Subject: [jdk19] RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that fixes an assertion failure when trying to add annotations to the hs_err file? > > The `block_start` API from `CollectedHeap` assumes that useful values for all given addresses is returned, not asserting/crashing like some method deeper in the call chain does since [JDK-8270540](https://bugs.openjdk.org/browse/JDK-8270540), resulting in somewhat scrambled hs_err files and additional stack frames to look at in the debugger. > > Testing: local compilation, gha, tier1-3 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix return value to just return null ------------- Changes: - all: https://git.openjdk.org/jdk19/pull/68/files - new: https://git.openjdk.org/jdk19/pull/68/files/e008106f..aa029e46 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk19&pr=68&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=68&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/68.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/68/head:pull/68 PR: https://git.openjdk.org/jdk19/pull/68 From tschatzl at openjdk.org Mon Jun 27 08:31:02 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 27 Jun 2022 08:31:02 GMT Subject: [jdk19] RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 [v2] In-Reply-To: References: <4cEnQDr8t7oT83U8Xoifmw-G43lO3WxqoQRFVbAFpO8=.8ecb08f7-1b0c-4665-b166-f599bfaf8162@github.com> Message-ID: <1gpi6xVPXw66_rPO-FSBXKWJtQ9DCKzlRl1-o_cH_Go=.13a52ce3-afc5-44d8-9ea3-c4f3ec3e3a10@github.com> On Sat, 25 Jun 2022 19:52:05 GMT, Thomas Schatzl wrote: >> Or fixing `block_is_obj`... > > Originally the method returned `nullptr`, but I'm not sure this is the best option, but probably the best for this change. I just return `nullptr`, fixing `block_is_obj` (returning false for addresses >= top) does not seem to be worth. ------------- PR: https://git.openjdk.org/jdk19/pull/68 From tschatzl at openjdk.org Mon Jun 27 08:41:25 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 27 Jun 2022 08:41:25 GMT Subject: RFR: 8288947: G1: Consolidate per-region info query in G1CollectedHeap In-Reply-To: References: Message-ID: On Wed, 22 Jun 2022 10:00:51 GMT, Albert Mingkun Yang wrote: > Simple change of removing `_humongous_reclaim_candidates`. > > Test: tier1-6 Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9233 From ayang at openjdk.org Mon Jun 27 08:51:35 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 27 Jun 2022 08:51:35 GMT Subject: [jdk19] RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 08:31:01 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that fixes an assertion failure when trying to add annotations to the hs_err file? >> >> The `block_start` API from `CollectedHeap` assumes that useful values for all given addresses is returned, not asserting/crashing like some method deeper in the call chain does since [JDK-8270540](https://bugs.openjdk.org/browse/JDK-8270540), resulting in somewhat scrambled hs_err files and additional stack frames to look at in the debugger. >> >> Testing: local compilation, gha, tier1-3 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Fix return value to just return null Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/68 From tschatzl at openjdk.org Mon Jun 27 10:07:38 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 27 Jun 2022 10:07:38 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code In-Reply-To: References: Message-ID: On Sat, 25 Jun 2022 00:16:43 GMT, Kim Barrett wrote: >> CPU resources like branch prediction/speculative execution aren't free either, and this is a very performance sensitive area of code. >> I'm planning to revisit this again for the card scanning code which in 99% of cases takes the aligned path. > > Then why not just card-align addr and always use the fast path code? @kimbarrett: The `block_start` method returns the first object reaching into `addr`; if we aligned first, then the result would be the first object reaching into `aligned(addr)` which is different; the callers would need to advance forward not-requested objects then. Or maybe I'm missing something in your suggestion? ------------- PR: https://git.openjdk.org/jdk/pull/9059 From iwalulya at openjdk.org Mon Jun 27 10:55:50 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 27 Jun 2022 10:55:50 GMT Subject: [jdk19] RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 08:31:01 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that fixes an assertion failure when trying to add annotations to the hs_err file? >> >> The `block_start` API from `CollectedHeap` assumes that useful values for all given addresses is returned, not asserting/crashing like some method deeper in the call chain does since [JDK-8270540](https://bugs.openjdk.org/browse/JDK-8270540), resulting in somewhat scrambled hs_err files and additional stack frames to look at in the debugger. >> >> Testing: local compilation, gha, tier1-3 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Fix return value to just return null Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/68 From tschatzl at openjdk.org Mon Jun 27 11:41:51 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 27 Jun 2022 11:41:51 GMT Subject: [jdk19] RFR: 8289093: BlockLocationPrinter fails to decode addresses with G1 [v2] In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 08:43:13 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix return value to just return null > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @walulyai for your reviews. ------------- PR: https://git.openjdk.org/jdk19/pull/68 From tschatzl at openjdk.org Mon Jun 27 11:45:41 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 27 Jun 2022 11:45:41 GMT Subject: [jdk19] Integrated: 8289093: BlockLocationPrinter fails to decode addresses with G1 In-Reply-To: References: Message-ID: On Fri, 24 Jun 2022 12:04:49 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes an assertion failure when trying to add annotations to the hs_err file? > > The `block_start` API from `CollectedHeap` assumes that useful values for all given addresses is returned, not asserting/crashing like some method deeper in the call chain does since [JDK-8270540](https://bugs.openjdk.org/browse/JDK-8270540), resulting in somewhat scrambled hs_err files and additional stack frames to look at in the debugger. > > Testing: local compilation, gha, tier1-3 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 699ad45b Author: Thomas Schatzl URL: https://git.openjdk.org/jdk19/commit/699ad45b4339940980314d4cd6e4606a66183fda Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8289093: BlockLocationPrinter fails to decode addresses with G1 Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk19/pull/68 From tschatzl at openjdk.org Mon Jun 27 13:50:27 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 27 Jun 2022 13:50:27 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v8] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? > > Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. > > G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. > The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://urldefense.com/v3/__https://doi.org/10.1145*2F1029873.1029879__;JQ!!ACWV5N9M2RV99hQ!KmUQeKTFpwGoanrsb64PnlyRL7CJwIM7N30IrdMgOy3_arurzZF6aPKtSFQv5dY3sbMU8JC7_gs6uOmIZDBOxp4IJKo$ )). > > This mechanism has several drawbacks: > > * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage > * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region > > The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". > > That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. > > This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: > > * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. > * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8884__;!!ACWV5N9M2RV99hQ!KmUQeKTFpwGoanrsb64PnlyRL7CJwIM7N30IrdMgOy3_arurzZF6aPKtSFQv5dY3sbMU8JC7_gs6uOmIZDBOFsWKJpQ$ ) and exploited in this change. This removes a few 100 LOC of changes :) > > Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. > > Let me describe the relation of tams and pb during the various phases in gc: > > Young-only gcs (and initial state): > `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap > > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ > | > tams, pb, tars > > During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. > Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ > | | > pb tams > > From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. > > Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. > > Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. > Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ ^ > | | | > tams pb (tars) > > As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. > > Evacuation failure handling: evacuation failure handling has been modified to accomodate this: > > * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. > * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. > > Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. > > Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into pull/8957 - Fix bits-above-tams verification Fix issue with region liveness logging, using outdated value - Fix bitmap verification - full gc before verification - More log messages fix compilation... ayang comments Some cleanup aborted full collection fix Minor changes More cleanup - Re-add skipping of scanning for remembered sets if unnecessary - More cleanups - Minor renaming to conform to existing nomenclature - ayang, iwalulya review: cleanups - ayang review2; more cleanup of unnecessary changes, asserts - ... and 12 more: https://git.openjdk.org/jdk/compare/be6be15e...0519982f ------------- Changes: https://git.openjdk.org/jdk/pull/8957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=07 Stats: 1821 lines in 48 files changed: 772 ins; 607 del; 442 mod Patch: https://git.openjdk.org/jdk/pull/8957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8957/head:pull/8957 PR: https://git.openjdk.org/jdk/pull/8957 From zgu at openjdk.org Mon Jun 27 23:04:29 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 27 Jun 2022 23:04:29 GMT Subject: RFR: 8287818: Shenandoah: adapt nmethod arming from Loom [v3] In-Reply-To: References: Message-ID: > Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it. > > Test: > > - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64 > - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 > - [x] hotspot_gc_shenandoah on AArch64 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Add assertion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9048/files - new: https://git.openjdk.org/jdk/pull/9048/files/b4ef6d63..b496a508 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9048&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9048&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9048.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9048/head:pull/9048 PR: https://git.openjdk.org/jdk/pull/9048 From zgu at openjdk.org Tue Jun 28 12:21:42 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 28 Jun 2022 12:21:42 GMT Subject: Integrated: 8287818: Shenandoah: adapt nmethod arming from Loom In-Reply-To: References: Message-ID: On Mon, 6 Jun 2022 23:29:10 GMT, Zhengyu Gu wrote: > Loom implemented nmethod arming mechanism, which is very similar to Shenandoah's. Shenandoah can use it. > > Test: > > - [x] hotspot_gc_shenandoah on Linux x86_64 and Windows x64 > - [x] tier1 with Shenandoah GC on Linux x86_64 and Windows x64 > - [x] hotspot_gc_shenandoah on AArch64 This pull request has now been integrated. Changeset: 549c6c22 Author: Zhengyu Gu URL: https://git.openjdk.org/jdk/commit/549c6c22aedc5a7f2acd0b0ceabf956227e35cb3 Stats: 52 lines in 5 files changed: 4 ins; 40 del; 8 mod 8287818: Shenandoah: adapt nmethod arming from Loom Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/9048 From zgu at openjdk.org Tue Jun 28 12:45:44 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 28 Jun 2022 12:45:44 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v3] In-Reply-To: References: <2WEjdZmJPwCTHO7oIxcWBzF__aK9_Thz7Qfig1CweAA=.da88a7dd-d252-49ff-b7dd-e92d6e95dbab@github.com> Message-ID: On Fri, 24 Jun 2022 17:45:48 GMT, Aleksey Shipilev wrote: > I still dislike the fact we are calling `Thread::current()` on hotpath. I think we can do better. Consider this modification on top of your current PR: http://cr.openjdk.java.net/~shade/8287805/thread-1.patch -- does that look better? Are your referring to `ShenandoahEvacuateUpdateRootsClosure`? It has to be context free closure, since it is a shared closure used by stack watermark processing. ------------- PR: https://git.openjdk.org/jdk/pull/9023 From ayang at openjdk.org Wed Jun 29 11:30:42 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 29 Jun 2022 11:30:42 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code In-Reply-To: References: Message-ID: On Mon, 27 Jun 2022 10:03:56 GMT, Thomas Schatzl wrote: >> Then why not just card-align addr and always use the fast path code? > > @kimbarrett: The `block_start` method returns the first object reaching into `addr`; if we aligned first, then the result would be the first object reaching into `aligned(addr)` which is different; the callers would need to advance forward not-requested objects then. > Or maybe I'm missing something in your suggestion? > I had something like that, but the "not observable" part was not that clear in my results I added the following to `G1BlockOffsetTablePart::block_start` to see the cost. if (is_aligned(addr, BOTConstants::card_size())) { return q; } Using `Scan Heap Roots (ms)` and `Scanned Cards` from `-Xlog:gc,gc+phases`, I can calculate #cards processed per ms. Surprisingly, I can observe some reduction (~2.7%) in this metric on my box. Re Kim's suggestion, the model where `G1BlockOffsetTablePart::block_start` accepts only card-aligned addresses and the caller (`HeapRegion::block_start`) handles block-walking (heap parsing) makes more sense to me. (After all, "block size" is sth meaningful only inside `HeapRegion`.) Ofc, this can be dealt with in this PR or another. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Thu Jun 30 10:21:40 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 30 Jun 2022 10:21:40 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code In-Reply-To: References: Message-ID: On Wed, 29 Jun 2022 11:26:59 GMT, Albert Mingkun Yang wrote: >> @kimbarrett: The `block_start` method returns the first object reaching into `addr`; if we aligned first, then the result would be the first object reaching into `aligned(addr)` which is different; the callers would need to advance forward not-requested objects then. >> Or maybe I'm missing something in your suggestion? > >> I had something like that, but the "not observable" part was not that clear in my results > > I added the following to `G1BlockOffsetTablePart::block_start` to see the cost. > > > if (is_aligned(addr, BOTConstants::card_size())) { > return q; > } > > > Using `Scan Heap Roots (ms)` and `Scanned Cards` from `-Xlog:gc,gc+phases`, I can calculate #cards processed per ms. Surprisingly, I can observe some reduction (~2.7%) in this metric on my box. > > Re Kim's suggestion, the model where `G1BlockOffsetTablePart::block_start` accepts only card-aligned addresses and the caller (`HeapRegion::block_start`) handles block-walking (heap parsing) makes more sense to me. (After all, "block size" is sth meaningful only inside `HeapRegion`.) Ofc, this can be dealt with in this PR or another. [Here](https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:submit/move-block-size-out-of-bot?expand=1)'s a prototype for (trying to) move `block_start` out of `G1BlockOffsetTablePart`; in the end I have a bit of mixed feelings about it: * the BlockOffsetTable deals with blocks; blocks intrinsically have a start and a size; removing the BlockOffsetTable to only deal with parts of a block seems a bit limited. Additionally not knowing about size will require to move out `verify` too if we are strict about this distinction, which means that lots of code is being dumped in the already (too) large `HeapRegion` class. Of course, like in the prototype, the `G1BlockOffsetTablePart::verify` could also stay as is.... * the BlockOffsetTable is already very tightly dependent on `HeapRegion` anyway (for current layout, i.e. `bottom`, `top`, `end`). Comments? ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Thu Jun 30 12:03:37 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 30 Jun 2022 12:03:37 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v9] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? > > Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. > > G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. > The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://doi.org/10.1145%2F1029873.1029879)). > > This mechanism has several drawbacks: > > * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage > * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region > > The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". > > That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. > > This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: > > * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. > * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://github.com/openjdk/jdk/pull/8884) and exploited in this change. This removes a few 100 LOC of changes :) > > Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. > > Let me describe the relation of tams and pb during the various phases in gc: > > Young-only gcs (and initial state): > `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap > > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ > | > tams, pb, tars > > During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. > Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ > | | > pb tams > > From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. > > Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. > > Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. > Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ ^ > | | | > tams pb (tars) > > As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. > > Evacuation failure handling: evacuation failure handling has been modified to accomodate this: > > * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. > * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. > > Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. > > Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix compilation after merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8957/files - new: https://git.openjdk.org/jdk/pull/8957/files/0519982f..b33a015a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/8957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8957/head:pull/8957 PR: https://git.openjdk.org/jdk/pull/8957 From tschatzl at openjdk.org Thu Jun 30 12:47:10 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 30 Jun 2022 12:47:10 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v10] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes one of the mark bitmaps in G1 to save memory? > > Previously G1 used two mark bitmaps, one that has been in use for current liveness determination ("prev bitmap"), one that is currently being built ("next bitmap"); these two then were swapped during the remark pause. > > G1 needed the current liveness information to determine whether an object (and the corresponding klass) below the respective top-at-mark-start is live, i.e. could be read from. > The mechanism is described in detail in the "Garbage-First Garbage Collection Paper" by Detlefs et al ([doi](https://doi.org/10.1145%2F1029873.1029879)). > > This mechanism has several drawbacks: > > * you need twice the space than actually necessary as we will see; this space is significant as a bitmap adds ~1.5% of Java heap size to the G1 native memory usage > * during scanning the cards you need to rely a lot on walking the bitmaps (below tams) which is extra work, and actually most of the time it is the case that the tams is at the end of the region > > The alternative presented here is to reformat the holes between objects with filler objects; this is a traditional sweep over the heap which has originally been considered fairly expensive. However since JDK 11 G1 already does that sweep anyway when rebuilding remembered sets, and during this investigation it has been shown that reformatting the holes is "for free". > > That reformatting not only includes actually stuffing filler objects into these holes, but also updating the BOT concurrently. > > This concurrency has some drawback: after class unloading (in the remark pause) and before the Cleanup pause (which indicates the end of the concurrent rebuilding of the remsets and scrubbing the regions phase) using the BOT needs some care: > > * during GC actually there is no issue: the BOT is at least stable in that it can not change while accessing it; the BOT may still point to dead objects, but these can be found using the bitmap. > * during concurrent refinement we can still use the BOT, because any mix of old BOT and new BOT eventually leads to some object start, i.e. an object before a given address. However that object may have been overwritten on the heap by filler object data, in a way that the heap is not parsable at the moment. So we must completely rely on the bitmap finding a valid object start from that (preliminary) object start. This observation is the difference to the previous [PR#8884](https://github.com/openjdk/jdk/pull/8884) and exploited in this change. This removes a few 100 LOC of changes :) > > Above I mentioned that there is a distinction between objects that can be parsed directly and objects for which we need to use the bitmap. For this reason the code introduces a per-region new marker called `parsable_bottom` (typically called `pb` in the code, similar to tams) that indicates from which address within the region the heap is parsable. > > Let me describe the relation of tams and pb during the various phases in gc: > > Young-only gcs (and initial state): > `pb = tams = tars = bottom`; card scanning always uses the BOT/direct scanning of the heap > > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ > | > tams, pb, tars > > During Concurrent Mark Start until Remark: `tams = top, pb = bottom`; concurrent marking runs; we can still use BOT/direct scanning of the heap for refinement and gc card scan. > Marking not only marks objects from bottom to tams, but also sets a flag in the back scan skip table on a fairly coarse basis. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ > | | > pb tams > > From Remark -> Cleanup: `pb = tams; tams = bottom; tars = top;` Remark unloaded classes, so we set `pb` to `tams`; in the region at addresses < `tams` we might encounter unparsable objects. This means that during this time, refinement can not use the BOT to find valid objects spanning into the card it wants to scan as described above. Use the bitmap for that. > > Rebuild the remembered sets from `bottom` to `tars`, and scrub the heap from `bottom` to `pb`. > > Note that the change sets `pb` incrementally (and concurrently) back to bottom as a region finishes scrubbing to decrease the size of the area we need to use the bitmap to help as a BOT replacement. > Scrubbing means: put filler objects in holes of dead objects, and update the BOT according to these filler objects. > > bottom top > | | > v v > +---------------------+ > | | > +---------------------| > ^ ^ ^ > | | | > tams pb (tars) > > As soon as scrubbing finishes on a per-region basis: Set `pb` to `bottom` - the whole region is now parsable again. At Cleanup, all regions are scrubbed. > > Evacuation failure handling: evacuation failure handling has been modified to accomodate this: > > * evac failure expects that the bitmap is clear for regions to (intermittently) mark live objects there. This still applies - the young collection needs to clear old gen regions, but only after the Cleanup pause (G1 can only have mixed gcs after cleanup) because only at that point marks may still be left from the marking on the bitmap of old regions. The young gc just clears those (and only those) at the beginning of gc. It also clears the bitmaps of old gen regions in the remove self-forwards phase. > * evac failure of young regions is handled as before: after evacuation failure the region is left as old gen region with marks below tams in the concurrent start pause, otherwise the bitmap is cleared. > > Thanks go to @kstefanj for the initial prototype, @walulyai for taking over for a bit. I'll add both as contributors/authors. > > Testing: tier1-5 (multiple times), tier 6-8 (running, but the previous version in PR#8884 completed this one fine) > > Thanks, > Thomas Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - Merge branch 'master' into pull/8957 - Fix compilation after merge - Merge branch 'master' into pull/8957 - Fix bits-above-tams verification Fix issue with region liveness logging, using outdated value - Fix bitmap verification - full gc before verification - More log messages fix compilation... ayang comments Some cleanup aborted full collection fix Minor changes More cleanup - Re-add skipping of scanning for remembered sets if unnecessary - More cleanups - Minor renaming to conform to existing nomenclature - ... and 14 more: https://git.openjdk.org/jdk/compare/feb223aa...f29c0f1c ------------- Changes: https://git.openjdk.org/jdk/pull/8957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=09 Stats: 1822 lines in 48 files changed: 773 ins; 607 del; 442 mod Patch: https://git.openjdk.org/jdk/pull/8957.diff Fetch: git fetch https://git.openjdk.org/jdk pull/8957/head:pull/8957 PR: https://git.openjdk.org/jdk/pull/8957 From txiadev at gmail.com Thu Jun 30 14:24:30 2022 From: txiadev at gmail.com (Tianqi Xia) Date: Thu, 30 Jun 2022 22:24:30 +0800 Subject: Reduce CPU usage of Remembered Sets by configuring grow hint of concurrent hash table Message-ID: Currently G1CardSet uses a concurrent hash table under the hood to keep a mapping between heap regions and card set containers. After running some experiments, I found adjusting the grow hint of the underlying concurrent hash table can potentially bring down the overall CPU usage of the process quite a bit. Here is a brief summary of my testing result: Benchmark: BigRamTester JDK version: master branch, commit 779b4e1d1959bc15a27492b7e2b951678e39cca8 Testing command: java -XX:+AlwaysPreTouch -Xlog:gc*=debug:gc.log::filecount=10,filesize=20m -Xms20g -Xmx20g BigRamTester Without any modification, the average CPU usage (measured by top, with 5-min sampling period) is roughly 660%; After changing the grow hint of the card set concurrent hash table from 4 to 1, the CPU usage can be reduced to 620%. The impact of this change on memory usage is minimal. The RES (report by top) before/after the change is something like 21.295G vs 21.30G, and the native memory usage of G1CardSet (report by NMT) also shows no difference. Theoretically by increasing the grow hint, we are preferring a more "flatten" hash table: less time is spent on traversing the collision list, less CPU is used. What I propose is, shall we make the grow hint a configurable parameter? Please let me know if i missed anything. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Thu Jun 30 14:52:13 2022 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 30 Jun 2022 16:52:13 +0200 Subject: Reduce CPU usage of Remembered Sets by configuring grow hint of concurrent hash table In-Reply-To: References: Message-ID: <27ab1d13-1e7a-3f40-935f-8841984ad045@oracle.com> Hi, On 30.06.22 16:24, Tianqi Xia wrote: > Currently G1CardSet uses a concurrent hash table under the hood to keep > a mapping between heap regions and card set containers. After running > some experiments, I found adjusting the grow hint of the underlying > concurrent hash table can potentially bring down the overall CPU usage > of the process quite a bit. > > Here is a brief summary of my testing result: > > Benchmark: BigRamTester > > JDK version: master branch, commit 779b4e1d1959bc15a27492b7e2b951678e39cca8 > > Testing command: java -XX:+AlwaysPreTouch > -Xlog:gc*=debug:gc.log::filecount=10,filesize=20m -Xms20g -Xmx20g > BigRamTester > > Without any modification, the average CPU usage (measured by top, with > 5-min sampling period) is roughly 660%; After changing the grow hint of > the card set concurrent hash table from 4 to 1, the CPU usage can be > reduced to 620%. > > The impact of this change on memory usage is minimal. The RES (report by > top) before/after the change is something like 21.295G vs 21.30G, and > the native memory usage of G1CardSet (report by NMT) also shows no > difference. > > Theoretically by increasing the grow hint, we are preferring a more > "flatten" hash table: less time is spent on traversing the collision > list, less CPU is used. What I propose is, shall we make the grow hint a > configurable parameter? Please let me know if i missed anything. > we've had something like this in the initial implementation but did not have time to look into this some more, so removed that interface to the user. E.g. see the constructor of G1CardSetHashTable where there is a parameter to set its initial size, but never use it. Same about the maximum typical number of links in the chain. Similar applies to G1SegmentedArrayAllocOptions always being the same (or even having different G1CardSetConfigurations). Did you test with different initial settings for different types of regions? Particularly bigramtester tends to have fairly unique distribution depending on generation iirc. Ideally these values would somehow be automatically derived, and not set by an option. So in general, yes, we are interested in improvements there. As a first step it would also be useful to e.g. print gc/refinement threads' vtime (I think this would mostly reduce refinement thread vtimes?) in a more straightforward/useful manner (and just ignore the OSes where this is not easily possible). I'm thinking about some (periodic?) log output that just prints (refinement) thread vtimes one after another (maybe relative?), maybe with an initial header, but I haven't thought it through. There is some (badly formatted) output for the marking threads iirc already. At least I think it would generally be fairly useful to provide such information by the VM as hooking some third party tool is sometimes a bit cumbersome. Of course, all this is just my initial reaction, I'm hoping others chime in too :) Thanks, Thomas From ayang at openjdk.org Thu Jun 30 15:10:59 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 30 Jun 2022 15:10:59 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 10:18:15 GMT, Thomas Schatzl wrote: >>> I had something like that, but the "not observable" part was not that clear in my results >> >> I added the following to `G1BlockOffsetTablePart::block_start` to see the cost. >> >> >> if (is_aligned(addr, BOTConstants::card_size())) { >> return q; >> } >> >> >> Using `Scan Heap Roots (ms)` and `Scanned Cards` from `-Xlog:gc,gc+phases`, I can calculate #cards processed per ms. Surprisingly, I can observe some reduction (~2.7%) in this metric on my box. >> >> Re Kim's suggestion, the model where `G1BlockOffsetTablePart::block_start` accepts only card-aligned addresses and the caller (`HeapRegion::block_start`) handles block-walking (heap parsing) makes more sense to me. (After all, "block size" is sth meaningful only inside `HeapRegion`.) Ofc, this can be dealt with in this PR or another. > > [Here](https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:submit/move-block-size-out-of-bot?expand=1)'s a prototype for (trying to) move `block_start` out of `G1BlockOffsetTablePart`; in the end I have a bit of mixed feelings about it: > * the BlockOffsetTable deals with blocks; blocks intrinsically have a start and a size; removing the BlockOffsetTable to only deal with parts of a block seems a bit limited. > Additionally not knowing about size will require to move out `verify` too if we are strict about this distinction, which means that lots of code is being dumped in the already (too) large `HeapRegion` class. Of course, like in the prototype, the `G1BlockOffsetTablePart::verify` could also stay as is.... > * the BlockOffsetTable is already very tightly dependent on `HeapRegion` anyway (for current layout, i.e. `bottom`, `top`, `end`). > > Comments? The structure of the patch looks good. Both options (leaking block-walking logic to `G1BlockOffsetTablePart` or moving `verify` to `HeapRegion`) are OK to me, though I prefer a third option -- removing `verify()` directly, since the BOT algorithm is not updated constantly. `verify()` essentially never fails. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From zgu at openjdk.org Thu Jun 30 19:42:42 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 30 Jun 2022 19:42:42 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v4] In-Reply-To: References: Message-ID: > ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated. > > Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated. > > Test: > > - [x] hotspot_gc_shenandoah Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Aleksey's comment - Merge branch 'master' into JDK-8287805-evac-updt-closures - v1 - Remove unused impl - Review feedback - Merge branch 'master' into JDK-8287805-evac-updt-closures - 8287805: Shenandoah: consolidate evacuate-update-root closures - Merge branch 'master' into consolidate_evac_root_closures - v0 - v0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9023/files - new: https://git.openjdk.org/jdk/pull/9023/files/689335bf..f076e810 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=02-03 Stats: 26049 lines in 302 files changed: 23432 ins; 1854 del; 763 mod Patch: https://git.openjdk.org/jdk/pull/9023.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9023/head:pull/9023 PR: https://git.openjdk.org/jdk/pull/9023