From tschatzl at openjdk.org Fri Jul 1 08:28:33 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Jul 2022 08:28:33 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v11] In-Reply-To: References: Message-ID: <2RPUNFiZBa8gH07RpjArryHGkfY5GV9-fYUcvzNgKDo=.0385f7ab-9266-4241-8964-2e5232d7e135@github.com> > 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: Bitmap clear during full gc verification must happen after before-verificaton ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8957/files - new: https://git.openjdk.org/jdk/pull/8957/files/f29c0f1c..04a243ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=09-10 Stats: 34 lines in 5 files changed: 22 ins; 5 del; 7 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 Fri Jul 1 08:35:25 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Jul 2022 08:35:25 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v12] 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: Remove debug code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8957/files - new: https://git.openjdk.org/jdk/pull/8957/files/04a243ee..164a52e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=10-11 Stats: 16 lines in 1 file changed: 0 ins; 16 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 ayang at openjdk.org Fri Jul 1 10:29:04 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 1 Jul 2022 10:29:04 GMT Subject: RFR: 8289575: G1: Remove unnecessary is-marking-active check in G1BarrierSetRuntime::write_ref_field_pre_entry Message-ID: Simple change of removing an unnecessary check. After that, the `enqueue` method becomes unused so removed as well. Test: tier1-3 ------------- Commit messages: - g1-pre-barrier-jrt-entry Changes: https://git.openjdk.org/jdk/pull/9345/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9345&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289575 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9345.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9345/head:pull/9345 PR: https://git.openjdk.org/jdk/pull/9345 From tschatzl at openjdk.org Fri Jul 1 11:33:38 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Jul 2022 11:33:38 GMT Subject: RFR: 8289575: G1: Remove unnecessary is-marking-active check in G1BarrierSetRuntime::write_ref_field_pre_entry In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 10:19:10 GMT, Albert Mingkun Yang wrote: > Simple change of removing an unnecessary check. After that, the `enqueue` method becomes unused so removed as well. > > Test: tier1-3 Lgtm. I closed [JDK-8258607](https://bugs.openjdk.org/browse/JDK-8258607) as duplicate of this as this change removes the last use of `SATBMarkQueue::enqueue`. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9345 From iwalulya at openjdk.org Fri Jul 1 12:42:39 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Fri, 1 Jul 2022 12:42:39 GMT Subject: RFR: 8289575: G1: Remove unnecessary is-marking-active check in G1BarrierSetRuntime::write_ref_field_pre_entry In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 10:19:10 GMT, Albert Mingkun Yang wrote: > Simple change of removing an unnecessary check. After that, the `enqueue` method becomes unused so removed as well. > > Test: tier1-3 Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9345 From tschatzl at openjdk.org Fri Jul 1 19:32:30 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 1 Jul 2022 19:32:30 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v13] 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 review, cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8957/files - new: https://git.openjdk.org/jdk/pull/8957/files/164a52e9..212f8712 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=11-12 Stats: 16 lines in 5 files changed: 2 ins; 5 del; 9 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 shade at openjdk.org Mon Jul 4 07:42:49 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 4 Jul 2022 07:42:49 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v4] In-Reply-To: References: Message-ID: On Thu, 30 Jun 2022 19:42:42 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 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 Looks fine, with minor nits. src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp line 145: > 143: > 144: Thread* thr = stable_thread ? _thread : Thread::current(); > 145: assert(thr == Thread::current(), "Wrong thread"); I think we can move these lines down to the only use in this thread. This would keep `Thread::current()` out of the hotpath. src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp line 148: > 146: > 147: T o = RawAccess<>::oop_load(p); > 148: if (! CompressedOops::is_null(o)) { Redundant whitespace? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9023 From ayang at openjdk.org Mon Jul 4 08:06:45 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Jul 2022 08:06:45 GMT Subject: RFR: 8289575: G1: Remove unnecessary is-marking-active check in G1BarrierSetRuntime::write_ref_field_pre_entry In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 10:19:10 GMT, Albert Mingkun Yang wrote: > Simple change of removing an unnecessary check. After that, the `enqueue` method becomes unused so removed as well. > > Test: tier1-3 Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9345 From ayang at openjdk.org Mon Jul 4 08:06:46 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Jul 2022 08:06:46 GMT Subject: Integrated: 8289575: G1: Remove unnecessary is-marking-active check in G1BarrierSetRuntime::write_ref_field_pre_entry In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 10:19:10 GMT, Albert Mingkun Yang wrote: > Simple change of removing an unnecessary check. After that, the `enqueue` method becomes unused so removed as well. > > Test: tier1-3 This pull request has now been integrated. Changeset: e31003a0 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/e31003a064693765a52f15ff9d4de2c342869a13 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod 8289575: G1: Remove unnecessary is-marking-active check in G1BarrierSetRuntime::write_ref_field_pre_entry Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9345 From iwalulya at openjdk.org Mon Jul 4 08:38:39 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 4 Jul 2022 08:38:39 GMT Subject: RFR: 8288947: G1: Consolidate per-region is-humongous 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 Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9233 From iwalulya at openjdk.org Mon Jul 4 08:38:40 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 4 Jul 2022 08:38:40 GMT Subject: RFR: 8287312: G1: Early return on first failure in VerifyRegionClosure In-Reply-To: <1PRHJMK0P8yAXVPa82qXVoCwQv_5-falHp57DT1Q1HM=.8336e203-28a3-44a0-b0eb-2e0810526ba8@github.com> References: <1PRHJMK0P8yAXVPa82qXVoCwQv_5-falHp57DT1Q1HM=.8336e203-28a3-44a0-b0eb-2e0810526ba8@github.com> Message-ID: On Wed, 25 May 2022 11:18:23 GMT, Albert Mingkun Yang wrote: > Simple restructuring to match the intent of the comment. > > Test: hotspot_gc Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/8882 From kbarrett at openjdk.org Mon Jul 4 08:44:43 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 4 Jul 2022 08:44:43 GMT Subject: RFR: 8287312: G1: Early return on first failure in VerifyRegionClosure In-Reply-To: <1PRHJMK0P8yAXVPa82qXVoCwQv_5-falHp57DT1Q1HM=.8336e203-28a3-44a0-b0eb-2e0810526ba8@github.com> References: <1PRHJMK0P8yAXVPa82qXVoCwQv_5-falHp57DT1Q1HM=.8336e203-28a3-44a0-b0eb-2e0810526ba8@github.com> Message-ID: <5UBgQ3_dBBZGU_HCs9dC-RmESICXPnW5TiLOJYySJLU=.2524e48c-9898-4b87-af73-467d294d373d@github.com> On Wed, 25 May 2022 11:18:23 GMT, Albert Mingkun Yang wrote: > Simple restructuring to match the intent of the comment. > > Test: hotspot_gc Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/8882 From ayang at openjdk.org Mon Jul 4 12:06:55 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Jul 2022 12:06:55 GMT Subject: Integrated: 8287312: G1: Early return on first failure in VerifyRegionClosure In-Reply-To: <1PRHJMK0P8yAXVPa82qXVoCwQv_5-falHp57DT1Q1HM=.8336e203-28a3-44a0-b0eb-2e0810526ba8@github.com> References: <1PRHJMK0P8yAXVPa82qXVoCwQv_5-falHp57DT1Q1HM=.8336e203-28a3-44a0-b0eb-2e0810526ba8@github.com> Message-ID: On Wed, 25 May 2022 11:18:23 GMT, Albert Mingkun Yang wrote: > Simple restructuring to match the intent of the comment. > > Test: hotspot_gc This pull request has now been integrated. Changeset: d53b02eb Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/d53b02eb9fceb6d170e0ea8613c2a064a7175892 Stats: 26 lines in 1 file changed: 10 ins; 11 del; 5 mod 8287312: G1: Early return on first failure in VerifyRegionClosure Reviewed-by: tschatzl, iwalulya, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/8882 From ayang at openjdk.org Mon Jul 4 12:06:54 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Jul 2022 12:06:54 GMT Subject: RFR: 8287312: G1: Early return on first failure in VerifyRegionClosure In-Reply-To: <1PRHJMK0P8yAXVPa82qXVoCwQv_5-falHp57DT1Q1HM=.8336e203-28a3-44a0-b0eb-2e0810526ba8@github.com> References: <1PRHJMK0P8yAXVPa82qXVoCwQv_5-falHp57DT1Q1HM=.8336e203-28a3-44a0-b0eb-2e0810526ba8@github.com> Message-ID: On Wed, 25 May 2022 11:18:23 GMT, Albert Mingkun Yang wrote: > Simple restructuring to match the intent of the comment. > > Test: hotspot_gc Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/8882 From ayang at openjdk.org Mon Jul 4 15:21:48 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Jul 2022 15:21:48 GMT Subject: RFR: 8288947: G1: Consolidate per-region is-humongous 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 Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9233 From ayang at openjdk.org Mon Jul 4 15:21:49 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 4 Jul 2022 15:21:49 GMT Subject: Integrated: 8288947: G1: Consolidate per-region is-humongous 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 This pull request has now been integrated. Changeset: bad9ffe4 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/bad9ffe47112c3d532e0486af093f662508a5816 Stats: 49 lines in 5 files changed: 4 ins; 37 del; 8 mod 8288947: G1: Consolidate per-region is-humongous query in G1CollectedHeap Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9233 From ayang at openjdk.org Tue Jul 5 09:53:46 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 5 Jul 2022 09:53:46 GMT Subject: RFR: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap Message-ID: One line change of negating a condition. Test: hotspot_gc ------------- Commit messages: - g1-cm-may-yield Changes: https://git.openjdk.org/jdk/pull/9374/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9374&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289729 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9374.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9374/head:pull/9374 PR: https://git.openjdk.org/jdk/pull/9374 From tschatzl at openjdk.org Tue Jul 5 14:13:32 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Jul 2022 14:13:32 GMT Subject: RFR: 8289740: Add verification testing during all concurrent phases in G1 Message-ID: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> Hi all, can I have reviews for this change that adds a test that causes GCs that do lots of verification in all phases of the concurrent cycle to make sure that verification is working after changes. Testing: test case, gha Thanks, Thomas ------------- Depends on: https://git.openjdk.org/jdk/pull/9376 Commit messages: - Add test - Add test Changes: https://git.openjdk.org/jdk/pull/9377/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9377&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289740 Stats: 100 lines in 1 file changed: 100 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9377.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9377/head:pull/9377 PR: https://git.openjdk.org/jdk/pull/9377 From tschatzl at openjdk.org Tue Jul 5 14:22:40 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 5 Jul 2022 14:22:40 GMT Subject: RFR: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 09:45:15 GMT, Albert Mingkun Yang wrote: > One line change of negating a condition. > > Test: hotspot_gc Lgtm. Good catch. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9374 From tschatzl at openjdk.org Wed Jul 6 08:50:27 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 08:50:27 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v14] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 08:16:24 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 one additional commit since the last revision: > > Fix verification (another time) - let TAMS be kept until the last useful time The latest patch has been checked against PR#9377 and PR#9376. ------------- PR: https://git.openjdk.org/jdk/pull/8957 From tschatzl at openjdk.org Wed Jul 6 12:48:29 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 12:48:29 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v2] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 12:43:53 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 > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Cleanup > - 828755:5 Tighten G1BlockOffsetTable::block_start() code > > initial version > - Make block_start_reaching_into_card() const > - initial version After introduction of a separate change ( 8289538: Make G1BlockOffsetTablePart unaware of block sizes #9395 ) for some refactoring this change differs so much from the original so that it is more than reasonable to rebase this change on the other. Only the last commit contains this change (c3866f3fc1ef5bade3ba4d723d87c4fb8bad5000) is part of this change. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Wed Jul 6 12:43:53 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 12:43:53 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v2] In-Reply-To: References: 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 Thomas Schatzl 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 four additional commits since the last revision: - Cleanup - 828755:5 Tighten G1BlockOffsetTable::block_start() code initial version - Make block_start_reaching_into_card() const - initial version ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9059/files - new: https://git.openjdk.org/jdk/pull/9059/files/04b720b6..ac2740c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=00-01 Stats: 92000 lines in 1801 files changed: 58028 ins; 18494 del; 15478 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 Wed Jul 6 13:48:30 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Jul 2022 13:48:30 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes [v2] In-Reply-To: <7zwfjqLtp0pZCuTY58yE_oCwyqMHVus2uzy_v0kySog=.b5b68f28-3206-44a4-ab05-de1b01ac5481@github.com> References: <7zwfjqLtp0pZCuTY58yE_oCwyqMHVus2uzy_v0kySog=.b5b68f28-3206-44a4-ab05-de1b01ac5481@github.com> Message-ID: On Wed, 6 Jul 2022 12:39:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. >> >> There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. >> >> Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Make block_start_reaching_into_card() const Just some minor & subjective comment. src/hotspot/share/gc/g1/heapRegion.hpp line 151: > 149: // next block (or the end of the HeapRegion.) > 150: inline HeapWord* forward_to_block_containing_addr(HeapWord* q, HeapWord* n, > 151: const void* addr) const; Not sure how helpful this comment is; it's not that the text is hard to comprehend but rather this method is not a proper (internal) API -- it's highly dependent on its caller. Therefore, I suggest inlining it to its sole caller. src/hotspot/share/gc/g1/heapRegion.inline.hpp line 89: > 87: // being precise, we should never have to step through more than > 88: // a single card. > 89: _bot_part.assert_same_bot_entry(n, addr); I think `assert(!is_crossing_card_boundary(n, addr)` matches the comment better. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9395 From ayang at openjdk.org Wed Jul 6 13:48:30 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Jul 2022 13:48:30 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes [v2] In-Reply-To: <7zwfjqLtp0pZCuTY58yE_oCwyqMHVus2uzy_v0kySog=.b5b68f28-3206-44a4-ab05-de1b01ac5481@github.com> References: <7zwfjqLtp0pZCuTY58yE_oCwyqMHVus2uzy_v0kySog=.b5b68f28-3206-44a4-ab05-de1b01ac5481@github.com> Message-ID: On Wed, 6 Jul 2022 12:39:18 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. >> >> There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. >> >> Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Make block_start_reaching_into_card() const Just some minor & subjective comment. src/hotspot/share/gc/g1/heapRegion.hpp line 151: > 149: // next block (or the end of the HeapRegion.) > 150: inline HeapWord* forward_to_block_containing_addr(HeapWord* q, HeapWord* n, > 151: const void* addr) const; Not sure how helpful this comment is; it's not that the text is hard to comprehend but rather this method is not a proper (internal) API -- it's highly dependent on its caller. Therefore, I suggest inlining it to its sole caller. src/hotspot/share/gc/g1/heapRegion.inline.hpp line 89: > 87: // being precise, we should never have to step through more than > 88: // a single card. > 89: _bot_part.assert_same_bot_entry(n, addr); I think `assert(!is_crossing_card_boundary(n, addr)` matches the comment better. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9395 From ayang at openjdk.org Wed Jul 6 08:18:50 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Jul 2022 08:18:50 GMT Subject: RFR: 8137280: Remove eager reclaim of humongous controls Message-ID: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> Simple change of removing two experiment flags whose default value is `true`. Test: hotspot_gc ------------- Commit messages: - g1-eager-reclaim Changes: https://git.openjdk.org/jdk/pull/9392/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9392&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8137280 Stats: 35 lines in 6 files changed: 0 ins; 31 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9392.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9392/head:pull/9392 PR: https://git.openjdk.org/jdk/pull/9392 From tschatzl at openjdk.org Wed Jul 6 12:06:07 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 12:06:07 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes Message-ID: Hi all, can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade Thanks, Thomas ------------- Commit messages: - initial version Changes: https://git.openjdk.org/jdk/pull/9395/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9395&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289538 Stats: 165 lines in 6 files changed: 70 ins; 80 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9395/head:pull/9395 PR: https://git.openjdk.org/jdk/pull/9395 From tschatzl at openjdk.org Wed Jul 6 09:52:26 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 09:52:26 GMT Subject: RFR: 8289740: Add verification testing during all concurrent phases in G1 [v2] In-Reply-To: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> References: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> Message-ID: > Hi all, > > can I have reviews for this change that adds a test that causes GCs that do lots of verification in all phases of the concurrent cycle to make sure that verification is working after changes. > > Testing: test case, gha > > Thanks, > Thomas Thomas Schatzl 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9377/files - new: https://git.openjdk.org/jdk/pull/9377/files/eed786bd..eed786bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9377&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9377&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9377.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9377/head:pull/9377 PR: https://git.openjdk.org/jdk/pull/9377 From tschatzl at openjdk.org Wed Jul 6 11:28:38 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 11:28:38 GMT Subject: RFR: 8137280: Remove eager reclaim of humongous controls In-Reply-To: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> References: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> Message-ID: <3jmBS5FWvOecxyMMQYGnNeGHTkPeO5rvPEmQL31AixQ=.86a9f5eb-ffce-4a01-8fd8-44a9bb260f9d@github.com> On Wed, 6 Jul 2022 08:12:32 GMT, Albert Mingkun Yang wrote: > Simple change of removing two experiment flags whose default value is `true`. > > Test: hotspot_gc Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9392 From iwalulya at openjdk.org Wed Jul 6 06:45:44 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 6 Jul 2022 06:45:44 GMT Subject: RFR: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 09:45:15 GMT, Albert Mingkun Yang wrote: > One line change of negating a condition. > > Test: hotspot_gc Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9374 From tschatzl at openjdk.org Wed Jul 6 08:16:24 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 08:16:24 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v14] 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 verification (another time) - let TAMS be kept until the last useful time ------------- Changes: - all: https://git.openjdk.org/jdk/pull/8957/files - new: https://git.openjdk.org/jdk/pull/8957/files/212f8712..5f721dc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=12-13 Stats: 52 lines in 6 files changed: 26 ins; 10 del; 16 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 ayang at openjdk.org Wed Jul 6 14:11:51 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Jul 2022 14:11:51 GMT Subject: Withdrawn: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 09:45:15 GMT, Albert Mingkun Yang wrote: > One line change of negating a condition. > > Test: hotspot_gc This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9374 From tschatzl at openjdk.org Wed Jul 6 15:20:29 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 15:20:29 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. > > There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. > > Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: - ayang review - cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9395/files - new: https://git.openjdk.org/jdk/pull/9395/files/9e847fc0..5eddae0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9395&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9395&range=01-02 Stats: 26 lines in 5 files changed: 6 ins; 15 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9395/head:pull/9395 PR: https://git.openjdk.org/jdk/pull/9395 From ayang at openjdk.org Wed Jul 6 14:11:48 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Jul 2022 14:11:48 GMT Subject: RFR: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap In-Reply-To: References: Message-ID: On Tue, 5 Jul 2022 09:45:15 GMT, Albert Mingkun Yang wrote: > One line change of negating a condition. > > Test: hotspot_gc Moved to https://github.com/openjdk/jdk19/pull/113 ------------- PR: https://git.openjdk.org/jdk/pull/9374 From tschatzl at openjdk.org Wed Jul 6 12:48:28 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 12:48:28 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v3] In-Reply-To: References: 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 Thomas Schatzl 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: 828755:5 Tighten G1BlockOffsetTable::block_start() code initial version Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9059/files - new: https://git.openjdk.org/jdk/pull/9059/files/ac2740c9..c3866f3f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 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 tschatzl at openjdk.org Wed Jul 6 09:52:02 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 09:52:02 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v15] 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 29 commits: - merge branch 'master' into pull/8956 - Fix verification (another time) - let TAMS be kept until the last useful time - ayang review, cleanup - Remove debug code - Bitmap clear during full gc verification must happen after before-verificaton - 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 - ... and 19 more: https://git.openjdk.org/jdk/compare/83418952...a299ce91 ------------- Changes: https://git.openjdk.org/jdk/pull/8957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8957&range=14 Stats: 1856 lines in 48 files changed: 793 ins; 613 del; 450 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 Wed Jul 6 12:57:12 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 12:57:12 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v4] In-Reply-To: References: Message-ID: <3qhfOYmfcJ6tDQJylEmaNZTwT6LR4Ny_Q9r_1nemi_g=.99095d96-2578-452b-bc93-a56d573d7f2a@github.com> > 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 Thomas Schatzl 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: 828755:5 Tighten G1BlockOffsetTable::block_start() code initial version Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9059/files - new: https://git.openjdk.org/jdk/pull/9059/files/c3866f3f..69b24b40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 iwalulya at openjdk.org Wed Jul 6 16:10:42 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 6 Jul 2022 16:10:42 GMT Subject: RFR: 8137280: Remove eager reclaim of humongous controls In-Reply-To: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> References: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> Message-ID: On Wed, 6 Jul 2022 08:12:32 GMT, Albert Mingkun Yang wrote: > Simple change of removing two experiment flags whose default value is `true`. > > Test: hotspot_gc Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9392 From rriggs at openjdk.org Wed Jul 6 16:49:24 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 6 Jul 2022 16:49:24 GMT Subject: [jdk19] RFR: 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 16:37:54 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/115 From iwalulya at openjdk.org Wed Jul 6 16:19:05 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 6 Jul 2022 16:19:05 GMT Subject: RFR: 8289800: G1: G1CollectionSet::finalize_young_part clears survivor list too early Message-ID: Hi all, Please review this small change to clear survivor regions list only after predictions for survivor_regions_evac_time are done. Test: tier1 //Ivan ------------- Commit messages: - 8289800: G1: G1CollectionSet::finalize_young_part clears survivor list too early Changes: https://git.openjdk.org/jdk/pull/9401/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9401&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289800 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9401.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9401/head:pull/9401 PR: https://git.openjdk.org/jdk/pull/9401 From dcubed at openjdk.org Wed Jul 6 16:52:57 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 6 Jul 2022 16:52:57 GMT Subject: [jdk19] Integrated: 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 16:37:54 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows. This pull request has now been integrated. Changeset: ef3f2ed9 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk19/commit/ef3f2ed9ba920ab8b1e3fb2029e7c0096dd11cc6 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk19/pull/115 From dcubed at openjdk.org Wed Jul 6 16:49:24 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 6 Jul 2022 16:49:24 GMT Subject: [jdk19] RFR: 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows Message-ID: A trivial fix to ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows. ------------- Commit messages: - 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows Changes: https://git.openjdk.org/jdk19/pull/115/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=115&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289841 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/115.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/115/head:pull/115 PR: https://git.openjdk.org/jdk19/pull/115 From ayang at openjdk.org Wed Jul 6 14:16:13 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 6 Jul 2022 14:16:13 GMT Subject: [jdk19] RFR: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap Message-ID: One line change of negating a condition. Test: hotspot_gc ------------- Commit messages: - Update g1ConcurrentMark.cpp Changes: https://git.openjdk.org/jdk19/pull/113/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=113&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289729 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/113.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/113/head:pull/113 PR: https://git.openjdk.org/jdk19/pull/113 From ayang at openjdk.org Thu Jul 7 06:41:31 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Jul 2022 06:41:31 GMT Subject: RFR: 8289800: G1: G1CollectionSet::finalize_young_part clears survivor list too early In-Reply-To: References: Message-ID: <6_5pcwI6kZNJeGL8dPue8X2eLaCeIVW7Kp_WveL5uE4=.9c7224cd-b0c0-430b-add3-c7af87f30cc6@github.com> On Wed, 6 Jul 2022 16:10:27 GMT, Ivan Walulya wrote: > Hi all, > > Please review this small change to clear survivor regions list only after predictions for survivor_regions_evac_time are done. > > Test: tier1 > > //Ivan Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9401 From tschatzl at openjdk.org Thu Jul 7 08:04:28 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 08:04:28 GMT Subject: RFR: 8289800: G1: G1CollectionSet::finalize_young_part clears survivor list too early In-Reply-To: References: Message-ID: <_kF8mhL387V1A0cG874P3GV3PFoB63-YN2BnpdkZMnY=.9dc6baff-3534-463f-9b69-8d8d98414e46@github.com> On Wed, 6 Jul 2022 16:10:27 GMT, Ivan Walulya wrote: > Hi all, > > Please review this small change to clear survivor regions list only after predictions for survivor_regions_evac_time are done. > > Test: tier1 > > //Ivan Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9401 From iwalulya at openjdk.org Thu Jul 7 10:31:41 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 7 Jul 2022 10:31:41 GMT Subject: RFR: 8289740: Add verification testing during all concurrent phases in G1 [v2] In-Reply-To: References: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> Message-ID: On Wed, 6 Jul 2022 09:52:26 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds a test that causes GCs that do lots of verification in all phases of the concurrent cycle to make sure that verification is working after changes. >> >> Testing: test case, gha >> >> Thanks, >> Thomas > > Thomas Schatzl 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. Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.org/jdk/pull/9377 From tschatzl at openjdk.org Wed Jul 6 12:39:18 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 6 Jul 2022 12:39:18 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes [v2] In-Reply-To: References: Message-ID: <7zwfjqLtp0pZCuTY58yE_oCwyqMHVus2uzy_v0kySog=.b5b68f28-3206-44a4-ab05-de1b01ac5481@github.com> > Hi all, > > can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. > > There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. > > Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Make block_start_reaching_into_card() const ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9395/files - new: https://git.openjdk.org/jdk/pull/9395/files/c43b00e8..9e847fc0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9395&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9395&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9395/head:pull/9395 PR: https://git.openjdk.org/jdk/pull/9395 From dcubed at openjdk.org Wed Jul 6 16:49:24 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 6 Jul 2022 16:49:24 GMT Subject: [jdk19] RFR: 8289841: ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 16:44:29 GMT, Roger Riggs wrote: >> A trivial fix to ProblemList vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java with ZGC on windows. > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs - Thanks for the fast review. ------------- PR: https://git.openjdk.org/jdk19/pull/115 From iwalulya at openjdk.org Thu Jul 7 10:39:44 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 7 Jul 2022 10:39:44 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes [v3] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 15:20:29 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. >> >> There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. >> >> Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: > > - ayang review > - cleanup Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.org/jdk/pull/9395 From iwalulya at openjdk.org Thu Jul 7 13:03:29 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 7 Jul 2022 13:03:29 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v15] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 09:52:02 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 with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - merge branch 'master' into pull/8956 > - Fix verification (another time) - let TAMS be kept until the last useful time > - ayang review, cleanup > - Remove debug code > - Bitmap clear during full gc verification must happen after before-verificaton > - 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 > - ... and 19 more: https://git.openjdk.org/jdk/compare/83418952...a299ce91 Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.org/jdk/pull/8957 From ayang at openjdk.org Thu Jul 7 13:56:58 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Jul 2022 13:56:58 GMT Subject: Integrated: 8137280: Remove eager reclaim of humongous controls In-Reply-To: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> References: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> Message-ID: On Wed, 6 Jul 2022 08:12:32 GMT, Albert Mingkun Yang wrote: > Simple change of removing two experiment flags whose default value is `true`. > > Test: hotspot_gc This pull request has now been integrated. Changeset: 013a5eee Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/013a5eeeb9d9a46778f68261ac69ed7235cdc7dd Stats: 35 lines in 6 files changed: 0 ins; 31 del; 4 mod 8137280: Remove eager reclaim of humongous controls Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9392 From ayang at openjdk.org Thu Jul 7 13:56:56 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Jul 2022 13:56:56 GMT Subject: RFR: 8137280: Remove eager reclaim of humongous controls In-Reply-To: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> References: <1mcq8xno0BLht7WkqT-njiBgilnjs1eNe1LQtsVq4QQ=.2e88f58a-e3e3-4f3a-a436-11c73c93eac5@github.com> Message-ID: <3700K3wPkroogILEGH0leG4kFJwMvU90HonLvjwph6I=.82cffd67-86da-4601-82a9-5690ab694a5b@github.com> On Wed, 6 Jul 2022 08:12:32 GMT, Albert Mingkun Yang wrote: > Simple change of removing two experiment flags whose default value is `true`. > > Test: hotspot_gc Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9392 From tschatzl at openjdk.org Thu Jul 7 19:13:21 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 19:13:21 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v5] In-Reply-To: References: 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 Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into pull/9059 - 828755:5 Tighten G1BlockOffsetTable::block_start() code initial version Cleanup - Make block_start_reaching_into_card() const - initial version ------------- Changes: https://git.openjdk.org/jdk/pull/9059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=04 Stats: 36 lines in 4 files changed: 15 ins; 15 del; 6 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 tschatzl at openjdk.org Thu Jul 7 19:17:35 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 19:17:35 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v6] In-Reply-To: References: 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 Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Improve merge, remove unneeded declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9059/files - new: https://git.openjdk.org/jdk/pull/9059/files/4666123e..ecda6c96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=04-05 Stats: 9 lines in 1 file changed: 3 ins; 6 del; 0 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 iwalulya at openjdk.org Thu Jul 7 15:13:42 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 7 Jul 2022 15:13:42 GMT Subject: Integrated: 8289800: G1: G1CollectionSet::finalize_young_part clears survivor list too early In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 16:10:27 GMT, Ivan Walulya wrote: > Hi all, > > Please review this small change to clear survivor regions list only after predictions for survivor_regions_evac_time are done. > > Test: tier1 > > //Ivan This pull request has now been integrated. Changeset: 74ca6ca2 Author: Ivan Walulya URL: https://git.openjdk.org/jdk/commit/74ca6ca25ba3ece0c92bf2c6e4f940996785c9a3 Stats: 6 lines in 1 file changed: 3 ins; 3 del; 0 mod 8289800: G1: G1CollectionSet::finalize_young_part clears survivor list too early Reviewed-by: ayang, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/9401 From tschatzl at openjdk.org Thu Jul 7 18:12:06 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 18:12:06 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes [v3] In-Reply-To: References: Message-ID: <2VITxHRZ8Zgr7jU_pW31Trr2QpqUiWjnjDztAAx7Cec=.1d678159-8fda-4c80-9404-bd172f50c24f@github.com> On Thu, 7 Jul 2022 10:36:01 GMT, Ivan Walulya wrote: >> Thomas Schatzl has updated the pull request incrementally with two additional commits since the last revision: >> >> - ayang review >> - cleanup > > Lgtm! Thanks @walulyai @albertnetymk for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9395 From tschatzl at openjdk.org Thu Jul 7 16:26:07 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 16:26:07 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes [v4] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. > > There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. > > Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade > > 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 five commits: - Merge branch 'master' into 8289538-move-Ablock-size-out-of-bot - ayang review - cleanup - Make block_start_reaching_into_card() const - initial version ------------- Changes: https://git.openjdk.org/jdk/pull/9395/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9395&range=03 Stats: 156 lines in 6 files changed: 75 ins; 67 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9395/head:pull/9395 PR: https://git.openjdk.org/jdk/pull/9395 From iwalulya at openjdk.org Thu Jul 7 15:13:41 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 7 Jul 2022 15:13:41 GMT Subject: RFR: 8289800: G1: G1CollectionSet::finalize_young_part clears survivor list too early In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 16:10:27 GMT, Ivan Walulya wrote: > Hi all, > > Please review this small change to clear survivor regions list only after predictions for survivor_regions_evac_time are done. > > Test: tier1 > > //Ivan Thanks for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9401 From tschatzl at openjdk.org Thu Jul 7 15:47:41 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 15:47:41 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v15] In-Reply-To: References: Message-ID: <8QxliDEextSrIvOSHnAoRQF0sKpp_NhSl6IHivXocDA=.559c6147-567a-4a75-a47a-0ae56fe6a4c1@github.com> On Thu, 7 Jul 2022 15:42:39 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: >> >> - merge branch 'master' into pull/8956 >> - Fix verification (another time) - let TAMS be kept until the last useful time >> - ayang review, cleanup >> - Remove debug code >> - Bitmap clear during full gc verification must happen after before-verificaton >> - 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 >> - ... and 19 more: https://git.openjdk.org/jdk/compare/83418952...a299ce91 > > Marked as reviewed by ayang (Reviewer). Thanks a lot @albertnetymk @walulyai for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/8957 From tschatzl at openjdk.org Thu Jul 7 18:12:07 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 18:12:07 GMT Subject: Integrated: 8289538: Make G1BlockOffsetTablePart unaware of block sizes In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 11:56:47 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. > > There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. > > Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade > > Thanks, > Thomas This pull request has now been integrated. Changeset: f7b18305 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f7b183059a3023f8da73859f1577d08a807749b2 Stats: 145 lines in 6 files changed: 63 ins; 67 del; 15 mod 8289538: Make G1BlockOffsetTablePart unaware of block sizes Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9395 From ayang at openjdk.org Thu Jul 7 20:02:52 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Jul 2022 20:02:52 GMT Subject: RFR: 8289740: Add verification testing during all concurrent phases in G1 [v3] In-Reply-To: References: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> Message-ID: On Thu, 7 Jul 2022 18:10:49 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that adds a test that causes GCs that do lots of verification in all phases of the concurrent cycle to make sure that verification is working after changes. >> >> Testing: test case, gha >> >> Thanks, >> Thomas > > Thomas Schatzl 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 four additional commits since the last revision: > > - Merge branch 'master' into pull/9377 > - Add test > - Add test > - Initial change, adding new concurrent cycle breakpoints Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9377 From tschatzl at openjdk.org Thu Jul 7 19:22:43 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 19:22:43 GMT Subject: [jdk19] RFR: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap In-Reply-To: References: Message-ID: <4LRbjs0wp-_PpFxnB7SVvdkhyudfuNgPFGrJmcqhJs4=.955351f7-8fc6-40e6-9fcd-c0b485a1bd80@github.com> On Wed, 6 Jul 2022 14:07:14 GMT, Albert Mingkun Yang wrote: > One line change of negating a condition. > > Test: hotspot_gc Still good :) ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk19/pull/113 From tschatzl at openjdk.org Thu Jul 7 16:34:40 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 16:34:40 GMT Subject: RFR: 8289538: Make G1BlockOffsetTablePart unaware of block sizes [v5] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that makes `G1BlockOffsetTablePart` unaware of block sizes: as discussed in PR#9059/[JDK-8287555](https://bugs.openjdk.org/browse/JDK-8287555) this is a good idea to make `G1BlockOffsetTablePart` just for "dumb" retrieval of the BOT entries, which makes the code simpler, avoiding some calling back and forth between `HeapRegion` and `G1BlockOffsetTablePart`. > > There is still the wart that `G1BlockOffsetTablePart::verify()` needs `block_size`, but since it's just verification I think this is fine. An alternative suggested by @albertnetymk is to remove that method completely. > > Testing: local compilation, gha, some benchmark checking that card scans/ms does not degrade > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix merge errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9395/files - new: https://git.openjdk.org/jdk/pull/9395/files/d98eb3ae..b8595efc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9395&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9395&range=03-04 Stats: 13 lines in 2 files changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9395/head:pull/9395 PR: https://git.openjdk.org/jdk/pull/9395 From tschatzl at openjdk.org Thu Jul 7 15:50:07 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 15:50:07 GMT Subject: Integrated: 8210708: Use single mark bitmap in G1 In-Reply-To: References: Message-ID: On Tue, 31 May 2022 14:43:14 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 This pull request has now been integrated. Changeset: 95e3190d Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/95e3190d96424885707dd7d07e25e898ad642e5b Stats: 1856 lines in 48 files changed: 793 ins; 613 del; 450 mod 8210708: Use single mark bitmap in G1 Co-authored-by: Stefan Johansson Co-authored-by: Ivan Walulya Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/8957 From tschatzl at openjdk.org Thu Jul 7 18:10:49 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 7 Jul 2022 18:10:49 GMT Subject: RFR: 8289740: Add verification testing during all concurrent phases in G1 [v3] In-Reply-To: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> References: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> Message-ID: > Hi all, > > can I have reviews for this change that adds a test that causes GCs that do lots of verification in all phases of the concurrent cycle to make sure that verification is working after changes. > > Testing: test case, gha > > Thanks, > Thomas Thomas Schatzl 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 four additional commits since the last revision: - Merge branch 'master' into pull/9377 - Add test - Add test - Initial change, adding new concurrent cycle breakpoints ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9377/files - new: https://git.openjdk.org/jdk/pull/9377/files/eed786bd..1b82991a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9377&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9377&range=01-02 Stats: 7577 lines in 195 files changed: 4096 ins; 1963 del; 1518 mod Patch: https://git.openjdk.org/jdk/pull/9377.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9377/head:pull/9377 PR: https://git.openjdk.org/jdk/pull/9377 From ayang at openjdk.org Thu Jul 7 15:44:49 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 7 Jul 2022 15:44:49 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v15] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 09:52:02 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 with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - merge branch 'master' into pull/8956 > - Fix verification (another time) - let TAMS be kept until the last useful time > - ayang review, cleanup > - Remove debug code > - Bitmap clear during full gc verification must happen after before-verificaton > - 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 > - ... and 19 more: https://git.openjdk.org/jdk/compare/83418952...a299ce91 Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/8957 From tschatzl at openjdk.org Fri Jul 8 07:19:45 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 07:19:45 GMT Subject: Integrated: 8289740: Add verification testing during all concurrent phases in G1 In-Reply-To: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> References: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> Message-ID: <3JwX0rTR7tEqkVVK8-j_LOmOM2TalPQXczf3NA8TxOQ=.f4009aaf-bfe5-4a57-a8ac-887d4db44b64@github.com> On Tue, 5 Jul 2022 14:04:12 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that adds a test that causes GCs that do lots of verification in all phases of the concurrent cycle to make sure that verification is working after changes. > > Testing: test case, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 1b8f466d Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/1b8f466dbad08c0fccb8f0069ff5141cf8d6bf2c Stats: 100 lines in 1 file changed: 100 ins; 0 del; 0 mod 8289740: Add verification testing during all concurrent phases in G1 Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/9377 From tschatzl at openjdk.org Fri Jul 8 08:25:27 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 08:25:27 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v7] In-Reply-To: References: 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 Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Refactoring ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9059/files - new: https://git.openjdk.org/jdk/pull/9059/files/ecda6c96..c848f00c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=05-06 Stats: 48 lines in 2 files changed: 17 ins; 18 del; 13 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 kbarrett at openjdk.org Fri Jul 8 09:17:00 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Jul 2022 09:17:00 GMT Subject: RFR: 8289997: gc/g1/TestVerificationInConcurrentCycle.java fails due to use of debug-only option In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 08:33:02 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes failures in product VMs due to use of a debug-only verification option? > > The change has the VM ignore that option as needed. > > Thanks, > Thomas > > Testing: local testing Changes requested by kbarrett (Reviewer). test/hotspot/jtreg/gc/g1/TestVerificationInConcurrentCycle.java line 39: > 37: * -XX:+G1VerifyRSetsDuringFullGC -XX:+G1VerifyHeapRegionCodeRoots > 38: * -XX:+VerifyRememberedSets -XX:+VerifyObjectStartArray > 39: * -XX:+IgnoreUnrecognizedVMOptions -XX:+G1VerifyBitmaps Rather than using `-XX:+IgnoreUnrecognizedVMOptions`, a "safer" solution would be to have two `@test` blocks, one that `@requires` a debug build and has that option, and one which `@requires` a product build and doesn't have the option. (This would be less important if the IgnoreXXX option only affected options that follow it, but it's "special" and affects all the options, regardless of where it appears.) ------------- PR: https://git.openjdk.org/jdk/pull/9424 From tschatzl at openjdk.org Fri Jul 8 07:16:43 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 07:16:43 GMT Subject: RFR: 8289740: Add verification testing during all concurrent phases in G1 [v2] In-Reply-To: References: <12PKpDI4f4laFLJ5yIJPLTJePNjDu0Nc20_coiQjhf8=.95e64f52-1253-4fe7-a976-a7058d96af1b@github.com> Message-ID: On Thu, 7 Jul 2022 10:28:30 GMT, Ivan Walulya wrote: >> Thomas Schatzl 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. > > Lgtm! Thanks @walulyai @albertnetymk for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9377 From lkorinth at openjdk.org Fri Jul 8 08:50:54 2022 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 8 Jul 2022 08:50:54 GMT Subject: RFR: 8289997: gc/g1/TestVerificationInConcurrentCycle.java fails due to use of debug-only option In-Reply-To: References: Message-ID: <09UjlYwaNQxPzga8r_nl-N-k5JCUPr7i1DOPh_vy_t0=.0379ce50-955e-4588-bd0b-7852390d6fc9@github.com> On Fri, 8 Jul 2022 08:33:02 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes failures in product VMs due to use of a debug-only verification option? > > The change has the VM ignore that option as needed. > > Thanks, > Thomas > > Testing: local testing Marked as reviewed by lkorinth (Reviewer). Looks good and trivial. Integrate it! ------------- PR: https://git.openjdk.org/jdk/pull/9424 From tschatzl at openjdk.org Fri Jul 8 08:50:56 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 08:50:56 GMT Subject: RFR: 8289997: gc/g1/TestVerificationInConcurrentCycle.java fails due to use of debug-only option In-Reply-To: <09UjlYwaNQxPzga8r_nl-N-k5JCUPr7i1DOPh_vy_t0=.0379ce50-955e-4588-bd0b-7852390d6fc9@github.com> References: <09UjlYwaNQxPzga8r_nl-N-k5JCUPr7i1DOPh_vy_t0=.0379ce50-955e-4588-bd0b-7852390d6fc9@github.com> Message-ID: On Fri, 8 Jul 2022 08:45:47 GMT, Leo Korinth wrote: >> Hi all, >> >> can I have reviews for this change that fixes failures in product VMs due to use of a debug-only verification option? >> >> The change has the VM ignore that option as needed. >> >> Thanks, >> Thomas >> >> Testing: local testing > > Looks good and trivial. Integrate it! Thanks @lkorinth for your review. ------------- PR: https://git.openjdk.org/jdk/pull/9424 From tschatzl at openjdk.org Fri Jul 8 08:43:14 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 08:43:14 GMT Subject: RFR: 8289997: gc/g1/TestVerificationInConcurrentCycle.java fails due to use of debug-only option Message-ID: Hi all, can I have reviews for this change that fixes failures in product VMs due to use of a debug-only verification option? The change has the VM ignore that option as needed. Thanks, Thomas Testing: local testing ------------- Commit messages: - Fix test Changes: https://git.openjdk.org/jdk/pull/9424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289997 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9424.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9424/head:pull/9424 PR: https://git.openjdk.org/jdk/pull/9424 From tschatzl at openjdk.org Fri Jul 8 15:18:23 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 15:18:23 GMT Subject: RFR: 8290019: Refactor HeapRegion::oops_on_memregion_iterate() Message-ID: Hi all, please review this potential refactoring for `HeapRegion::oops_on_memregion_iterate()`; it's a bit subjective imo if the code is better now, so please feel free to say so and I'll retract. Testing: tier1-3 Thanks, Thomas ------------- Commit messages: - Initail version Changes: https://git.openjdk.org/jdk/pull/9430/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290019 Stats: 45 lines in 2 files changed: 18 ins; 18 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9430.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9430/head:pull/9430 PR: https://git.openjdk.org/jdk/pull/9430 From tschatzl at openjdk.org Fri Jul 8 15:15:54 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 15:15:54 GMT Subject: RFR: 8290017: Directly call HeapRegion::block_start in G1CMObjArrayProcessor::process_slice Message-ID: <6Y2ZLO122JW6XuxKC6NoXhwvAU5KKt33uXSY4mCuiwc=.1a9c66d4-d66b-4d23-b0a1-28d1af86a358@github.com> Hi all, please review this small change to have `G1CMObjArrayProcessor::process_slice` call `HeapRegion::block` directly instead of indirectly via `G1CollectedHeap`. This saves a check and an indirection (but generally isn't perf sensitive anyway, but still). Testing: tier1-3 Thanks, Thomas ------------- Commit messages: - Initial version Changes: https://git.openjdk.org/jdk/pull/9428/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9428&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290017 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9428.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9428/head:pull/9428 PR: https://git.openjdk.org/jdk/pull/9428 From tschatzl at openjdk.org Fri Jul 8 08:25:27 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 08:25:27 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v6] In-Reply-To: References: Message-ID: On Thu, 7 Jul 2022 19:17:35 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 > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Improve merge, remove unneeded declarations Did some refactoring to remove some duplicate `block_start` call. Passes tier1-3. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Fri Jul 8 15:18:47 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 15:18:47 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v7] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 08:25:27 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 > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring I moved some fairly unrelated refactoring/cleanup to separate PRs without updating this one yet (https://github.com/openjdk/jdk/pull/9430, https://github.com/openjdk/jdk/pull/9429 and https://github.com/openjdk/jdk/pull/9428); let's wait until they are pushed and merged. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Fri Jul 8 15:16:08 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 15:16:08 GMT Subject: RFR: 8290018: Remove dead declarations in G1BlockOffsetTablePart Message-ID: Hi all, please review this removal of dead code in `G1BlockOffsetTablePart`. Testing: compilation Thanks, Thomas ------------- Commit messages: - Initial version Changes: https://git.openjdk.org/jdk/pull/9429/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9429&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290018 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9429.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9429/head:pull/9429 PR: https://git.openjdk.org/jdk/pull/9429 From tschatzl at openjdk.org Fri Jul 8 08:52:56 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Jul 2022 08:52:56 GMT Subject: Integrated: 8289997: gc/g1/TestVerificationInConcurrentCycle.java fails due to use of debug-only option In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 08:33:02 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that fixes failures in product VMs due to use of a debug-only verification option? > > The change has the VM ignore that option as needed. > > Thanks, > Thomas > > Testing: local testing This pull request has now been integrated. Changeset: f1967cfa Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f1967cfaabb30dba82eca0ab028f43020fe50c2b Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8289997: gc/g1/TestVerificationInConcurrentCycle.java fails due to use of debug-only option Reviewed-by: lkorinth ------------- PR: https://git.openjdk.org/jdk/pull/9424 From ayang at openjdk.org Fri Jul 8 21:31:43 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 8 Jul 2022 21:31:43 GMT Subject: RFR: 8290017: Directly call HeapRegion::block_start in G1CMObjArrayProcessor::process_slice In-Reply-To: <6Y2ZLO122JW6XuxKC6NoXhwvAU5KKt33uXSY4mCuiwc=.1a9c66d4-d66b-4d23-b0a1-28d1af86a358@github.com> References: <6Y2ZLO122JW6XuxKC6NoXhwvAU5KKt33uXSY4mCuiwc=.1a9c66d4-d66b-4d23-b0a1-28d1af86a358@github.com> Message-ID: On Fri, 8 Jul 2022 15:07:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change to have `G1CMObjArrayProcessor::process_slice` call `HeapRegion::block` directly instead of indirectly via `G1CollectedHeap`. This saves a check and an indirection (but generally isn't perf sensitive anyway, but still). > > Testing: tier1-3 > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9428 From ayang at openjdk.org Fri Jul 8 21:33:51 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 8 Jul 2022 21:33:51 GMT Subject: RFR: 8290018: Remove dead declarations in G1BlockOffsetTablePart In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 15:08:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of dead code in `G1BlockOffsetTablePart`. > > Testing: compilation > > Thanks, > Thomas Good and trivial. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9429 From ysr at openjdk.org Sat Jul 9 00:31:47 2022 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Sat, 9 Jul 2022 00:31:47 GMT Subject: RFR: 8210708: Use single mark bitmap in G1 [v15] In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 09:52:02 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 with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - merge branch 'master' into pull/8956 > - Fix verification (another time) - let TAMS be kept until the last useful time > - ayang review, cleanup > - Remove debug code > - Bitmap clear during full gc verification must happen after before-verificaton > - 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 > - ... and 19 more: https://git.openjdk.org/jdk/compare/83418952...a299ce91 Do you have any before-after performance numbers for the change? (If so, would make sense to add to the JBS ticket.) ------------- PR: https://git.openjdk.org/jdk/pull/8957 From ayang at openjdk.org Sun Jul 10 13:43:32 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Sun, 10 Jul 2022 13:43:32 GMT Subject: RFR: 8290019: Refactor HeapRegion::oops_on_memregion_iterate() In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 15:09:32 GMT, Thomas Schatzl wrote: > Hi all, > > please review this potential refactoring for `HeapRegion::oops_on_memregion_iterate()`; it's a bit subjective imo if the code is better now, so please feel free to say so and I'll retract. > > Testing: tier1-3 > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). src/hotspot/share/gc/g1/heapRegion.inline.hpp line 407: > 405: inline HeapWord* HeapRegion::oops_on_memregion_iterate_in_unparsable(MemRegion mr, HeapWord* block_start, Closure* cl) { > 406: HeapWord* const start = mr.start(); > 407: // Only scan until parsable_bottom. This comment can be dropped now. ------------- PR: https://git.openjdk.org/jdk/pull/9430 From iwalulya at openjdk.org Mon Jul 11 07:05:51 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 11 Jul 2022 07:05:51 GMT Subject: [jdk19] RFR: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap In-Reply-To: References: Message-ID: <59QBn1UuW2rItCZYBKMHTXHH0jxRftyou5mmkjnMfMw=.9158cfff-0d43-4515-92e8-56c1b22ac08f@github.com> On Wed, 6 Jul 2022 14:07:14 GMT, Albert Mingkun Yang wrote: > One line change of negating a condition. > > Test: hotspot_gc Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk19/pull/113 From iwalulya at openjdk.org Mon Jul 11 07:07:40 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 11 Jul 2022 07:07:40 GMT Subject: RFR: 8290017: Directly call HeapRegion::block_start in G1CMObjArrayProcessor::process_slice In-Reply-To: <6Y2ZLO122JW6XuxKC6NoXhwvAU5KKt33uXSY4mCuiwc=.1a9c66d4-d66b-4d23-b0a1-28d1af86a358@github.com> References: <6Y2ZLO122JW6XuxKC6NoXhwvAU5KKt33uXSY4mCuiwc=.1a9c66d4-d66b-4d23-b0a1-28d1af86a358@github.com> Message-ID: On Fri, 8 Jul 2022 15:07:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change to have `G1CMObjArrayProcessor::process_slice` call `HeapRegion::block` directly instead of indirectly via `G1CollectedHeap`. This saves a check and an indirection (but generally isn't perf sensitive anyway, but still). > > Testing: tier1-3 > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9428 From tschatzl at openjdk.org Mon Jul 11 07:36:41 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Jul 2022 07:36:41 GMT Subject: RFR: 8290017: Directly call HeapRegion::block_start in G1CMObjArrayProcessor::process_slice In-Reply-To: References: <6Y2ZLO122JW6XuxKC6NoXhwvAU5KKt33uXSY4mCuiwc=.1a9c66d4-d66b-4d23-b0a1-28d1af86a358@github.com> Message-ID: On Fri, 8 Jul 2022 21:28:14 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this small change to have `G1CMObjArrayProcessor::process_slice` call `HeapRegion::block` directly instead of indirectly via `G1CollectedHeap`. This saves a check and an indirection (but generally isn't perf sensitive anyway, but still). >> >> Testing: tier1-3 >> >> Thanks, >> Thomas > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @walulyai for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/9428 From tschatzl at openjdk.org Mon Jul 11 07:40:30 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Jul 2022 07:40:30 GMT Subject: Integrated: 8290017: Directly call HeapRegion::block_start in G1CMObjArrayProcessor::process_slice In-Reply-To: <6Y2ZLO122JW6XuxKC6NoXhwvAU5KKt33uXSY4mCuiwc=.1a9c66d4-d66b-4d23-b0a1-28d1af86a358@github.com> References: <6Y2ZLO122JW6XuxKC6NoXhwvAU5KKt33uXSY4mCuiwc=.1a9c66d4-d66b-4d23-b0a1-28d1af86a358@github.com> Message-ID: On Fri, 8 Jul 2022 15:07:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this small change to have `G1CMObjArrayProcessor::process_slice` call `HeapRegion::block` directly instead of indirectly via `G1CollectedHeap`. This saves a check and an indirection (but generally isn't perf sensitive anyway, but still). > > Testing: tier1-3 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 4ab77ac6 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/4ab77ac60df78eedb16ebe142a51f703165e808d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8290017: Directly call HeapRegion::block_start in G1CMObjArrayProcessor::process_slice Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9428 From tschatzl at openjdk.org Mon Jul 11 07:48:00 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Jul 2022 07:48:00 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests Message-ID: Hi all, can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) * adding additional `@requires` * removing it in tests where it is not actually required Testing: gha, running tests Thanks, Thomas ------------- Commit messages: - Merge branch 'master' into 8290023-remove-use-of-ignoreunrecognized - fix test - Merge fixes - Initial batch Changes: https://git.openjdk.org/jdk/pull/9443/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290023 Stats: 258 lines in 13 files changed: 189 ins; 26 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/9443.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9443/head:pull/9443 PR: https://git.openjdk.org/jdk/pull/9443 From iwalulya at openjdk.org Mon Jul 11 07:53:20 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 11 Jul 2022 07:53:20 GMT Subject: RFR: 8290019: Refactor HeapRegion::oops_on_memregion_iterate() In-Reply-To: References: Message-ID: <_LjNjDIGehdJzRI3HcqsUWaLau8GvoLLT46XG-432vg=.0075adef-d8cb-44c5-bf3a-22c777eb3831@github.com> On Fri, 8 Jul 2022 15:09:32 GMT, Thomas Schatzl wrote: > Hi all, > > please review this potential refactoring for `HeapRegion::oops_on_memregion_iterate()`; it's a bit subjective imo if the code is better now, so please feel free to say so and I'll retract. > > Testing: tier1-3 > > Thanks, > Thomas Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9430 From tschatzl at openjdk.org Mon Jul 11 07:59:47 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Jul 2022 07:59:47 GMT Subject: RFR: 8290018: Remove dead declarations in G1BlockOffsetTablePart In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 21:29:35 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this removal of dead code in `G1BlockOffsetTablePart`. >> >> Testing: compilation >> >> Thanks, >> Thomas > > Good and trivial. Thanks @albertnetymk for your review ------------- PR: https://git.openjdk.org/jdk/pull/9429 From tschatzl at openjdk.org Mon Jul 11 08:01:14 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Jul 2022 08:01:14 GMT Subject: RFR: 8290019: Refactor HeapRegion::oops_on_memregion_iterate() In-Reply-To: <_LjNjDIGehdJzRI3HcqsUWaLau8GvoLLT46XG-432vg=.0075adef-d8cb-44c5-bf3a-22c777eb3831@github.com> References: <_LjNjDIGehdJzRI3HcqsUWaLau8GvoLLT46XG-432vg=.0075adef-d8cb-44c5-bf3a-22c777eb3831@github.com> Message-ID: On Mon, 11 Jul 2022 07:50:25 GMT, Ivan Walulya wrote: >> Hi all, >> >> please review this potential refactoring for `HeapRegion::oops_on_memregion_iterate()`; it's a bit subjective imo if the code is better now, so please feel free to say so and I'll retract. >> >> Testing: tier1-3 >> >> Thanks, >> Thomas > > Marked as reviewed by iwalulya (Reviewer). Thanks @walulyai @albertnetymk for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/9430 From tschatzl at openjdk.org Mon Jul 11 08:01:15 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Jul 2022 08:01:15 GMT Subject: Integrated: 8290019: Refactor HeapRegion::oops_on_memregion_iterate() In-Reply-To: References: Message-ID: <0W1g6rpl8anoqjk3VaRwdmhaZgvTBKrgfS8EFLaCgQM=.5fa6bbfb-ca68-4d09-8699-87af730c5e7b@github.com> On Fri, 8 Jul 2022 15:09:32 GMT, Thomas Schatzl wrote: > Hi all, > > please review this potential refactoring for `HeapRegion::oops_on_memregion_iterate()`; it's a bit subjective imo if the code is better now, so please feel free to say so and I'll retract. > > Testing: tier1-3 > > Thanks, > Thomas This pull request has now been integrated. Changeset: e2598207 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/e25982071d6d1586d723bcc0d261be619a187f00 Stats: 45 lines in 2 files changed: 18 ins; 18 del; 9 mod 8290019: Refactor HeapRegion::oops_on_memregion_iterate() Reviewed-by: ayang, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9430 From ayang at openjdk.org Mon Jul 11 08:02:17 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Jul 2022 08:02:17 GMT Subject: [jdk19] RFR: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 14:07:14 GMT, Albert Mingkun Yang wrote: > One line change of negating a condition. > > Test: hotspot_gc Thanks for the review. ------------- PR: https://git.openjdk.org/jdk19/pull/113 From ayang at openjdk.org Mon Jul 11 08:02:17 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Jul 2022 08:02:17 GMT Subject: [jdk19] Integrated: 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 14:07:14 GMT, Albert Mingkun Yang wrote: > One line change of negating a condition. > > Test: hotspot_gc This pull request has now been integrated. Changeset: b542bcba Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk19/commit/b542bcba57a1ac79b9b7182dbf984b447754fafc Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8289729: G1: Incorrect verification logic in G1ConcurrentMark::clear_next_bitmap Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk19/pull/113 From tschatzl at openjdk.org Mon Jul 11 08:02:41 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Jul 2022 08:02:41 GMT Subject: Integrated: 8290018: Remove dead declarations in G1BlockOffsetTablePart In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 15:08:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review this removal of dead code in `G1BlockOffsetTablePart`. > > Testing: compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: 0225eb43 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/0225eb434cb8792d362923bf2c2e3607be4efcb9 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod 8290018: Remove dead declarations in G1BlockOffsetTablePart Reviewed-by: ayang ------------- PR: https://git.openjdk.org/jdk/pull/9429 From ayang at openjdk.org Mon Jul 11 10:08:47 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Mon, 11 Jul 2022 10:08:47 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas Marked as reviewed by ayang (Reviewer). test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java line 153: > 151: * java.management/sun.management > 152: * jdk.internal.jvmstat/sun.jvmstat.monitor > 153: * @run main/othervm -XX:+UsePerfData -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC gc.metaspace.TestMetaspacePerfCounters It's unclear to me why `-XX:+UnlockExperimentalVMOptions` is needed in this file. test/hotspot/jtreg/gc/metaspace/TestPerfCountersAndMemoryPools.java line 58: > 56: * jdk.internal.jvmstat/sun.jvmstat.monitor > 57: * @run main/othervm -Xlog:class+load,class+unload=trace -XX:+UseSerialGC -XX:+UsePerfData -Xint gc.metaspace.TestPerfCountersAndMemoryPools > 58: * @run main/othervm -Xlog:class+load,class+unload=trace -XX:+UseSerialGC -XX:+UsePerfData -Xint gc.metaspace.TestPerfCountersAndMemoryPools These two lines are identical; is this intended? ------------- PR: https://git.openjdk.org/jdk/pull/9443 From lkorinth at openjdk.org Mon Jul 11 12:55:38 2022 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 11 Jul 2022 12:55:38 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas I have looked through the change, and it looks mostly good to me. TestEagerReclaimHumongousRegionsClearMarkBits after the change only runs in debug builds, is that made on purpose? ------------- PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Mon Jul 11 13:08:43 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 11 Jul 2022 13:08:43 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests In-Reply-To: References: Message-ID: <5dUXqi03xrDnZkyF4IKnhyAwSIJupNZkdoEBiwGqSYk=.3804b8b2-5cc0-452c-a495-5803fff4e2a5@github.com> On Mon, 11 Jul 2022 12:52:17 GMT, Leo Korinth wrote: > I have looked through the change, and it looks mostly good to me. TestEagerReclaimHumongousRegionsClearMarkBits after the change only runs in debug builds, is that made on purpose? TestEagerReclaimHumongousRegionsClearMarkBits is not going to crash due to bitmap verification error in product mode because that verification is debug mode only. At most it could crash due to other reasons, but I do not think it is worth running the test for random suspicion that something might be wrong that other tests would highly likely also pick up. ------------- PR: https://git.openjdk.org/jdk/pull/9443 From zgu at openjdk.org Mon Jul 11 14:23:25 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 11 Jul 2022 14:23:25 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v5] In-Reply-To: References: Message-ID: <-gZIyL_HcxoALruUKy0_hg2nA-IrcjZA7SRsBtFOlfE=.46003d5a-3899-48dd-b5c7-b3df04389b4d@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: Aleksey's comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9023/files - new: https://git.openjdk.org/jdk/pull/9023/files/f076e810..44f50839 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=03-04 Stats: 7 lines in 1 file changed: 3 ins; 3 del; 1 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 duke at openjdk.org Mon Jul 11 16:09:42 2022 From: duke at openjdk.org (duke) Date: Mon, 11 Jul 2022 16:09:42 GMT Subject: Withdrawn: 8286739: Refactor FreeListConfig In-Reply-To: References: Message-ID: On Fri, 13 May 2022 14:45:25 GMT, Albert Mingkun Yang wrote: > This PR consists of two commits: > > 1 is about making `FreeListConfig` an "interface" of `allocate/deallocate`. > 2 is about renaming `FreeListConfig -> MemAllocator`. > > Test: hotspot_gc This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8704 From lkorinth at openjdk.org Mon Jul 11 16:13:40 2022 From: lkorinth at openjdk.org (Leo Korinth) Date: Mon, 11 Jul 2022 16:13:40 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas Looks good, and thanks for removing `-XX:+IgnoreUnrecognizedVMOptions` from our test cases. ------------- Marked as reviewed by lkorinth (Reviewer). PR: https://git.openjdk.org/jdk/pull/9443 From kbarrett at openjdk.org Mon Jul 11 18:19:51 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 11 Jul 2022 18:19:51 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests In-Reply-To: References: Message-ID: <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com> On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas Changes requested by kbarrett (Reviewer). test/hotspot/jtreg/gc/epsilon/TestAlignment.java line 40: > 38: * gc.epsilon.TestAlignment > 39: */ > 40: /** Insert blank line. test/hotspot/jtreg/gc/epsilon/TestAlignment.java line 41: > 39: */ > 40: /** > 41: * @test TestMaxTLAB Wrong test name. test/hotspot/jtreg/gc/g1/TestLargePageUseForAuxMemory.java line 121: > 119: "-XX:" + (largePageEnabled ? "+" : "-") + "UseLargePages" }); > 120: if (Platform.is64bit()) { > 121: vmOpts.add("-XX:ObjectAlignmentInBytes=8"); As 8 is the default value, I'm not sure why this option is being added. test/hotspot/jtreg/gc/g1/TestVerificationInConcurrentCycle.java line 47: > 45: * @test TestVerificationInConcurrentCycle > 46: * @requires vm.gc.G1 > 47: * @requires !vm.debug Maybe add a comment that this leaves out debug-only G1VerifyBitmaps. test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java line 100: > 98: */ > 99: > 100: /* @test TestMetaspacePerfCountersSerial I think that throughout this test could use the new-ish `@test id=XXX` feature, so this could be `@test id=Serial32` and the earlier one for 64 bit could be `@test id=Serial64`. This would give more information in failure report summaries. test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java line 155: > 153: * @run main/othervm -XX:+UsePerfData -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC gc.metaspace.TestMetaspacePerfCounters > 154: */ > 155: Is this file missing entries for Epsilon? That could be a followup RFE if appropriate. test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java line 40: > 38: * of barrier flags > 39: * @requires vm.gc.Shenandoah > 40: * @requires !vm.debug Seems like it might be a bit simpler to have one `@test` with the first two `@run` lines and no `@requires` on `vm.debug`, and a second (debug-only) `@test` with the third `@run`. ------------- PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Tue Jul 12 08:07:45 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Jul 2022 08:07:45 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests In-Reply-To: <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com> References: <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com> Message-ID: <4v4M--0sO6QFYpsUwGienS6oPXfdkHT3HtmTKhn1m1E=.8b3d17b8-d9db-4a0a-aba7-ae40b121f1dd@github.com> On Mon, 11 Jul 2022 17:52:08 GMT, Kim Barrett wrote: >> Hi all, >> >> can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? >> >> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by >> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) >> * adding additional `@requires` >> * removing it in tests where it is not actually required >> >> Testing: gha, running tests >> >> Thanks, >> Thomas > > test/hotspot/jtreg/gc/g1/TestLargePageUseForAuxMemory.java line 121: > >> 119: "-XX:" + (largePageEnabled ? "+" : "-") + "UseLargePages" }); >> 120: if (Platform.is64bit()) { >> 121: vmOpts.add("-XX:ObjectAlignmentInBytes=8"); > > As 8 is the default value, I'm not sure why this option is being added. Idk, I removed it. ------------- PR: https://git.openjdk.org/jdk/pull/9443 From ayang at openjdk.org Tue Jul 12 08:25:09 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 12 Jul 2022 08:25:09 GMT Subject: RFR: 8290080: G1: Remove unnecessary is-obj-dead check in HeapRegion::do_oops_on_memregion_in_humongous Message-ID: Simple change of removing an `if` check. Test: tier1-6 ------------- Commit messages: - g1-remove-is-dead-check Changes: https://git.openjdk.org/jdk/pull/9462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290080 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9462.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9462/head:pull/9462 PR: https://git.openjdk.org/jdk/pull/9462 From tschatzl at openjdk.org Tue Jul 12 08:36:42 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Jul 2022 08:36:42 GMT Subject: RFR: 8290080: G1: Remove unnecessary is-obj-dead check in HeapRegion::do_oops_on_memregion_in_humongous In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 08:17:09 GMT, Albert Mingkun Yang wrote: > Simple change of removing an `if` check. > > Test: tier1-6 lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9462 From tschatzl at openjdk.org Tue Jul 12 08:36:59 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Jul 2022 08:36:59 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: ayang, kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9443/files - new: https://git.openjdk.org/jdk/pull/9443/files/9848697e..279b99d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=00-01 Stats: 36 lines in 6 files changed: 2 ins; 11 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/9443.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9443/head:pull/9443 PR: https://git.openjdk.org/jdk/pull/9443 From lkorinth at openjdk.org Tue Jul 12 10:42:43 2022 From: lkorinth at openjdk.org (Leo Korinth) Date: Tue, 12 Jul 2022 10:42:43 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v2] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 08:36:59 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? >> >> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by >> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) >> * adding additional `@requires` >> * removing it in tests where it is not actually required >> >> Testing: gha, running tests >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > ayang, kbarrett review Looks good. ------------- Marked as reviewed by lkorinth (Reviewer). PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Tue Jul 12 16:52:22 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Jul 2022 16:52:22 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v8] In-Reply-To: References: 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 Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Remove change - Merge branch 'master' into pull/9059 - Merge branch 'master' into pull/9059 - Refactoring - Improve merge, remove unneeded declarations - Merge branch 'master' into pull/9059 - 828755:5 Tighten G1BlockOffsetTable::block_start() code initial version Cleanup - Make block_start_reaching_into_card() const - initial version ------------- Changes: https://git.openjdk.org/jdk/pull/9059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9059&range=07 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 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 tschatzl at openjdk.org Tue Jul 12 16:52:22 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Jul 2022 16:52:22 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v7] In-Reply-To: References: Message-ID: On Fri, 8 Jul 2022 08:25:27 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 > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring Cleaned out cleanups, open for comments again. ------------- PR: https://git.openjdk.org/jdk/pull/9059 From tschatzl at openjdk.org Tue Jul 12 14:46:51 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Jul 2022 14:46:51 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v3] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: add Epsilongc tests for TestMetaspacePerfCounters.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9443/files - new: https://git.openjdk.org/jdk/pull/9443/files/279b99d9..1b530193 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=01-02 Stats: 31 lines in 1 file changed: 31 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9443.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9443/head:pull/9443 PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Tue Jul 12 14:46:52 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Jul 2022 14:46:52 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v3] In-Reply-To: <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com> References: <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com> Message-ID: <7pWz4FpEoOYH_oiqq77R7LuMDSiL-rPh0efNMicRjsI=.3bcb61bb-bee9-48ad-b460-2cdc56ee851c@github.com> On Mon, 11 Jul 2022 18:07:14 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> add Epsilongc tests for TestMetaspacePerfCounters.java > > test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java line 155: > >> 153: * @run main/othervm -XX:+UsePerfData -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC gc.metaspace.TestMetaspacePerfCounters >> 154: */ >> 155: > > Is this file missing entries for Epsilon? That could be a followup RFE if appropriate. Added. Passes. ------------- PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Tue Jul 12 14:56:15 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 12 Jul 2022 14:56:15 GMT Subject: RFR: 8290177: Improve documentation in G1MMUTracker Message-ID: Hi all, please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. Testing: gha Thanks, Thomas ------------- Commit messages: - initial version Changes: https://git.openjdk.org/jdk/pull/9471/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290177 Stats: 32 lines in 2 files changed: 16 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/9471.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9471/head:pull/9471 PR: https://git.openjdk.org/jdk/pull/9471 From ayang at openjdk.org Wed Jul 13 07:41:16 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 13 Jul 2022 07:41:16 GMT Subject: RFR: 8290221: G1: Merge multiple calls of get_next_marked_addr in HeapRegion::oops_on_memregion_iterate_in_unparsable Message-ID: Simple change of merging two calls of `get_next_marked_addr` into one. Test: hotspot_gc ------------- Commit messages: - g1-next-marked-addr Changes: https://git.openjdk.org/jdk/pull/9477/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9477&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290221 Stats: 21 lines in 1 file changed: 6 ins; 12 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9477.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9477/head:pull/9477 PR: https://git.openjdk.org/jdk/pull/9477 From tschatzl at openjdk.org Wed Jul 13 08:11:43 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 08:11:43 GMT Subject: RFR: 8290221: G1: Merge multiple calls of get_next_marked_addr in HeapRegion::oops_on_memregion_iterate_in_unparsable In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 07:20:36 GMT, Albert Mingkun Yang wrote: > Simple change of merging two calls of `get_next_marked_addr` into one. > > Test: hotspot_gc Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9477 From kbarrett at openjdk.org Wed Jul 13 08:35:43 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 13 Jul 2022 08:35:43 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v3] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 14:46:51 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? >> >> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by >> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) >> * adding additional `@requires` >> * removing it in tests where it is not actually required >> >> Testing: gha, running tests >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > add Epsilongc tests for TestMetaspacePerfCounters.java Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9443 From iwalulya at openjdk.org Wed Jul 13 09:12:07 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 13 Jul 2022 09:12:07 GMT Subject: RFR: 8290177: Improve documentation in G1MMUTracker In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 14:48:09 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. > > Testing: gha > > Thanks, > Thomas Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.org/jdk/pull/9471 From tschatzl at openjdk.org Wed Jul 13 09:38:38 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 09:38:38 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v4] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Fix x86 metaspaceperfcounters test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9443/files - new: https://git.openjdk.org/jdk/pull/9443/files/1b530193..4c5d78f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9443.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9443/head:pull/9443 PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Wed Jul 13 10:31:52 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 10:31:52 GMT Subject: RFR: 8290223: Initialize G1CardClosure in card scanning once Message-ID: <8vlwRbOYyimea17bljpOVA5DkUk-GPLy_e9ANBQGoxY=.6216c8a6-be54-49ec-93f2-fc45969d591f@github.com> Hi all, please review this minor change to avoid repeatedly initializing `G1CardClosure` in card scanning. Testing: gha, local compilation Thanks, Thomas ------------- Commit messages: - initial version Changes: https://git.openjdk.org/jdk/pull/9478/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9478&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290223 Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9478.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9478/head:pull/9478 PR: https://git.openjdk.org/jdk/pull/9478 From tschatzl at openjdk.org Wed Jul 13 13:51:15 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 13:51:15 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v5] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Epsilon needs UnlockExperimentalOptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9443/files - new: https://git.openjdk.org/jdk/pull/9443/files/4c5d78f6..f94c5b5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9443.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9443/head:pull/9443 PR: https://git.openjdk.org/jdk/pull/9443 From iwalulya at openjdk.org Wed Jul 13 13:56:01 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 13 Jul 2022 13:56:01 GMT Subject: RFR: 8290221: G1: Merge multiple calls of get_next_marked_addr in HeapRegion::oops_on_memregion_iterate_in_unparsable In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 07:20:36 GMT, Albert Mingkun Yang wrote: > Simple change of merging two calls of `get_next_marked_addr` into one. > > Test: hotspot_gc Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9477 From iwalulya at openjdk.org Wed Jul 13 13:57:08 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 13 Jul 2022 13:57:08 GMT Subject: RFR: 8290080: G1: Remove unnecessary is-obj-dead check in HeapRegion::do_oops_on_memregion_in_humongous In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 08:17:09 GMT, Albert Mingkun Yang wrote: > Simple change of removing an `if` check. > > Test: tier1-6 Marked as reviewed by iwalulya (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9462 From kbarrett at openjdk.org Wed Jul 13 14:03:11 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 13 Jul 2022 14:03:11 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v5] In-Reply-To: References: Message-ID: <3RMOjf00YO53Jz1gNOLYIHjETSazWQPT-sbpNnM-Ybk=.25f1c9b4-a806-424d-adc4-cf1714e70e83@github.com> On Wed, 13 Jul 2022 13:51:15 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? >> >> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by >> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) >> * adding additional `@requires` >> * removing it in tests where it is not actually required >> >> Testing: gha, running tests >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > Epsilon needs UnlockExperimentalOptions Drat! I meant to check for that and then forgot. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Wed Jul 13 16:10:04 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 16:10:04 GMT Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests [v5] In-Reply-To: <3RMOjf00YO53Jz1gNOLYIHjETSazWQPT-sbpNnM-Ybk=.25f1c9b4-a806-424d-adc4-cf1714e70e83@github.com> References: <3RMOjf00YO53Jz1gNOLYIHjETSazWQPT-sbpNnM-Ybk=.25f1c9b4-a806-424d-adc4-cf1714e70e83@github.com> Message-ID: On Wed, 13 Jul 2022 14:01:09 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> Epsilon needs UnlockExperimentalOptions > > Drat! I meant to check for that and then forgot. Looks good. Thanks @kimbarrett @albertnetymk @lkorinth for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Wed Jul 13 16:11:23 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 16:11:23 GMT Subject: Integrated: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests In-Reply-To: References: Message-ID: On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests? > > As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by > * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them) > * adding additional `@requires` > * removing it in tests where it is not actually required > > Testing: gha, running tests > > Thanks, > Thomas This pull request has now been integrated. Changeset: 2583feb2 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/2583feb21bf5419afc3c1953d964cf89d65fe8a2 Stats: 282 lines in 13 files changed: 208 ins; 24 del; 50 mod 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests Reviewed-by: ayang, lkorinth, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9443 From tschatzl at openjdk.org Wed Jul 13 18:35:29 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 18:35:29 GMT Subject: Integrated: 8290253: gc/g1/TestVerificationInConcurrentCycle.java#id1 fails with "Error. can't find sun.hotspot.WhiteBox in test directory or libraries" Message-ID: Hi, can I have reviews for this fix to the `TestVerificationInConcurrentCycle.java` test that due to a merge issue referenced the old WhiteBox library which fails during testing because it had been deleted in the meantime. Testing: gha, test passes in release and debug locally Thanks, Thomas ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/9483/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9483&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290253 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9483.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9483/head:pull/9483 PR: https://git.openjdk.org/jdk/pull/9483 From dcubed at openjdk.org Wed Jul 13 18:35:29 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 13 Jul 2022 18:35:29 GMT Subject: Integrated: 8290253: gc/g1/TestVerificationInConcurrentCycle.java#id1 fails with "Error. can't find sun.hotspot.WhiteBox in test directory or libraries" In-Reply-To: References: Message-ID: <4WJAtxwqsKqjzdC8bR_eRT1a-r73Acg3mDFRW96f3zo=.c71eafbb-432f-47d5-9168-0c919d518482@github.com> On Wed, 13 Jul 2022 18:25:18 GMT, Thomas Schatzl wrote: > Hi, > > can I have reviews for this fix to the `TestVerificationInConcurrentCycle.java` test that due to a merge issue referenced the old WhiteBox library which fails during testing because it had been deleted in the meantime. > > Testing: gha, test passes in release and debug locally > > Thanks, > Thomas Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/9483 From tschatzl at openjdk.org Wed Jul 13 18:35:29 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 18:35:29 GMT Subject: Integrated: 8290253: gc/g1/TestVerificationInConcurrentCycle.java#id1 fails with "Error. can't find sun.hotspot.WhiteBox in test directory or libraries" In-Reply-To: <4WJAtxwqsKqjzdC8bR_eRT1a-r73Acg3mDFRW96f3zo=.c71eafbb-432f-47d5-9168-0c919d518482@github.com> References: <4WJAtxwqsKqjzdC8bR_eRT1a-r73Acg3mDFRW96f3zo=.c71eafbb-432f-47d5-9168-0c919d518482@github.com> Message-ID: On Wed, 13 Jul 2022 18:26:51 GMT, Daniel D. Daugherty wrote: >> Hi, >> >> can I have reviews for this fix to the `TestVerificationInConcurrentCycle.java` test that due to a merge issue referenced the old WhiteBox library which fails during testing because it had been deleted in the meantime. >> >> Testing: gha, test passes in release and debug locally >> >> Thanks, >> Thomas > > Thumbs up. This is a trivial fix. Thanks @dcubed-ojdk . ------------- PR: https://git.openjdk.org/jdk/pull/9483 From tschatzl at openjdk.org Wed Jul 13 18:35:30 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 13 Jul 2022 18:35:30 GMT Subject: Integrated: 8290253: gc/g1/TestVerificationInConcurrentCycle.java#id1 fails with "Error. can't find sun.hotspot.WhiteBox in test directory or libraries" In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 18:25:18 GMT, Thomas Schatzl wrote: > Hi, > > can I have reviews for this fix to the `TestVerificationInConcurrentCycle.java` test that due to a merge issue referenced the old WhiteBox library which fails during testing because it had been deleted in the meantime. > > Testing: gha, test passes in release and debug locally > > Thanks, > Thomas This pull request has now been integrated. Changeset: 5e3ecff7 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/5e3ecff7a60708aaf4a3c63f85907e4fb2dcbc9e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8290253: gc/g1/TestVerificationInConcurrentCycle.java#id1 fails with "Error. can't find sun.hotspot.WhiteBox in test directory or libraries" Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/9483 From zgu at openjdk.org Wed Jul 13 18:48:42 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 13 Jul 2022 18:48:42 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode Message-ID: Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). Test: - [x] hotspot_gc_shenandoah - [x] jdk_loom with Shenandoah + iu - [x] hotspot_loom with Shenandoah + iu ------------- Commit messages: - 8290250: Shenandoah: disable Loom for iu mode Changes: https://git.openjdk.org/jdk19/pull/140/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=140&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290250 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk19/pull/140.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/140/head:pull/140 PR: https://git.openjdk.org/jdk19/pull/140 From eosterlund at openjdk.org Wed Jul 13 19:06:21 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 13 Jul 2022 19:06:21 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu wrote: > Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). > > Test: > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + iu > - [x] hotspot_loom with Shenandoah + iu Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. ------------- PR: https://git.openjdk.org/jdk19/pull/140 From zgu at openjdk.org Wed Jul 13 19:31:13 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 13 Jul 2022 19:31:13 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com> On Wed, 13 Jul 2022 19:02:39 GMT, Erik ?sterlund wrote: > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? ------------- PR: https://git.openjdk.org/jdk19/pull/140 From rkennke at openjdk.org Wed Jul 13 19:43:01 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 13 Jul 2022 19:43:01 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu wrote: > Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). > > Test: > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + iu > - [x] hotspot_loom with Shenandoah + iu Yes, looks good. Thank you. ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.org/jdk19/pull/140 From eosterlund at openjdk.org Wed Jul 13 20:04:58 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 13 Jul 2022 20:04:58 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com> References: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com> Message-ID: On Wed, 13 Jul 2022 19:27:40 GMT, Zhengyu Gu wrote: > > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. > > > > Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? > > Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. However, with an IU scheme, that property does not translate. Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. ------------- PR: https://git.openjdk.org/jdk19/pull/140 From jiefu at openjdk.org Wed Jul 13 23:16:36 2022 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 13 Jul 2022 23:16:36 GMT Subject: RFR: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023 Message-ID: Hi all, Please review the trivial fix which fixes a typo (`required` --> `requires`). Thanks. Best regards, Jie ------------- Commit messages: - 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023 Changes: https://git.openjdk.org/jdk/pull/9485/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9485&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290269 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9485.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9485/head:pull/9485 PR: https://git.openjdk.org/jdk/pull/9485 From kbarrett at openjdk.org Thu Jul 14 02:27:03 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 14 Jul 2022 02:27:03 GMT Subject: RFR: 8290223: Initialize G1CardClosure in card scanning once In-Reply-To: <8vlwRbOYyimea17bljpOVA5DkUk-GPLy_e9ANBQGoxY=.6216c8a6-be54-49ec-93f2-fc45969d591f@github.com> References: <8vlwRbOYyimea17bljpOVA5DkUk-GPLy_e9ANBQGoxY=.6216c8a6-be54-49ec-93f2-fc45969d591f@github.com> Message-ID: On Wed, 13 Jul 2022 09:16:29 GMT, Thomas Schatzl wrote: > Hi all, > > please review this minor change to avoid repeatedly initializing `G1CardClosure` in card scanning. > > Testing: gha, local compilation > > Thanks, > Thomas The JBS issue is labled `gc-performance`. Is it measurable? I'm not strongly opposed to the change, but it increases the scope of the scan closure (which is slightly unhelpful for code understanding). It also passes the _heap_roots_found counter (by reference) to the closure constructor before it's value has been initialized, so have to make sure the closure constructor doesn't access the value. So I'd like to know what the benefit might be. ------------- PR: https://git.openjdk.org/jdk/pull/9478 From tschatzl at openjdk.org Thu Jul 14 07:55:08 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 07:55:08 GMT Subject: RFR: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023 In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 23:09:19 GMT, Jie Fu wrote: > Hi all, > > Please review the trivial fix which fixes a typo (`required` --> `requires`). > > Thanks. > Best regards, > Jie Lgtm and trivial ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9485 From ayang at openjdk.org Thu Jul 14 07:58:04 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Jul 2022 07:58:04 GMT Subject: RFR: 8290080: G1: Remove unnecessary is-obj-dead check in HeapRegion::do_oops_on_memregion_in_humongous In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 08:17:09 GMT, Albert Mingkun Yang wrote: > Simple change of removing an `if` check. > > Test: tier1-6 Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9462 From ayang at openjdk.org Thu Jul 14 08:00:18 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Jul 2022 08:00:18 GMT Subject: Integrated: 8290080: G1: Remove unnecessary is-obj-dead check in HeapRegion::do_oops_on_memregion_in_humongous In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 08:17:09 GMT, Albert Mingkun Yang wrote: > Simple change of removing an `if` check. > > Test: tier1-6 This pull request has now been integrated. Changeset: 109e21af Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/109e21af667ff85daca1d1e0756e0080dbaf54f3 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod 8290080: G1: Remove unnecessary is-obj-dead check in HeapRegion::do_oops_on_memregion_in_humongous Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9462 From tschatzl at openjdk.org Thu Jul 14 08:25:50 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 08:25:50 GMT Subject: RFR: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023 In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 23:09:19 GMT, Jie Fu wrote: > Hi all, > > Please review the trivial fix which fixes a typo (`required` --> `requires`). > > Thanks. > Best regards, > Jie Also, apologies for the issue - I did not do release build runs with the change, and gha doesn't either. ------------- PR: https://git.openjdk.org/jdk/pull/9485 From jiefu at openjdk.org Thu Jul 14 08:34:05 2022 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 14 Jul 2022 08:34:05 GMT Subject: RFR: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023 In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 07:52:19 GMT, Thomas Schatzl wrote: > Lgtm and trivial Thanks @tschatzl for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9485 From jiefu at openjdk.org Thu Jul 14 08:34:07 2022 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 14 Jul 2022 08:34:07 GMT Subject: Integrated: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023 In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 23:09:19 GMT, Jie Fu wrote: > Hi all, > > Please review the trivial fix which fixes a typo (`required` --> `requires`). > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: be58cbc4 Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/be58cbc417ba5e08aa2118f9522c72c96c181a86 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023 Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/9485 From ayang at openjdk.org Thu Jul 14 08:50:12 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Jul 2022 08:50:12 GMT Subject: RFR: 8290221: G1: Merge multiple calls of get_next_marked_addr in HeapRegion::oops_on_memregion_iterate_in_unparsable In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 07:20:36 GMT, Albert Mingkun Yang wrote: > Simple change of merging two calls of `get_next_marked_addr` into one. > > Test: hotspot_gc Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9477 From ayang at openjdk.org Thu Jul 14 08:50:12 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Jul 2022 08:50:12 GMT Subject: Integrated: 8290221: G1: Merge multiple calls of get_next_marked_addr in HeapRegion::oops_on_memregion_iterate_in_unparsable In-Reply-To: References: Message-ID: <6b0dM9h88jx3qYACZTB0dVhXXirdlbHvc6k-pSqA_jo=.09800d2e-674a-4ed1-a900-e2637444162f@github.com> On Wed, 13 Jul 2022 07:20:36 GMT, Albert Mingkun Yang wrote: > Simple change of merging two calls of `get_next_marked_addr` into one. > > Test: hotspot_gc This pull request has now been integrated. Changeset: c7c20661 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/c7c20661eee727ed8354b19723c359ae7c2d4bd8 Stats: 21 lines in 1 file changed: 6 ins; 12 del; 3 mod 8290221: G1: Merge multiple calls of get_next_marked_addr in HeapRegion::oops_on_memregion_iterate_in_unparsable Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.org/jdk/pull/9477 From ayang at openjdk.org Thu Jul 14 09:05:31 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Jul 2022 09:05:31 GMT Subject: RFR: 8290291: G1: Merge multiple calls of block_size in HeapRegion::block_start Message-ID: Simple change of merging duplicate inline calls. It reduces asm footprint, e.g. `G1RemSet::refine_card_concurrently` by ~200 bytes. (The first commit is what I had originally -- inlining the block-walking logic, because block-walking logic is not used by others and highly specific to its sole caller. Ofc, this is subjective.) Test: hotspot_gc ------------- Commit messages: - helper - g1-inline-forward-block Changes: https://git.openjdk.org/jdk/pull/9490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290291 Stats: 47 lines in 2 files changed: 17 ins; 25 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9490.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9490/head:pull/9490 PR: https://git.openjdk.org/jdk/pull/9490 From ayang at openjdk.org Thu Jul 14 09:28:04 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 14 Jul 2022 09:28:04 GMT Subject: RFR: 8290177: Improve documentation in G1MMUTracker In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 14:48:09 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. > > Testing: gha > > Thanks, > Thomas Some minor comments. src/hotspot/share/gc/g1/g1MMUTracker.cpp line 59: > 57: } > 58: > 59: double G1MMUTracker::calculate_gc_time(double time_stamp) { I think `current_timestamp` reads better; in this file/context `X_time` is (often) used to mean a duration. Keeping the `current` prefix helps also; from the callee's perspective, the arg represents "now". src/hotspot/share/gc/g1/g1MMUTracker.hpp line 113: > 111: > 112: // Determines how many seconds relative to current_time a pause of pause_time length > 113: // would fit the MMU. What I have in mind is sth like "Distance to the upcoming earliest possible GC pause without violating the MMU constraint. The return value is measured in seconds." ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9471 From tschatzl at openjdk.org Thu Jul 14 12:15:03 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 12:15:03 GMT Subject: RFR: 8290223: Initialize G1CardClosure in card scanning once In-Reply-To: <8vlwRbOYyimea17bljpOVA5DkUk-GPLy_e9ANBQGoxY=.6216c8a6-be54-49ec-93f2-fc45969d591f@github.com> References: <8vlwRbOYyimea17bljpOVA5DkUk-GPLy_e9ANBQGoxY=.6216c8a6-be54-49ec-93f2-fc45969d591f@github.com> Message-ID: On Wed, 13 Jul 2022 09:16:29 GMT, Thomas Schatzl wrote: > Hi all, > > please review this minor change to avoid repeatedly initializing `G1CardClosure` in card scanning. > > Testing: gha, local compilation > > Thanks, > Thomas Closing after re-measuring. ------------- PR: https://git.openjdk.org/jdk/pull/9478 From tschatzl at openjdk.org Thu Jul 14 12:15:03 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 12:15:03 GMT Subject: Withdrawn: 8290223: Initialize G1CardClosure in card scanning once In-Reply-To: <8vlwRbOYyimea17bljpOVA5DkUk-GPLy_e9ANBQGoxY=.6216c8a6-be54-49ec-93f2-fc45969d591f@github.com> References: <8vlwRbOYyimea17bljpOVA5DkUk-GPLy_e9ANBQGoxY=.6216c8a6-be54-49ec-93f2-fc45969d591f@github.com> Message-ID: On Wed, 13 Jul 2022 09:16:29 GMT, Thomas Schatzl wrote: > Hi all, > > please review this minor change to avoid repeatedly initializing `G1CardClosure` in card scanning. > > Testing: gha, local compilation > > Thanks, > Thomas This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9478 From tschatzl at openjdk.org Thu Jul 14 12:37:35 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 12:37:35 GMT Subject: RFR: 8290177: Improve documentation in G1MMUTracker [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: ayang review; make clear that "time" is a timestamp in a few places ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9471/files - new: https://git.openjdk.org/jdk/pull/9471/files/f336a8c0..54d89bbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=00-01 Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/9471.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9471/head:pull/9471 PR: https://git.openjdk.org/jdk/pull/9471 From tschatzl at openjdk.org Thu Jul 14 13:03:50 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 13:03:50 GMT Subject: RFR: 8290177: Improve documentation in G1MMUTracker [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: current_timestamp vs. timestamp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9471/files - new: https://git.openjdk.org/jdk/pull/9471/files/54d89bbd..dfafe00b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9471.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9471/head:pull/9471 PR: https://git.openjdk.org/jdk/pull/9471 From tschatzl at openjdk.org Thu Jul 14 13:33:48 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 13:33:48 GMT Subject: RFR: 8290177: Improve documentation in G1MMUTracker [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: More discussions on documentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9471/files - new: https://git.openjdk.org/jdk/pull/9471/files/dfafe00b..668f0e1c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9471.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9471/head:pull/9471 PR: https://git.openjdk.org/jdk/pull/9471 From zgu at openjdk.org Thu Jul 14 14:03:25 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 14 Jul 2022 14:03:25 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive Message-ID: Please review this patch to fix Loom test crash with Shenandoah IU mode. Test: - [x] hotspot_gc_shenandoah - [x] jdk_loom with Shenandoah + IU - [x] hotspot_loom with Shenandoah + IU ------------- Commit messages: - 8288129: Shenandoah: Skynet test crashed with iu + aggressive - Merge branch 'master' into JDK-8288129-iu-vthr - Merge branch 'master' into JDK-8288129-iu-vthr - v0 Changes: https://git.openjdk.org/jdk/pull/9494/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9494&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288129 Stats: 8 lines in 1 file changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9494.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9494/head:pull/9494 PR: https://git.openjdk.org/jdk/pull/9494 From tschatzl at openjdk.org Thu Jul 14 14:16:59 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 14:16:59 GMT Subject: RFR: 8290177: Improve documentation in G1MMUTracker [v5] In-Reply-To: References: Message-ID: > Hi all, > > please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. > > Testing: gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: fix compilation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9471/files - new: https://git.openjdk.org/jdk/pull/9471/files/668f0e1c..0505d5f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9471&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9471.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9471/head:pull/9471 PR: https://git.openjdk.org/jdk/pull/9471 From zgu at openjdk.org Thu Jul 14 15:34:47 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 14 Jul 2022 15:34:47 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive [v2] In-Reply-To: References: Message-ID: > Please review this patch to fix Loom test crash with Shenandoah IU mode. > > Test: > > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + IU > - [x] hotspot_loom with Shenandoah + IU 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: - Merge branch 'master' into JDK-8288129-iu-vthr - Fix - 8288129: Shenandoah: Skynet test crashed with iu + aggressive - Merge branch 'master' into JDK-8288129-iu-vthr - Merge branch 'master' into JDK-8288129-iu-vthr - v0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9494/files - new: https://git.openjdk.org/jdk/pull/9494/files/24cad3b5..6f901a74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9494&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9494&range=00-01 Stats: 996 lines in 46 files changed: 686 ins; 75 del; 235 mod Patch: https://git.openjdk.org/jdk/pull/9494.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9494/head:pull/9494 PR: https://git.openjdk.org/jdk/pull/9494 From zgu at openjdk.org Thu Jul 14 15:57:17 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 14 Jul 2022 15:57:17 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive [v3] In-Reply-To: References: Message-ID: > Please review this patch to fix Loom test crash with Shenandoah IU mode. > > Test: > > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + IU > - [x] hotspot_loom with Shenandoah + IU Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: Always requires barrier for IU ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9494/files - new: https://git.openjdk.org/jdk/pull/9494/files/6f901a74..067b51eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9494&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9494&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9494.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9494/head:pull/9494 PR: https://git.openjdk.org/jdk/pull/9494 From zgu at openjdk.org Thu Jul 14 16:41:03 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 14 Jul 2022 16:41:03 GMT Subject: Withdrawn: 8288129: Shenandoah: Skynet test crashed with iu + aggressive In-Reply-To: References: Message-ID: <24LBExD5WMSzWnymHEjzu8tUPCB4AG50qxbzRFJFweo=.25e9ef00-c7a1-45a6-8199-d55b03e5e993@github.com> On Thu, 14 Jul 2022 13:54:35 GMT, Zhengyu Gu wrote: > Please review this patch to fix Loom test crash with Shenandoah IU mode. > > Test: > > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + IU > - [x] hotspot_loom with Shenandoah + IU This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9494 From zgu at openjdk.org Thu Jul 14 17:20:28 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 14 Jul 2022 17:20:28 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com> Message-ID: On Wed, 13 Jul 2022 20:01:51 GMT, Erik ?sterlund wrote: > > > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. > > > > > > Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? > > Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. > > However, with an IU scheme, that property does not translate. > > Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. > > So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. Unfortunately, IU problem is beyond the barrier elision. Even I don't elide the barrier for IU, I still see failures. ------------- PR: https://git.openjdk.org/jdk19/pull/140 From zgu at openjdk.org Thu Jul 14 17:23:07 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Thu, 14 Jul 2022 17:23:07 GMT Subject: [jdk19] Integrated: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: <5Aro-qPeLVOs5STFw3kaBl-XBDYinhkrKDldDGxL5eM=.4b5000b4-36ca-4c13-a8be-42837a393b46@github.com> On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu wrote: > Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). > > Test: > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + iu > - [x] hotspot_loom with Shenandoah + iu This pull request has now been integrated. Changeset: c8e03151 Author: Zhengyu Gu URL: https://git.openjdk.org/jdk19/commit/c8e03151142c444710321c2e8a41e242283922a4 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8290250: Shenandoah: disable Loom for iu mode Reviewed-by: rkennke ------------- PR: https://git.openjdk.org/jdk19/pull/140 From eosterlund at openjdk.org Thu Jul 14 17:44:09 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 14 Jul 2022 17:44:09 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com> Message-ID: On Thu, 14 Jul 2022 17:17:49 GMT, Zhengyu Gu wrote: > > > > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. > > > > > > > > > > > > Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? > > > > > > Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. > > > > > > However, with an IU scheme, that property does not translate. > > > > > > Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. > > > > > > So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. > > > > Unfortunately, IU problem is beyond the barrier elision. Even I don't elide the barrier for IU, I still see failures. Right. Loom assumes that write barriers are not needed on newly allocated objects, so that it can copy oops from the stack to the heap. Shenandoah with IU mode is the only collector where that is not true, due to the reason I outlined. What I'm saying isn't that turning off barrier elision in IU mode will fix your current loom crash. I'm saying that even without loom, the barrier elision is invalid in general. I thought I'd let you know, in case you want Shenandoah with IU mode to work reliably at all. ------------- PR: https://git.openjdk.org/jdk19/pull/140 From rkennke at openjdk.org Thu Jul 14 18:21:26 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 14 Jul 2022 18:21:26 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com> Message-ID: On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund wrote: > > > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. > > > > > > Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? > > Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. > > However, with an IU scheme, that property does not translate. > > Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. > > So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem. [1] https://www.cs.technion.ac.il/~yahave/papers/pldi06-cgc.pdf ------------- PR: https://git.openjdk.org/jdk19/pull/140 From erik.osterlund at oracle.com Thu Jul 14 19:10:13 2022 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 14 Jul 2022 19:10:13 +0000 Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com> Message-ID: <44214571-5AAC-4FA1-B25B-A35F59C67D97@oracle.com> Hi Roman, The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked. I will try to explain my example more clearly step by step. 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B. 2. Marking starts. A is matked as a root, but before B is marked concurrently? 3. T1 loads B from the field of A. 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers. 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through. 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash) 7. The root from T1 to B is discarded. 8. Concurrent marking traces from A but finds only null from step 4. 9. Marking terminates. You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode. Hope this helps. /Erik > On 14 Jul 2022, at 20:21, Roman Kennke wrote: > > ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund wrote: > >>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. >>> >>> >>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? >> >> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. >> >> However, with an IU scheme, that property does not translate. >> >> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. >> >> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. > > IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem. > > [1] https://www.cs.technion.ac.il/~yahave/papers/pldi06-cgc.pdf > > ------------- > > PR: https://git.openjdk.org/jdk19/pull/140 From rkennke at redhat.com Thu Jul 14 19:49:15 2022 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Jul 2022 21:49:15 +0200 Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: <44214571-5AAC-4FA1-B25B-A35F59C67D97@oracle.com> References: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com> <44214571-5AAC-4FA1-B25B-A35F59C67D97@oracle.com> Message-ID: Hey Erik, I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already. Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-) Thanks, Roman > Hi Roman, > > The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked. > > I will try to explain my example more clearly step by step. > > 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B. > > 2. Marking starts. A is matked as a root, but before B is marked concurrently? > > 3. T1 loads B from the field of A. > > 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers. > > 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through. > > 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash) > > 7. The root from T1 to B is discarded. > > 8. Concurrent marking traces from A but finds only null from step 4. > > 9. Marking terminates. > > You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode. > > Hope this helps. > > /Erik > >> On 14 Jul 2022, at 20:21, Roman Kennke wrote: >> >> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund wrote: >> >>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. >>>> >>>> >>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? >>> >>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. >>> >>> However, with an IU scheme, that property does not translate. >>> >>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. >>> >>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. >> >> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem. >> >> [1] https://www.cs.technion.ac.il/~yahave/papers/pldi06-cgc.pdf >> >> ------------- >> >> PR: https://git.openjdk.org/jdk19/pull/140 From erik.osterlund at oracle.com Thu Jul 14 20:03:35 2022 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 14 Jul 2022 20:03:35 +0000 Subject: [External] : Re: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: The problem is that when you store the edge from C to B in my example, at step 6, the newly allocated object C is implicitly live, but the new value being written to the field (B) is not implicitly live and needs to be explicitly kept alive in an IU model. But it isn?t if the barrier is elided. This is a difference to SATB where B is also implicitly live due to being part of the snapshot-at-the-beginning, which is why eliding the barrier has no effect with SATB. /Erik > On 14 Jul 2022, at 21:49, Roman Kennke wrote: > > ?Hey Erik, > > I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already. > > Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-) > > Thanks, > Roman > > >> Hi Roman, >> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked. >> I will try to explain my example more clearly step by step. >> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B. >> 2. Marking starts. A is matked as a root, but before B is marked concurrently? >> 3. T1 loads B from the field of A. >> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers. >> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through. >> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash) >> 7. The root from T1 to B is discarded. >> 8. Concurrent marking traces from A but finds only null from step 4. >> 9. Marking terminates. >> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode. >> Hope this helps. >> /Erik >>>> On 14 Jul 2022, at 20:21, Roman Kennke wrote: >>> >>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund wrote: >>> >>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. >>>>> >>>>> >>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? >>>> >>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. >>>> >>>> However, with an IU scheme, that property does not translate. >>>> >>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. >>>> >>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. >>> >>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem. >>> >>> [1] https://urldefense.com/v3/__https://www.cs.technion.ac.il/*yahave/papers/pldi06-cgc.pdf__;fg!!ACWV5N9M2RV99hQ!LsTZM-MExdpbuTsR32dxyaa5i0r_hGg6RUCZm_YoqDYChH9oqK-dpzVCb7nD-ZtT0hlRzSgDnXxLrSmkx7Q$ >>> ------------- >>> >>> PR: https://git.openjdk.org/jdk19/pull/140 > From rkennke at redhat.com Thu Jul 14 20:11:31 2022 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 14 Jul 2022 22:11:31 +0200 Subject: [External] : Re: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: <5d556173-9092-9ff9-1376-c973841de353@redhat.com> No wait. The barrier is elided when B is new, but when C is new. This works differently than SATB. Makes sense? Roman > The problem is that when you store the edge from C to B in my example, at step 6, the newly allocated object C is implicitly live, but the new value being written to the field (B) is not implicitly live and needs to be explicitly kept alive in an IU model. But it isn?t if the barrier is elided. This is a difference to SATB where B is also implicitly live due to being part of the snapshot-at-the-beginning, which is why eliding the barrier has no effect with SATB. > > /Erik > >> On 14 Jul 2022, at 21:49, Roman Kennke wrote: >> >> ?Hey Erik, >> >> I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already. >> >> Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-) >> >> Thanks, >> Roman >> >> >>> Hi Roman, >>> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked. >>> I will try to explain my example more clearly step by step. >>> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B. >>> 2. Marking starts. A is matked as a root, but before B is marked concurrently? >>> 3. T1 loads B from the field of A. >>> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers. >>> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through. >>> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash) >>> 7. The root from T1 to B is discarded. >>> 8. Concurrent marking traces from A but finds only null from step 4. >>> 9. Marking terminates. >>> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode. >>> Hope this helps. >>> /Erik >>>>> On 14 Jul 2022, at 20:21, Roman Kennke wrote: >>>> >>>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund wrote: >>>> >>>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. >>>>>> >>>>>> >>>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? >>>>> >>>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. >>>>> >>>>> However, with an IU scheme, that property does not translate. >>>>> >>>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. >>>>> >>>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. >>>> >>>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem. >>>> >>>> [1] https://urldefense.com/v3/__https://www.cs.technion.ac.il/*yahave/papers/pldi06-cgc.pdf__;fg!!ACWV5N9M2RV99hQ!LsTZM-MExdpbuTsR32dxyaa5i0r_hGg6RUCZm_YoqDYChH9oqK-dpzVCb7nD-ZtT0hlRzSgDnXxLrSmkx7Q$ >>>> ------------- >>>> >>>> PR: https://git.openjdk.org/jdk19/pull/140 >> From tschatzl at openjdk.org Thu Jul 14 21:06:18 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 21:06:18 GMT Subject: RFR: 8290177: Improve documentation in G1MMUTracker [v5] In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 14:16:59 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. >> >> Testing: gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > fix compilation Thanks for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/9471 From erik.osterlund at oracle.com Thu Jul 14 21:07:36 2022 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 14 Jul 2022 21:07:36 +0000 Subject: [External] : Re: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: <5d556173-9092-9ff9-1376-c973841de353@redhat.com> References: <5d556173-9092-9ff9-1376-c973841de353@redhat.com> Message-ID: Hi Roman, We seem to agree that eliding barriers purely on the basis that the containing object of a field is newly allocated, is invalid. But you seem to say that you do not elide barriers on e.g. initializing stores. If that is the case, all is well. However? Last time I looked at the store capturing code of C2 for optimizing initializing stores, it emits normal stores with barriers and then in InitializeNode::capture_store it finds stores that are initializing stores for the new object (C), finds and clones the plain store (excluding barriers), and cuts out the old initializing store with IGVN, which should make the IU barrier not ?useful? (only used by dead code), and hence be removed in the useless barrier elimination phase, having the implicit effect of eliding barriers on initializing stores. I think that was indeed the intention of cloning the plain store, and cutting out the old store + barriers. But that isn?t legal with IU. If this works, I don?t see how. Did I miss something? /Erik > On 14 Jul 2022, at 22:11, Roman Kennke wrote: > > ?No wait. The barrier is elided when B is new, but when C is new. This works differently than SATB. Makes sense? > > Roman > > >> The problem is that when you store the edge from C to B in my example, at step 6, the newly allocated object C is implicitly live, but the new value being written to the field (B) is not implicitly live and needs to be explicitly kept alive in an IU model. But it isn?t if the barrier is elided. This is a difference to SATB where B is also implicitly live due to being part of the snapshot-at-the-beginning, which is why eliding the barrier has no effect with SATB. >> /Erik >>>> On 14 Jul 2022, at 21:49, Roman Kennke wrote: >>> >>> ?Hey Erik, >>> >>> I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already. >>> >>> Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-) >>> >>> Thanks, >>> Roman >>> >>> >>>> Hi Roman, >>>> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked. >>>> I will try to explain my example more clearly step by step. >>>> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B. >>>> 2. Marking starts. A is matked as a root, but before B is marked concurrently? >>>> 3. T1 loads B from the field of A. >>>> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers. >>>> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through. >>>> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash) >>>> 7. The root from T1 to B is discarded. >>>> 8. Concurrent marking traces from A but finds only null from step 4. >>>> 9. Marking terminates. >>>> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode. >>>> Hope this helps. >>>> /Erik >>>>>> On 14 Jul 2022, at 20:21, Roman Kennke wrote: >>>>> >>>>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund wrote: >>>>> >>>>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. >>>>>>> >>>>>>> >>>>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? >>>>>> >>>>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. >>>>>> >>>>>> However, with an IU scheme, that property does not translate. >>>>>> >>>>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. >>>>>> >>>>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. >>>>> >>>>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem. >>>>> >>>>> [1] https://urldefense.com/v3/__https://www.cs.technion.ac.il/*yahave/papers/pldi06-cgc.pdf__;fg!!ACWV5N9M2RV99hQ!LsTZM-MExdpbuTsR32dxyaa5i0r_hGg6RUCZm_YoqDYChH9oqK-dpzVCb7nD-ZtT0hlRzSgDnXxLrSmkx7Q$ >>>>> ------------- >>>>> >>>>> PR: https://git.openjdk.org/jdk19/pull/140 >>> > From tschatzl at openjdk.org Thu Jul 14 21:07:37 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 14 Jul 2022 21:07:37 GMT Subject: Integrated: 8290177: Improve documentation in G1MMUTracker In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 14:48:09 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change to improve the naming and documentation in `G1MMUTracker::when_sec`. Recently we have been looking at some young gen sizing issues (for another time), and it took some time to understand what the code does and how it works. This is kind of the result of this internal discussion, but I'm open to improve this further. > > Testing: gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: 757a742a Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/757a742ac78a6ececcc4f9f542f8f7108968129d Stats: 34 lines in 2 files changed: 16 ins; 0 del; 18 mod 8290177: Improve documentation in G1MMUTracker Reviewed-by: iwalulya, ayang ------------- PR: https://git.openjdk.org/jdk/pull/9471 From ysr at openjdk.org Thu Jul 14 23:55:07 2022 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 14 Jul 2022 23:55:07 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu wrote: > Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). > > Test: > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + iu > - [x] hotspot_loom with Shenandoah + iu CMS collected only old gen, and direct allocations in old gen were grey, and so would updates of black objects in old gen. I assume new objects in Shenandoah would also be grey as would be updates of those objects? (That would be the classical IU scheme in my understanding.) I should read the Vechev paper though. Is the Shenandoah treatment of new allocations described anywhere for the IU case? ------------- PR: https://git.openjdk.org/jdk19/pull/140 From erik.osterlund at oracle.com Fri Jul 15 06:04:44 2022 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 15 Jul 2022 06:04:44 +0000 Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: <68446895-002B-488F-B870-4378AD46BF1C@oracle.com> Hi Ramki, If memory serves well, CMS used ?deferred card marking?, to colour allocations into the old generation grey, at a subsequent allocation or in a subsequent safepoint. The important effect of that is that they were coloured grey, before marking terminates, yet importantly after the initializing stores I just described, which would have their barriers elided in C2. So the GC would read the fields after the initializing stores have become visible. As for Shenandoah IU, I?m not sure if the approach is described somewhere. But my understanding is that instead of first writing a new value to a field, and then handing the address of the field to the GC, so that it can read this new value, Shenandoah hands the new value to the GC directly. So rather than colouring the containing object of the field grey, it colours the new value grey. New allocations are black. And that is fine if you don?t elide barriers on newly allocated objects. If initializing stores elide barriers though, the newly allocated object needs to be asynchronously grey, like CMS (due to deferred card marking for old objects and due to subsequent YC for young objects). There is AFAICT no such code, and I think the assumption is that elisions are not happening on newly allocated objects, but I think that they are happening, for initializing stores in C2. At least I can?t see what would stop that machinery from removing the barriers. /Erik > On 15 Jul 2022, at 01:55, Y.Srinivas Ramakrishna wrote: > > ?On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu wrote: > >> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). >> >> Test: >> - [x] hotspot_gc_shenandoah >> - [x] jdk_loom with Shenandoah + iu >> - [x] hotspot_loom with Shenandoah + iu > > CMS collected only old gen, and direct allocations in old gen were grey, and so would updates of black objects in old gen. I assume new objects in Shenandoah would also be grey as would be updates of those objects? (That would be the classical IU scheme in my understanding.) > > I should read the Vechev paper though. Is the Shenandoah treatment of new allocations described anywhere for the IU case? > > ------------- > > PR: https://git.openjdk.org/jdk19/pull/140 From tschatzl at openjdk.org Fri Jul 15 11:12:54 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 15 Jul 2022 11:12:54 GMT Subject: RFR: 8290366: Remove unused during_conc_mark parameter in HeapRegion::note_self_forwarding_removal_start Message-ID: Hi all, can I have reviews for this trivial removal of an unused parameter? Testing: local compilation Thanks, Thomas ------------- Commit messages: - Remove parameter Changes: https://git.openjdk.org/jdk/pull/9510/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9510&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290366 Stats: 7 lines in 3 files changed: 0 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9510.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9510/head:pull/9510 PR: https://git.openjdk.org/jdk/pull/9510 From tschatzl at openjdk.org Fri Jul 15 12:22:11 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 15 Jul 2022 12:22:11 GMT Subject: RFR: 8290291: G1: Merge multiple calls of block_size in HeapRegion::block_start In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 08:55:47 GMT, Albert Mingkun Yang wrote: > Simple change of merging duplicate inline calls. It reduces asm footprint, e.g. `G1RemSet::refine_card_concurrently` by ~200 bytes. > > (The first commit is what I had originally -- inlining the block-walking logic, because block-walking logic is not used by others and highly specific to its sole caller. Ofc, this is subjective.) > > Test: hotspot_gc Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9490 From ayang at openjdk.org Fri Jul 15 13:45:06 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Jul 2022 13:45:06 GMT Subject: RFR: 8290366: Remove unused during_conc_mark parameter in HeapRegion::note_self_forwarding_removal_start In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 11:03:25 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this trivial removal of an unused parameter? > > Testing: local compilation > > Thanks, > Thomas Good and trivial. ------------- Marked as reviewed by ayang (Reviewer). PR: https://git.openjdk.org/jdk/pull/9510 From rkennke at redhat.com Fri Jul 15 13:52:56 2022 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 15 Jul 2022 15:52:56 +0200 Subject: [External] : Re: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: <5d556173-9092-9ff9-1376-c973841de353@redhat.com> Message-ID: Hi Erik, > Hi Roman, > > We seem to agree that eliding barriers purely on the basis that the containing object of a field is newly allocated, is invalid. But you seem to say that you do not elide barriers on e.g. initializing stores. If that is the case, all is well. However? > Last time I looked at the store capturing code of C2 for optimizing initializing stores, it emits normal stores with barriers and then in InitializeNode::capture_store it finds stores that are initializing stores for the new object (C), finds and clones the plain store (excluding barriers), and cuts out the old initializing store with IGVN, which should make the IU barrier not ?useful? (only used by dead code), and hence be removed in the useless barrier elimination phase, having the implicit effect of eliding barriers on initializing stores. I think that was indeed the intention of cloning the plain store, and cutting out the old store + barriers. But that isn?t legal with IU. If this works, I don?t see how. Did I miss something? Ok, this seems indeed problematic. A way to get rid of it easily would be -XX:-ReduceFieldZeroing, right? But I suspect that does more than is needed. I need to think about this a little more. Thanks for pointing this out! /Roman > /Erik > >> On 14 Jul 2022, at 22:11, Roman Kennke wrote: >> >> ?No wait. The barrier is elided when B is new, but when C is new. This works differently than SATB. Makes sense? >> >> Roman >> >> >>> The problem is that when you store the edge from C to B in my example, at step 6, the newly allocated object C is implicitly live, but the new value being written to the field (B) is not implicitly live and needs to be explicitly kept alive in an IU model. But it isn?t if the barrier is elided. This is a difference to SATB where B is also implicitly live due to being part of the snapshot-at-the-beginning, which is why eliding the barrier has no effect with SATB. >>> /Erik >>>>> On 14 Jul 2022, at 21:49, Roman Kennke wrote: >>>> >>>> ?Hey Erik, >>>> >>>> I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already. >>>> >>>> Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-) >>>> >>>> Thanks, >>>> Roman >>>> >>>> >>>>> Hi Roman, >>>>> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked. >>>>> I will try to explain my example more clearly step by step. >>>>> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B. >>>>> 2. Marking starts. A is matked as a root, but before B is marked concurrently? >>>>> 3. T1 loads B from the field of A. >>>>> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers. >>>>> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through. >>>>> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash) >>>>> 7. The root from T1 to B is discarded. >>>>> 8. Concurrent marking traces from A but finds only null from step 4. >>>>> 9. Marking terminates. >>>>> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode. >>>>> Hope this helps. >>>>> /Erik >>>>>>> On 14 Jul 2022, at 20:21, Roman Kennke wrote: >>>>>> >>>>>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund wrote: >>>>>> >>>>>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found. >>>>>>>> >>>>>>>> >>>>>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything? >>>>>>> >>>>>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. >>>>>>> >>>>>>> However, with an IU scheme, that property does not translate. >>>>>>> >>>>>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object. >>>>>>> >>>>>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that. >>>>>> >>>>>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem. >>>>>> >>>>>> [1] https://urldefense.com/v3/__https://www.cs.technion.ac.il/*yahave/papers/pldi06-cgc.pdf__;fg!!ACWV5N9M2RV99hQ!LsTZM-MExdpbuTsR32dxyaa5i0r_hGg6RUCZm_YoqDYChH9oqK-dpzVCb7nD-ZtT0hlRzSgDnXxLrSmkx7Q$ >>>>>> ------------- >>>>>> >>>>>> PR: https://git.openjdk.org/jdk19/pull/140 >>>> >> From tschatzl at openjdk.org Fri Jul 15 14:01:11 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 15 Jul 2022 14:01:11 GMT Subject: RFR: 8290366: Remove unused during_conc_mark parameter in HeapRegion::note_self_forwarding_removal_start In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 11:03:25 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this trivial removal of an unused parameter? > > Testing: local compilation > > Thanks, > Thomas Thanks for your review ------------- PR: https://git.openjdk.org/jdk/pull/9510 From tschatzl at openjdk.org Fri Jul 15 14:01:11 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 15 Jul 2022 14:01:11 GMT Subject: Integrated: 8290366: Remove unused during_conc_mark parameter in HeapRegion::note_self_forwarding_removal_start In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 11:03:25 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this trivial removal of an unused parameter? > > Testing: local compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: b4e2ce00 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/b4e2ce0094751540ac0673b22af3b3221d1fd74a Stats: 7 lines in 3 files changed: 0 ins; 4 del; 3 mod 8290366: Remove unused during_conc_mark parameter in HeapRegion::note_self_forwarding_removal_start Reviewed-by: ayang ------------- PR: https://git.openjdk.org/jdk/pull/9510 From ayang at openjdk.org Fri Jul 15 14:22:30 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Fri, 15 Jul 2022 14:22:30 GMT Subject: RFR: 8290376: G1: Refactor G1MMUTracker::when_sec Message-ID: <32PFxzf2tSpty-UgoZsVOVxJ32Avu_bnY0LdRfCgksw=.8c6e63de-5df5-4ba0-92d5-4910cf239ad7@github.com> Introducing a more intuitive implementation. This PR consists of two commits: the first adds the new algorithm and verifies the result is same as before. The second commit removes the old implementation. Test: tier1-6 for the first commit. ------------- Commit messages: - replace - g1-mmu Changes: https://git.openjdk.org/jdk/pull/9517/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9517&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290376 Stats: 61 lines in 2 files changed: 25 ins; 17 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/9517.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9517/head:pull/9517 PR: https://git.openjdk.org/jdk/pull/9517 From zgu at openjdk.org Fri Jul 15 17:30:14 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Fri, 15 Jul 2022 17:30:14 GMT Subject: RFR: 8290374: Shenandoah: Remove inaccurate comment on SBS::load_reference_barrier() Message-ID: Please review this trivial patch to remove inaccurate comment. Even with separate mark-compact marking phase, we still need `is_evacuation_in_progress()` check to deal with the scenario that Full GC was upgraded from concurrent/degenerated GC. ------------- Commit messages: - 8290374: Shenandoah: Remove inaccurate comment on SBS::load_reference_barrier() Changes: https://git.openjdk.org/jdk/pull/9522/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9522&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290374 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9522.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9522/head:pull/9522 PR: https://git.openjdk.org/jdk/pull/9522 From zgu at openjdk.org Fri Jul 15 17:45:11 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Fri, 15 Jul 2022 17:45:11 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: <7AMezvvM8ja-VCJl-ZI_1J5ssxgHhdS0tq6S4IWn4jc=.67d4b473-0d63-46c0-83c5-4d49686caa45@github.com> On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu wrote: > Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). > > Test: > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + iu > - [x] hotspot_loom with Shenandoah + iu The problem is beyond C2, `Skynet` fails with -`Xint`: Referenced from: interior location: 0x00000000e4de6df0 0x00000000e4de6dc8 - klass 0x0000000800036ec0 jdk.internal.vm.StackChunk allocated after mark start not after update watermark marked strong marked weak not in collection set mark: mark(is_neutral no_hash age=0) region: | 1335|R |BTE e4dc0000, e4e00000, e4e00000|TAMS e4dc0000|UWM e4e00000|U 256K|T 256K|G 0B|S 0B|L 256K|CP 0 Object: 0x00000000e4c2e2b0 - klass 0x0000000800036ec0 jdk.internal.vm.StackChunk not allocated after mark start not after update watermark not marked strong not marked weak not in collection set mark: mark(is_neutral no_hash age=0) region: | 1328|R |BTE e4c00000, e4c40000, e4c40000|TAMS e4c40000|UWM e4c40000|U 256K|T 256K|G 0B|S 0B|L 93264B|CP 0 Forwardee: (the object itself) So, it seems that IU mode either misses iu barrier on load or we need to treat new object as grey. ------------- PR: https://git.openjdk.org/jdk19/pull/140 From erik.osterlund at oracle.com Fri Jul 15 21:37:48 2022 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 15 Jul 2022 21:37:48 +0000 Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: <7AMezvvM8ja-VCJl-ZI_1J5ssxgHhdS0tq6S4IWn4jc=.67d4b473-0d63-46c0-83c5-4d49686caa45@github.com> References: <7AMezvvM8ja-VCJl-ZI_1J5ssxgHhdS0tq6S4IWn4jc=.67d4b473-0d63-46c0-83c5-4d49686caa45@github.com> Message-ID: <5816BFC1-D2E7-4D23-9F50-C38D3C69E63F@oracle.com> Hi Zhengyu, I suppose requires_barriers needs to return true when marking is active with IU, as you need barriers even on newly allocated objects then, as I was discussing. /Erik > On 15 Jul 2022, at 19:45, Zhengyu Gu wrote: > > ?On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu wrote: > >> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). >> >> Test: >> - [x] hotspot_gc_shenandoah >> - [x] jdk_loom with Shenandoah + iu >> - [x] hotspot_loom with Shenandoah + iu > > The problem is beyond C2, `Skynet` fails with -`Xint`: > > > Referenced from: > interior location: 0x00000000e4de6df0 > 0x00000000e4de6dc8 - klass 0x0000000800036ec0 jdk.internal.vm.StackChunk > allocated after mark start > not after update watermark > marked strong > marked weak > not in collection set > mark: mark(is_neutral no_hash age=0) > region: | 1335|R |BTE e4dc0000, e4e00000, e4e00000|TAMS e4dc0000|UWM e4e00000|U 256K|T 256K|G 0B|S 0B|L 256K|CP 0 > > Object: > 0x00000000e4c2e2b0 - klass 0x0000000800036ec0 jdk.internal.vm.StackChunk > not allocated after mark start > not after update watermark > not marked strong > not marked weak > not in collection set > mark: mark(is_neutral no_hash age=0) > region: | 1328|R |BTE e4c00000, e4c40000, e4c40000|TAMS e4c40000|UWM e4c40000|U 256K|T 256K|G 0B|S 0B|L 93264B|CP 0 > > Forwardee: > (the object itself) > > > So, it seems that IU mode either misses iu barrier on load or we need to treat new object as grey. > > ------------- > > PR: https://git.openjdk.org/jdk19/pull/140 From jwilhelm at openjdk.org Sat Jul 16 12:36:44 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sat, 16 Jul 2022 12:36:44 GMT Subject: RFR: Merge jdk19 Message-ID: Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8281969: Bad result for the snippet @link tag if substring/regex consists of whitespace - 8290250: Shenandoah: disable Loom for iu mode - 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9526&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9526&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9526/files Stats: 68 lines in 7 files changed: 34 ins; 12 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/9526.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9526/head:pull/9526 PR: https://git.openjdk.org/jdk/pull/9526 From jwilhelm at openjdk.org Sun Jul 17 15:15:03 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Sun, 17 Jul 2022 15:15:03 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 12:26:23 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 522b6574 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/522b65743ca10fcba0a27d25b8fa11319999e228 Stats: 68 lines in 7 files changed: 34 ins; 12 del; 22 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9526 From zgu at openjdk.org Sun Jul 17 23:55:13 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Sun, 17 Jul 2022 23:55:13 GMT Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode In-Reply-To: References: Message-ID: <_pU_wj7BaFUmMUyWClA7R8zby8Yqg74mcC_NLfLLyJE=.97ac9d30-6612-4f12-adb8-e265bf4b17ea@github.com> On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu wrote: > Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature). > > Test: > - [x] hotspot_gc_shenandoah > - [x] jdk_loom with Shenandoah + iu > - [x] hotspot_loom with Shenandoah + iu > _Mailing list message from [Erik Osterlund](mailto:erik.osterlund at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at mail.openjdk.org):_ > > Hi Zhengyu, > > I suppose requires_barriers needs to return true when marking is active with IU, as you need barriers even on newly allocated objects then, as I was discussing. > > /Erik Tried that, still not working. I can not see how it can be Loom specific? but seems it's only exposed by `Skynet` Thanks, -Zhengyu ------------- PR: https://git.openjdk.org/jdk19/pull/140 From rkennke at openjdk.org Mon Jul 18 11:31:48 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Jul 2022 11:31:48 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive [v3] In-Reply-To: References: Message-ID: On Thu, 14 Jul 2022 15:57:17 GMT, Zhengyu Gu wrote: >> Please review this patch to fix Loom test crash with Shenandoah IU mode. >> >> Test: >> >> - [x] hotspot_gc_shenandoah >> - [x] jdk_loom with Shenandoah + IU >> - [x] hotspot_loom with Shenandoah + IU > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > Always requires barrier for IU Looks good to me. ------------- PR: https://git.openjdk.org/jdk/pull/9494 From zgu at openjdk.org Mon Jul 18 12:42:00 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 18 Jul 2022 12:42:00 GMT Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive [v3] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 11:28:12 GMT, Roman Kennke wrote: > Looks good to me. I closed it. Unfortunately, the fix can still fail ... ------------- PR: https://git.openjdk.org/jdk/pull/9494 From zgu at openjdk.org Mon Jul 18 13:10:05 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 18 Jul 2022 13:10:05 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v6] 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 13 additional commits since the last revision: - Merge branch 'master' into JDK-8287805-evac-updt-closures - Move get thread closer to the use - Aleksey's comment - 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 - ... and 3 more: https://git.openjdk.org/jdk/compare/3fc125de...8c12588d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9023/files - new: https://git.openjdk.org/jdk/pull/9023/files/44f50839..8c12588d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9023&range=04-05 Stats: 98651 lines in 2162 files changed: 52824 ins; 28883 del; 16944 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 shade at openjdk.org Mon Jul 18 13:10:05 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 18 Jul 2022 13:10:05 GMT Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root closures [v6] In-Reply-To: References: Message-ID: On Mon, 18 Jul 2022 13:05: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 > > 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 13 additional commits since the last revision: > > - Merge branch 'master' into JDK-8287805-evac-updt-closures > - Move get thread closer to the use > - Aleksey's comment > - 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 > - ... and 3 more: https://git.openjdk.org/jdk/compare/3fc125de...8c12588d Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9023 From zgu at openjdk.org Mon Jul 18 16:58:02 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Mon, 18 Jul 2022 16:58:02 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: b2010a74 Author: Zhengyu Gu URL: https://git.openjdk.org/jdk/commit/b2010a748137d17f4968659503e0579ea8558afd Stats: 113 lines in 4 files changed: 15 ins; 68 del; 30 mod 8287805: Shenandoah: consolidate evacuate-update-root closures Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/9023 From tschatzl at openjdk.org Tue Jul 19 09:16:34 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 19 Jul 2022 09:16:34 GMT Subject: RFR: 8290512: G1: Fix typo in allocation statistics log message Message-ID: Hi all, please review this trivial change to add a whitespace to a log message. Testing: local compilation Thanks, Thomas ------------- Commit messages: - Typo fixed Changes: https://git.openjdk.org/jdk/pull/9552/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9552&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290512 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9552.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9552/head:pull/9552 PR: https://git.openjdk.org/jdk/pull/9552 From kbarrett at openjdk.org Tue Jul 19 11:18:04 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 19 Jul 2022 11:18:04 GMT Subject: RFR: 8290512: G1: Fix typo in allocation statistics log message In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 09:08:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial change to add a whitespace to a log message. > > Testing: local compilation > > Thanks, > Thomas Looks good, and trivial, but with a suggestion for further improvement if you want. src/hotspot/share/gc/g1/g1OldGenAllocationTracker.cpp line 53: > 51: > 52: log_debug(gc, alloc, stats)("Old generation allocation in the last mutator period, " > 53: "old gen allocated: " SIZE_FORMAT "B, humongous allocated: " SIZE_FORMAT "B, " You could replace uses of `SIZE_FORMAT` with "%zu" formatting directives, which might allow removal of the line break in the string without making it overly long. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9552 From tschatzl at openjdk.org Tue Jul 19 11:36:35 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 19 Jul 2022 11:36:35 GMT Subject: RFR: 8290512: G1: Fix typo in allocation statistics log message [v2] In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 11:12:46 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett review > > src/hotspot/share/gc/g1/g1OldGenAllocationTracker.cpp line 53: > >> 51: >> 52: log_debug(gc, alloc, stats)("Old generation allocation in the last mutator period, " >> 53: "old gen allocated: " SIZE_FORMAT "B, humongous allocated: " SIZE_FORMAT "B, " > > You could replace uses of `SIZE_FORMAT` with "%zu" formatting directives, which might allow removal of the line break in the string without making it overly long. Done. Unfortunately the string is still too long for my taste, so I kept it. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9552 From tschatzl at openjdk.org Tue Jul 19 11:36:34 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 19 Jul 2022 11:36:34 GMT Subject: RFR: 8290512: G1: Fix typo in allocation statistics log message [v2] In-Reply-To: References: Message-ID: <2LwK_NjStwWcwBnKBKqCr7wra3jvRtn0KUKx2rn4xbs=.8f94489e-0ed9-4233-8fb8-8fd93db62769@github.com> > Hi all, > > please review this trivial change to add a whitespace to a log message. > > Testing: local compilation > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9552/files - new: https://git.openjdk.org/jdk/pull/9552/files/95baf3a2..84ba4420 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9552&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9552&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9552.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9552/head:pull/9552 PR: https://git.openjdk.org/jdk/pull/9552 From tschatzl at openjdk.org Tue Jul 19 12:44:03 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 19 Jul 2022 12:44:03 GMT Subject: RFR: 8290512: G1: Fix typo in allocation statistics log message [v2] In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 11:14:50 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett review > > Looks good, and trivial, but with a suggestion for further improvement if you want. Thanks @kimbarrett for the review ------------- PR: https://git.openjdk.org/jdk/pull/9552 From tschatzl at openjdk.org Tue Jul 19 12:44:05 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 19 Jul 2022 12:44:05 GMT Subject: Integrated: 8290512: G1: Fix typo in allocation statistics log message In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 09:08:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this trivial change to add a whitespace to a log message. > > Testing: local compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: a41b12f4 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/a41b12f430b8d6ebbb634c0a6a077ed13c68bcb7 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8290512: G1: Fix typo in allocation statistics log message Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9552 From tschatzl at openjdk.org Tue Jul 19 13:41:24 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 19 Jul 2022 13:41:24 GMT Subject: RFR: 8290533: Remove G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*,oop) Message-ID: Hi all, please review this simple change to merge the `G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*, oop)` method with the other overload as this is its only use. Testing: local compilation Thanks, Thomas ------------- Commit messages: - Initial version Changes: https://git.openjdk.org/jdk/pull/9556/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9556&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290533 Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9556.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9556/head:pull/9556 PR: https://git.openjdk.org/jdk/pull/9556 From tschatzl at openjdk.org Tue Jul 19 15:55:26 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 19 Jul 2022 15:55:26 GMT Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector Message-ID: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> Hi all, can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read. Testing: tier1-3 Thanks, Thomas ------------- Commit messages: - fix copyright years - Fix verification - needs to be uninitialized (nullptr) - initial version Changes: https://git.openjdk.org/jdk/pull/9560/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9560&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290525 Stats: 79 lines in 14 files changed: 28 ins; 32 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/9560.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9560/head:pull/9560 PR: https://git.openjdk.org/jdk/pull/9560 From sangheki at openjdk.org Tue Jul 19 16:27:46 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Tue, 19 Jul 2022 16:27:46 GMT Subject: RFR: 8290533: Remove G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*,oop) In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 13:33:36 GMT, Thomas Schatzl wrote: > Hi all, > > please review this simple change to merge the `G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*, oop)` method with the other overload as this is its only use. > > Testing: local compilation > > Thanks, > Thomas Marked as reviewed by sangheki (Reviewer). Looks good. ------------- PR: https://git.openjdk.org/jdk/pull/9556 From kbarrett at openjdk.org Wed Jul 20 01:16:44 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Jul 2022 01:16:44 GMT Subject: RFR: 8290468: Remove gc/gctests/mallocWithGC tests In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 20:44:12 GMT, Leonid Mesnik wrote: > The gc/gctests/mallocWithGC tests test interaction of GC with malloc/free. > They are duplicates of vmTestbase/gc/lock/malloc/ tests. > Not sure that even vmTestbase/gc/lock/malloc/ are needed. GC do nothing with malloc/free and it doesn't make sense to test their interaction. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9563 From tschatzl at openjdk.org Wed Jul 20 08:30:48 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 20 Jul 2022 08:30:48 GMT Subject: RFR: 8290468: Remove gc/gctests/mallocWithGC tests In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 20:44:12 GMT, Leonid Mesnik wrote: > The gc/gctests/mallocWithGC tests test interaction of GC with malloc/free. > They are duplicates of vmTestbase/gc/lock/malloc/ tests. > Not sure that even vmTestbase/gc/lock/malloc/ are needed. GC do nothing with malloc/free and it doesn't make sense to test their interaction. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9563 From shade at openjdk.org Wed Jul 20 12:25:10 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 20 Jul 2022 12:25:10 GMT Subject: RFR: 8290374: Shenandoah: Remove inaccurate comment on SBS::load_reference_barrier() In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 17:17:11 GMT, Zhengyu Gu wrote: > Please review this trivial patch to remove inaccurate comment. > > Even with separate mark-compact marking phase, we still need `is_evacuation_in_progress()` check to deal with the scenario that Full GC was upgraded from concurrent/degenerated GC. OK, right. Looks good. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9522 From zgu at openjdk.org Wed Jul 20 12:47:03 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 20 Jul 2022 12:47:03 GMT Subject: Integrated: 8290374: Shenandoah: Remove inaccurate comment on SBS::load_reference_barrier() In-Reply-To: References: Message-ID: On Fri, 15 Jul 2022 17:17:11 GMT, Zhengyu Gu wrote: > Please review this trivial patch to remove inaccurate comment. > > Even with separate mark-compact marking phase, we still need `is_evacuation_in_progress()` check to deal with the scenario that Full GC was upgraded from concurrent/degenerated GC. This pull request has now been integrated. Changeset: 011958d3 Author: Zhengyu Gu URL: https://git.openjdk.org/jdk/commit/011958d30b275f0f6a2de097938ceeb34beb314d Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod 8290374: Shenandoah: Remove inaccurate comment on SBS::load_reference_barrier() Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/9522 From tschatzl at openjdk.org Wed Jul 20 15:09:13 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 20 Jul 2022 15:09:13 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template. Message-ID: Hi all, can I have reviews for this change that removes the templates and casts around `G1CollectedHeap::heap_region_containing`? Testing: tier1-5 Thanks, Thomas ------------- Commit messages: - Remove some more casts - Revert changes to heap_region_containing() - Remove cast - Remove unnecessary changes - some changes - Use const void* Changes: https://git.openjdk.org/jdk/pull/9572/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9572&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8237913 Stats: 35 lines in 10 files changed: 0 ins; 10 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/9572.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9572/head:pull/9572 PR: https://git.openjdk.org/jdk/pull/9572 From kbarrett at openjdk.org Wed Jul 20 16:09:00 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 20 Jul 2022 16:09:00 GMT Subject: RFR: 8290533: Remove G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*,oop) In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 13:33:36 GMT, Thomas Schatzl wrote: > Hi all, > > please review this simple change to merge the `G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*, oop)` method with the other overload as this is its only use. > > Testing: local compilation > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9556 From tschatzl at openjdk.org Wed Jul 20 16:20:50 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 20 Jul 2022 16:20:50 GMT Subject: RFR: 8290533: Remove G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*,oop) In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 16:23:59 GMT, Sangheon Kim wrote: >> Hi all, >> >> please review this simple change to merge the `G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*, oop)` method with the other overload as this is its only use. >> >> Testing: local compilation >> >> Thanks, >> Thomas > > Looks good. Thanks @sangheon @kimbarrett for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/9556 From tschatzl at openjdk.org Wed Jul 20 16:20:50 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 20 Jul 2022 16:20:50 GMT Subject: Integrated: 8290533: Remove G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*,oop) In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 13:33:36 GMT, Thomas Schatzl wrote: > Hi all, > > please review this simple change to merge the `G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*, oop)` method with the other overload as this is its only use. > > Testing: local compilation > > Thanks, > Thomas This pull request has now been integrated. Changeset: eeb345a2 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/eeb345a286115213f8a75dfe54cdcc39dfca597a Stats: 7 lines in 2 files changed: 0 ins; 7 del; 0 mod 8290533: Remove G1ConcurrentMark::mark_in_bitmap(uint, HeapRegion*,oop) Reviewed-by: sangheki, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9556 From tschatzl at openjdk.org Wed Jul 20 16:23:18 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 20 Jul 2022 16:23:18 GMT Subject: RFR: 8253413: [REDO] [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs Message-ID: Hi all, can I have reviews for this change that fixes a bug in how young gen is calculating when G1 is using the region reserve already - in that case it does not bound the young gen by what is available any more, resulting in a guaranteed full gc (from the original change at [JDK-8244603](https://bugs.openjdk.org/browse/JDK-8244603). The reason for backing out and redoing this change already twice is not because of bugs by itself, but it triggered bugs which have been fixed in the meantime. For reference, the original review thread is [here](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2020-June/030062.html). Here's the text, a bit edited because I am not intending to immediately follow up with the uncommit during young gc changes: In particular, with this change the following issues two related issues are fixed: * 8238858: G1 Mixed gc young gen sizing might cause the first mixed gc to immediately follow the prepare mixed gc * 8244603: G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs These have been grouped together because it is too hard to separate them out as the bugs required significant rewrite in the young gen sizing. This results in G1 following GCTimeRatio much better than before, leading to less erratic heap expansion. That is, constant loads do not result in that much overcommit any more. Some background: At end of gc and when the remembered set sampling thread (re-)evaluates the young gen G1 calculates two values: - the *desired* (unconstrained) size of the young gen; desired/unconstrained meaning that these values are not limited by actually existing free regions. This value is interesting for adaptive IHOP so that it (better) converges to a fixed value. - the actual *target* size for the young gen, i.e. after taking constraints in available free regions into account, and whether we are currently already needing to use parts of the reserve or not. Some problems that were fixed with the current code: - there were some calculations to ensure that "at least one region will be allocated" every time g1 recalculates young gen but that really resulted in g1 increasing the young gen by at least one. You do not always want that, particularly since we regularly revise the young gen. What you want is a minimum desired *eden* size. - the desired and target young gen size calculation was done in a single huge method. This change splits up the code a bit. - the code that calculated the actual *target* young length has been very inconsistent in handling the reserve. I.e. the limit to the actually available free regions only applied in some cases, and notably not if you were already using the reserve, causing strange behavior where at least the calculated young gen target length was higher than available free regions. This could cause full gcs. - I added some detailed trace-level logging for the ergonomic decisions which really helps when debugging issues, but might be too large/intrusive for the code - I am not sure whether to leave it in. For reviewing I think the best entry point for this change is `G1Policy::update_young_list_target_length(size_t)` where the new code first calculates a desired young gen length and then target young length. - currently, and like before, MMU desired length overrides the pause time desired length. I.e. *if* a GCPauseTimeIntervalMillis is set, the spacing between gcs is more important than actual pause times. The difference is that now that there is an explicit comment about this behavior there :) - when eating into the reserve (last 10% of heap), we at most allow use of the sizer's min young length or half of the reserve regions (rounded up!), whichever is higher. This is an arbitrary decision, but since supposedly at that time we are already close to the next mixed gc due to adaptive ihop, so we can take more. - note that all this is about calculating a *target* length, not the actual length. Actual length may be higher e.g. due to gclocker. Testing: tier1-5, perf testing without differences Thanks, Thomas ------------- Commit messages: - Revert "8253411: [BACKOUT] [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs" Changes: https://git.openjdk.org/jdk/pull/9573/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9573&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8253413 Stats: 393 lines in 3 files changed: 196 ins; 80 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/9573.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9573/head:pull/9573 PR: https://git.openjdk.org/jdk/pull/9573 From tschatzl at openjdk.org Wed Jul 20 16:46:54 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 20 Jul 2022 16:46:54 GMT Subject: RFR: 8253413: [REDO] [REDO] G1 incorrectly limiting young gen size when using the reserve can result in repeated full gcs [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that fixes a bug in how young gen is calculating when G1 is using the region reserve already - in that case it does not bound the young gen by what is available any more, resulting in a guaranteed full gc (from the original change at [JDK-8244603](https://bugs.openjdk.org/browse/JDK-8244603). > > The reason for backing out and redoing this change already twice is not because of bugs by itself, but it triggered bugs which have been fixed in the meantime. > For reference, the original review thread is [here](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2020-June/030062.html). > > Here's the text, a bit edited because I am not intending to immediately follow up with the uncommit during young gc changes: > > In particular, with this change the following issues two related issues > are fixed: > > * 8238858: G1 Mixed gc young gen sizing might cause the first mixed gc > to immediately follow the prepare mixed gc > * 8244603: G1 incorrectly limiting young gen size when using the reserve > can result in repeated full gcs > > These have been grouped together because it is too hard to separate them > out as the bugs required significant rewrite in the young gen sizing. > > This results in G1 following GCTimeRatio much better than before, > leading to less erratic heap expansion. That is, constant loads do not > result in that much overcommit any more. > > Some background: > > At end of gc and when the remembered set sampling thread (re-)evaluates the young gen G1 calculates two values: > > - the *desired* (unconstrained) size of the young gen; desired/unconstrained meaning that these values are not limited by > actually existing free regions. This value is interesting for adaptive IHOP so that it (better) converges to a fixed value. > - the actual *target* size for the young gen, i.e. after taking constraints in available free regions into account, and whether we are > currently already needing to use parts of the reserve or not. > > Some problems that were fixed with the current code: > > - there were some calculations to ensure that "at least one region will be allocated" every time g1 recalculates young gen but that really resulted in g1 increasing the young gen by at least one. You do not always want that, particularly since we regularly revise the young gen. What you want is a minimum desired *eden* size. > - the desired and target young gen size calculation was done in a single huge method. This change splits up the code a bit. > - the code that calculated the actual *target* young length has been very inconsistent in handling the reserve. I.e. the limit to the > actually available free regions only applied in some cases, and notably not if you were already using the reserve, causing strange behavior where at least the calculated young gen target length was higher than available free regions. This could cause full gcs. > - I added some detailed trace-level logging for the ergonomic decisions which really helps when debugging issues, but might be too large/intrusive for the code - I am not sure whether to leave it in. > > For reviewing I think the best entry point for this change is `G1Policy::update_young_list_target_length(size_t)` where the new code first calculates a desired young gen length and then target young length. > > - currently, and like before, MMU desired length overrides the pause time desired length. I.e. *if* a GCPauseTimeIntervalMillis is set, the spacing between gcs is more important than actual pause times. The difference is that now that there is an explicit comment about this behavior there :) > - when eating into the reserve (last 10% of heap), we at most allow use of the sizer's min young length or half of the reserve regions (rounded up!), whichever is higher. This is an arbitrary decision, but since supposedly at that time we are already close to the next mixed gc due to adaptive ihop, so we can take more. > > - note that all this is about calculating a *target* length, not the actual length. Actual length may be higher e.g. due to gclocker. > > Testing: tier1-5, perf testing without differences > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: Minor whitespace fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9573/files - new: https://git.openjdk.org/jdk/pull/9573/files/a7deed34..337a6671 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9573&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9573&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9573.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9573/head:pull/9573 PR: https://git.openjdk.org/jdk/pull/9573 From lmesnik at openjdk.org Wed Jul 20 19:23:08 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Jul 2022 19:23:08 GMT Subject: Integrated: 8290468: Remove gc/gctests/mallocWithGC tests In-Reply-To: References: Message-ID: <2-2-7szGJt93xnq5yQApIoUwQiTa6_eX58cKWI9DEFE=.8b057287-6944-44d6-9ead-12b6caf8d150@github.com> On Tue, 19 Jul 2022 20:44:12 GMT, Leonid Mesnik wrote: > The gc/gctests/mallocWithGC tests test interaction of GC with malloc/free. > They are duplicates of vmTestbase/gc/lock/malloc/ tests. > Not sure that even vmTestbase/gc/lock/malloc/ are needed. GC do nothing with malloc/free and it doesn't make sense to test their interaction. This pull request has now been integrated. Changeset: b1817a30 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/b1817a30a00d74f70b247c783047bfbb49515dda Stats: 540 lines in 7 files changed: 0 ins; 540 del; 0 mod 8290468: Remove gc/gctests/mallocWithGC tests Reviewed-by: kbarrett, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/9563 From kbarrett at openjdk.org Thu Jul 21 06:25:48 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Jul 2022 06:25:48 GMT Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector In-Reply-To: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> Message-ID: On Tue, 19 Jul 2022 15:47:01 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read. > > Testing: tier1-3 > > Thanks, > Thomas Looks good. Just one minor formatting nit. src/hotspot/share/gc/g1/g1FullCollector.hpp line 93: > 91: G1FullGCHeapRegionAttr _region_attr_table; > 92: > 93: HeapWord*volatile *_compaction_tops; Spacing in the type is strange. `HeapWord* volatile* _compaction_tops;` is (I think) more usual for our code. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9560 From kbarrett at openjdk.org Thu Jul 21 06:40:11 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Jul 2022 06:40:11 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template. In-Reply-To: References: Message-ID: <0LDWxgnsMSD0UPmBcpaudRCi54mAVpH2ffBmMWkSFI4=.0ccd9218-48f8-42e9-afce-9930a96215bc@github.com> On Wed, 20 Jul 2022 15:00:52 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that removes the templates and casts around `G1CollectedHeap::heap_region_containing`? > > Testing: tier1-5 > > Thanks, > Thomas src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1129: > 1127: // Returns the HeapRegion that contains addr, or nullptr if that is an uncommitted > 1128: // region. addr must not be nullptr. > 1129: inline HeapRegion* heap_region_containing_or_null(HeapWord* addr) const; Why does `heap_region_containing` take `void*` but `heap_region_containing_or_null` takes `HeapWord*`. Seems like they should be the same (probably `void*` for both?). And why did the `const` qualifier get dropped for the or_null variant? ------------- PR: https://git.openjdk.org/jdk/pull/9572 From tschatzl at openjdk.org Thu Jul 21 07:42:03 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Jul 2022 07:42:03 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template. In-Reply-To: <0LDWxgnsMSD0UPmBcpaudRCi54mAVpH2ffBmMWkSFI4=.0ccd9218-48f8-42e9-afce-9930a96215bc@github.com> References: <0LDWxgnsMSD0UPmBcpaudRCi54mAVpH2ffBmMWkSFI4=.0ccd9218-48f8-42e9-afce-9930a96215bc@github.com> Message-ID: <7HFD6oz3PDksM2em03wZppXELs03mjgN39nGintfx9M=.411fbafd-bb16-46e4-96b3-121330f1f3a2@github.com> On Thu, 21 Jul 2022 06:26:57 GMT, Kim Barrett wrote: >> Hi all, >> >> can I have reviews for this change that removes the templates and casts around `G1CollectedHeap::heap_region_containing`? >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1129: > >> 1127: // Returns the HeapRegion that contains addr, or nullptr if that is an uncommitted >> 1128: // region. addr must not be nullptr. >> 1129: inline HeapRegion* heap_region_containing_or_null(HeapWord* addr) const; > > Why does `heap_region_containing` take `void*` but `heap_region_containing_or_null` takes `HeapWord*`. Seems like they should be the same (probably `void*` for both?). And why did the `const` qualifier get dropped for the or_null variant? `heap_region_containing_or_null` only needs the `HeapWord*` variant - I thought to specialize them as much as possible; dropping of the const has been unintenional. I will fix and regularize these two methods. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9572 From tschatzl at openjdk.org Thu Jul 21 08:00:01 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Jul 2022 08:00:01 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template. [v2] In-Reply-To: References: Message-ID: > Hi all, > > can I have reviews for this change that removes the templates and casts around `G1CollectedHeap::heap_region_containing`? > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9572/files - new: https://git.openjdk.org/jdk/pull/9572/files/75038fbe..dac1531f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9572&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9572&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9572.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9572/head:pull/9572 PR: https://git.openjdk.org/jdk/pull/9572 From tschatzl at openjdk.org Thu Jul 21 08:02:05 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Jul 2022 08:02:05 GMT Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector [v2] In-Reply-To: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> Message-ID: > Hi all, > > can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read. > > Testing: tier1-3 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: kbarrett review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9560/files - new: https://git.openjdk.org/jdk/pull/9560/files/16d264f6..57d69c14 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9560&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9560&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9560.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9560/head:pull/9560 PR: https://git.openjdk.org/jdk/pull/9560 From kbarrett at openjdk.org Thu Jul 21 11:18:04 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Jul 2022 11:18:04 GMT Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector [v2] In-Reply-To: References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> Message-ID: On Thu, 21 Jul 2022 08:02:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read. >> >> Testing: tier1-3 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9560 From kbarrett at openjdk.org Thu Jul 21 11:19:06 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 21 Jul 2022 11:19:06 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template. [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 08:00:01 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that removes the templates and casts around `G1CollectedHeap::heap_region_containing`? >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9572 From tschatzl at openjdk.org Thu Jul 21 12:00:37 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Jul 2022 12:00:37 GMT Subject: RFR: 8290806: Only add eager reclaim task to G1PostEvacuateCollectionSetCleanupTask2 if there were candidates Message-ID: Hi all, can I have reviews for this tiny optimization that does not enqueue the eager reclaim task if there were no eager reclaim candidates? This saves an iteration over all heap regions in applications that do not allocate humongous type arrays. Testing: gha, gc/g1 Thanks, Thomas ------------- Commit messages: - Initial version Changes: https://git.openjdk.org/jdk/pull/9590/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9590&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290806 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9590.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9590/head:pull/9590 PR: https://git.openjdk.org/jdk/pull/9590 From tschatzl at openjdk.org Thu Jul 21 14:47:33 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 21 Jul 2022 14:47:33 GMT Subject: RFR: 8290814: Hide G1RootRegions behind G1ConcurrentMark Message-ID: <8XH46F5P_iwKwD-xvcAg59oiCFtYrZ6NKAWRkKeIIf8=.353d4a19-ff1f-4fd2-bafe-5d295914af25@github.com> Hi all, please review this cleanup that better encapsulates the `G1RootRegions` member of `G1ConcurrentMark` to be not directly accessible by non-concurrent mark related code. This is a preparatory change for [JDK-8289822](https://bugs.openjdk.org/browse/JDK-8289822) in that since the TAMSes are then owned by `G1ConcurrentMark`, there is the possibility to avoid allowing write access to these to non-G1ConcurrentMark classes as well. [here](https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:submit/8289822-move-tams?expand=1) you can see how that change could look like (also includes [JDK-8290357](https://bugs.openjdk.org/browse/JDK-8290357) that is also out for review). Testing: tier1-3 Thanks, Thomas ------------- Commit messages: - initial version Changes: https://git.openjdk.org/jdk/pull/9593/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9593&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290814 Stats: 37 lines in 4 files changed: 24 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9593.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9593/head:pull/9593 PR: https://git.openjdk.org/jdk/pull/9593 From tschatzl at openjdk.org Fri Jul 22 10:55:11 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 22 Jul 2022 10:55:11 GMT Subject: [jdk19] RFR: 8290867: Race freeing remembered set segments Message-ID: Hi all, please review this fix for a crash due to a race in remembered set segment deallocation. Here is the description (provided by chaeubl as reported): - Thread A executes `G1SegmentedArray::create_new_segment` and tries to pop an element from the `_free_segment_list`. For that, thread A executes `LockFreeStack::pop()` - Thread A reads `LockFreeStack::top()` - Thread B executes `LockFreeStack::pop()`, also reads `LockFreeStack::top()` and pops that element from the stack - Thread B executes `Atomic::cmpxchg(&_first, prev, next);` in `G1SegmentedArray::create_new_segment` but it fails because another thread already registered a different segment - Thread B calls `G1SegmentedArraySegment::delete_segment` and frees the value - Thread A tries to access `top()->next` in `LockFreeStack::pop()`, which causes a segfault because `top()` was freed by thread B The fix is to delay the deletion of that memory segment until all readers (i.e. in `G1SegmentedArrayFreeList::get` calling `_list.pop()`) drop the references to that memory segment. The readers are already guarded by a `CriticalSection`. Testing: tier1-5 running, reproducer that adds extra delays that significantly delays to widen the opportunity this race can occur passes on BigRAMTester Thanks, Thomas ------------- Commit messages: - initial version Changes: https://git.openjdk.org/jdk19/pull/152/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=152&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290867 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk19/pull/152.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/152/head:pull/152 PR: https://git.openjdk.org/jdk19/pull/152 From kbarrett at openjdk.org Fri Jul 22 21:46:03 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 22 Jul 2022 21:46:03 GMT Subject: [jdk19] RFR: 8290867: Race freeing remembered set segments In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 10:43:19 GMT, Thomas Schatzl wrote: > Hi all, > > please review this fix for a crash due to a race in remembered set segment deallocation. Here is the description (provided by chaeubl as reported): > > - Thread A executes `G1SegmentedArray::create_new_segment` and tries to pop an element from the `_free_segment_list`. For that, thread A executes `LockFreeStack::pop()` > - Thread A reads `LockFreeStack::top()` > - Thread B executes `LockFreeStack::pop()`, also reads `LockFreeStack::top()` and pops that element from the stack > - Thread B executes `Atomic::cmpxchg(&_first, prev, next);` in `G1SegmentedArray::create_new_segment` but it fails because another thread already registered a different segment > - Thread B calls `G1SegmentedArraySegment::delete_segment` and frees the value > - Thread A tries to access `top()->next` in `LockFreeStack::pop()`, which causes a segfault because `top()` was freed by thread B > > The fix is to delay the deletion of that memory segment until all readers (i.e. in `G1SegmentedArrayFreeList::get` calling `_list.pop()`) drop the references to that memory segment. The readers are already guarded by a `CriticalSection`. > > Testing: tier1-5 running, reproducer that adds extra delays that significantly delays to widen the opportunity this race can occur passes on BigRAMTester (otherwise crashes in a few seconds) > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk19/pull/152 From duke at openjdk.org Mon Jul 25 09:37:38 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 25 Jul 2022 09:37:38 GMT Subject: RFR: 8290459: Remove unused GCCause enums Message-ID: 8290459: Remove unused GCCause enums ------------- Commit messages: - Merge branch 'JDK-8290459' of github.com:xmas92/jdk into JDK-8290459 - Remove unused GCCause enums - Remove unused GCCause enums Changes: https://git.openjdk.org/jdk/pull/9614/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9614&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290459 Stats: 19 lines in 2 files changed: 0 ins; 18 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9614.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9614/head:pull/9614 PR: https://git.openjdk.org/jdk/pull/9614 From tschatzl at openjdk.org Mon Jul 25 10:02:58 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Jul 2022 10:02:58 GMT Subject: RFR: 8290459: Remove unused GCCause enums In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 12:32:20 GMT, Axel Boldt-Christmas wrote: > 8290459: Remove unused GCCause enums Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9614 From kbarrett at openjdk.org Mon Jul 25 10:52:50 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Jul 2022 10:52:50 GMT Subject: RFR: 8290459: Remove unused GCCause enums In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 12:32:20 GMT, Axel Boldt-Christmas wrote: > 8290459: Remove unused GCCause enums Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9614 From kbarrett at openjdk.org Mon Jul 25 11:01:19 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Jul 2022 11:01:19 GMT Subject: RFR: 8290959: Consistently use "grey" instead of "gray" in GC code Message-ID: <21IL4ohaB3_EKGu_rSFmV10PjzKuJOHSnpx97maViSI=.2825b411-5a11-49ec-9fc3-c5f6f6343a5c@github.com> Please review this trivial spelling change in some comments to make them consistent with the spelling in identifier names. ------------- Commit messages: - change spelling Changes: https://git.openjdk.org/jdk/pull/9625/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9625&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290959 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/9625.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9625/head:pull/9625 PR: https://git.openjdk.org/jdk/pull/9625 From duke at openjdk.org Mon Jul 25 11:08:06 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Mon, 25 Jul 2022 11:08:06 GMT Subject: Integrated: 8290459: Remove unused GCCause enums In-Reply-To: References: Message-ID: On Fri, 22 Jul 2022 12:32:20 GMT, Axel Boldt-Christmas wrote: > 8290459: Remove unused GCCause enums This pull request has now been integrated. Changeset: 350808a5 Author: Axel Boldt-Christmas Committer: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/350808a5a3cbaa097c3360bfca9af6d90f1b223b Stats: 19 lines in 2 files changed: 0 ins; 18 del; 1 mod 8290459: Remove unused GCCause enums Reviewed-by: tschatzl, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9614 From tschatzl at openjdk.org Mon Jul 25 11:11:51 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Mon, 25 Jul 2022 11:11:51 GMT Subject: RFR: 8290959: Consistently use "grey" instead of "gray" in GC code In-Reply-To: <21IL4ohaB3_EKGu_rSFmV10PjzKuJOHSnpx97maViSI=.2825b411-5a11-49ec-9fc3-c5f6f6343a5c@github.com> References: <21IL4ohaB3_EKGu_rSFmV10PjzKuJOHSnpx97maViSI=.2825b411-5a11-49ec-9fc3-c5f6f6343a5c@github.com> Message-ID: On Mon, 25 Jul 2022 10:53:52 GMT, Kim Barrett wrote: > Please review this trivial spelling change in some comments to make them > consistent with the spelling in identifier names. Looks good and trivial. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9625 From kbarrett at openjdk.org Mon Jul 25 12:26:25 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Jul 2022 12:26:25 GMT Subject: RFR: 8290959: Consistently use "grey" instead of "gray" in GC code In-Reply-To: References: <21IL4ohaB3_EKGu_rSFmV10PjzKuJOHSnpx97maViSI=.2825b411-5a11-49ec-9fc3-c5f6f6343a5c@github.com> Message-ID: On Mon, 25 Jul 2022 11:08:49 GMT, Thomas Schatzl wrote: >> Please review this trivial spelling change in some comments to make them >> consistent with the spelling in identifier names. > > Looks good and trivial. Thanks for reviewing @tschatzl . ------------- PR: https://git.openjdk.org/jdk/pull/9625 From kbarrett at openjdk.org Mon Jul 25 12:30:06 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Jul 2022 12:30:06 GMT Subject: Integrated: 8290959: Consistently use "grey" instead of "gray" in GC code In-Reply-To: <21IL4ohaB3_EKGu_rSFmV10PjzKuJOHSnpx97maViSI=.2825b411-5a11-49ec-9fc3-c5f6f6343a5c@github.com> References: <21IL4ohaB3_EKGu_rSFmV10PjzKuJOHSnpx97maViSI=.2825b411-5a11-49ec-9fc3-c5f6f6343a5c@github.com> Message-ID: On Mon, 25 Jul 2022 10:53:52 GMT, Kim Barrett wrote: > Please review this trivial spelling change in some comments to make them > consistent with the spelling in identifier names. This pull request has now been integrated. Changeset: b17269ad Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/b17269ad522f05717b84356c885de24c5368447e Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8290959: Consistently use "grey" instead of "gray" in GC code Reviewed-by: tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/9625 From kbarrett at openjdk.org Mon Jul 25 12:31:12 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 25 Jul 2022 12:31:12 GMT Subject: RFR: 8290806: Only add eager reclaim task to G1 post evacuate tasks if there were candidates In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 11:53:40 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this tiny optimization that does not enqueue the eager reclaim task if there were no eager reclaim candidates? This saves an iteration over all heap regions in applications that do not allocate humongous type arrays. > > Testing: gha, gc/g1 > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9590 From rsunderbabu at openjdk.org Mon Jul 25 16:16:25 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Mon, 25 Jul 2022 16:16:25 GMT Subject: RFR: 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 Message-ID: LoadUnloadGC2 tests the Class unloading during GC. In order to trigger the GC, lots of memory is created at a short interval. Instead of GC getting triggered, the test quickly gets into OOME. Using WhiteBox.fullGC is a cleaner and deterministic way to trigger GC. ------------- Commit messages: - 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 Changes: https://git.openjdk.org/jdk/pull/9628/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9628&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282642 Stats: 8 lines in 1 file changed: 3 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9628.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9628/head:pull/9628 PR: https://git.openjdk.org/jdk/pull/9628 From lmesnik at openjdk.org Tue Jul 26 01:54:49 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 26 Jul 2022 01:54:49 GMT Subject: RFR: 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 In-Reply-To: References: Message-ID: On Mon, 25 Jul 2022 16:09:27 GMT, Ramkumar Sunderbabu wrote: > LoadUnloadGC2 tests the Class unloading during GC. In order to trigger the GC, lots of memory is created at a short interval. Instead of GC getting triggered, the test quickly gets into OOME. > Using WhiteBox.fullGC is a cleaner and deterministic way to trigger GC. test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java line 56: > 54: while (stresser.iteration()) { > 55: log.info("Iteration: " + stresser.getIteration()); > 56: WhiteBox.getWhiteBox().fullGC(); We need to create some classes to unload them. Are they created? ------------- PR: https://git.openjdk.org/jdk/pull/9628 From rsunderbabu at openjdk.org Tue Jul 26 08:52:51 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Tue, 26 Jul 2022 08:52:51 GMT Subject: RFR: 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 [v2] In-Reply-To: References: Message-ID: > LoadUnloadGC2 tests the Class unloading during GC. In order to trigger the GC, lots of memory is created at a short interval. Instead of GC getting triggered, the test quickly gets into OOME. > Using WhiteBox.fullGC is a cleaner and deterministic way to trigger GC. Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9628/files - new: https://git.openjdk.org/jdk/pull/9628/files/f3b9121d..18447296 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9628&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9628&range=00-01 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9628.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9628/head:pull/9628 PR: https://git.openjdk.org/jdk/pull/9628 From rsunderbabu at openjdk.org Tue Jul 26 08:52:51 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Tue, 26 Jul 2022 08:52:51 GMT Subject: RFR: 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 [v2] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 01:49:23 GMT, Leonid Mesnik wrote: >> Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 > > test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java line 56: > >> 54: while (stresser.iteration()) { >> 55: log.info("Iteration: " + stresser.getIteration()); >> 56: WhiteBox.getWhiteBox().fullGC(); > > We need to create some classes to unload them. Are they created? I missed that part. I will correct it. ------------- PR: https://git.openjdk.org/jdk/pull/9628 From sangheki at openjdk.org Tue Jul 26 13:19:09 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Tue, 26 Jul 2022 13:19:09 GMT Subject: RFR: 8290806: Only add eager reclaim task to G1 post evacuate tasks if there were candidates In-Reply-To: References: Message-ID: <_54Zy_0dVvSywkmjAVTafD1GHV6K5ETkV2TYka3Xu08=.a8023c73-b1d9-46d6-ae29-44060e55fd1f@github.com> On Thu, 21 Jul 2022 11:53:40 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this tiny optimization that does not enqueue the eager reclaim task if there were no eager reclaim candidates? This saves an iteration over all heap regions in applications that do not allocate humongous type arrays. > > Testing: gha, gc/g1 > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by sangheki (Reviewer). PR: https://git.openjdk.org/jdk/pull/9590 From tschatzl at openjdk.org Tue Jul 26 13:32:28 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Jul 2022 13:32:28 GMT Subject: RFR: 8290806: Only add eager reclaim task to G1 post evacuate tasks if there were candidates In-Reply-To: References: Message-ID: <-6P7Wr5UYIvUjqJkB4uqvKEPw_UhXoHDG4yN_uDdiRA=.e1e28fd9-b00f-44b1-aa86-52211b85d025@github.com> On Mon, 25 Jul 2022 12:28:05 GMT, Kim Barrett wrote: >> Hi all, >> >> can I have reviews for this tiny optimization that does not enqueue the eager reclaim task if there were no eager reclaim candidates? This saves an iteration over all heap regions in applications that do not allocate humongous type arrays. >> >> Testing: gha, gc/g1 >> >> Thanks, >> Thomas > > Looks good. Thanks @kimbarrett @sangheon for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9590 From tschatzl at openjdk.org Tue Jul 26 13:32:29 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Jul 2022 13:32:29 GMT Subject: Integrated: 8290806: Only add eager reclaim task to G1 post evacuate tasks if there were candidates In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 11:53:40 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this tiny optimization that does not enqueue the eager reclaim task if there were no eager reclaim candidates? This saves an iteration over all heap regions in applications that do not allocate humongous type arrays. > > Testing: gha, gc/g1 > > Thanks, > Thomas This pull request has now been integrated. Changeset: da9cc5c9 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/da9cc5c9f48280786af7939f50c38eb7054e70c9 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8290806: Only add eager reclaim task to G1 post evacuate tasks if there were candidates Reviewed-by: kbarrett, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/9590 From tschatzl at openjdk.org Tue Jul 26 15:56:30 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Jul 2022 15:56:30 GMT Subject: RFR: 8291037: Move PLAB resizing mechanism to G1EvacStats Message-ID: Hi all, please review this refactoring that moves the PLAB resizing mechanism to `G1EvacStats` as G1 is the only user for this functionality. The change is split into two commits for easier review: 65eef6482cc0a995d29e822c9c26063bb42c7679 only moves the code, 028e3adeca1d496520f0c79f3b4bcedd7e7f0f15 tries to improve it a bit. Note that this change also removes the old, unused PLAB re-sizing algorithm previously used by CMS, hence the relatively large count of deleted LOC. Testing: gha, gc/g1 Thanks, Thomas ------------- Commit messages: - touch-up - Code motion Changes: https://git.openjdk.org/jdk/pull/9644/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9644&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291037 Stats: 190 lines in 6 files changed: 67 ins; 100 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/9644.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9644/head:pull/9644 PR: https://git.openjdk.org/jdk/pull/9644 From tschatzl at openjdk.org Tue Jul 26 16:05:57 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 26 Jul 2022 16:05:57 GMT Subject: RFR: 8291037: Move PLAB resizing mechanism to G1EvacStats [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this refactoring that moves the PLAB resizing mechanism to `G1EvacStats` as G1 is the only user for this functionality. > > The change is split into two commits for easier review: 65eef6482cc0a995d29e822c9c26063bb42c7679 only moves the code, 028e3adeca1d496520f0c79f3b4bcedd7e7f0f15 tries to improve it a bit. > > Note that this change also removes the old, unused PLAB re-sizing algorithm previously used by CMS, hence the relatively large count of deleted LOC. > > Testing: gha, gc/g1 > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: improve one comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9644/files - new: https://git.openjdk.org/jdk/pull/9644/files/028e3ade..0f8bc696 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9644&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9644&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9644.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9644/head:pull/9644 PR: https://git.openjdk.org/jdk/pull/9644 From rsunderbabu at openjdk.org Tue Jul 26 16:25:53 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Tue, 26 Jul 2022 16:25:53 GMT Subject: RFR: 8282651: ZGC: vmTestbase/gc/ArrayJuggle/ tests fails intermittently with exit code 97 Message-ID: Fixing JuggleTests for OOME. The JuggleTests continuously allocate memory and juggle them in various array positions. Over the course of allocation, heap might be fully filled, esp in high memory strategy. The test doesn't take into account OOME and run under the assumption that any freed memory would be immediately GCed. Immediate GC under memory stress is not guaranteed. Hence it is better to explicitly call WhiteBox API to do the job. ------------- Commit messages: - 8282651: ZGC: vmTestbase/gc/ArrayJuggle/ tests fails intermittently with exit code 97 Changes: https://git.openjdk.org/jdk/pull/9645/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9645&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282651 Stats: 159 lines in 34 files changed: 98 ins; 0 del; 61 mod Patch: https://git.openjdk.org/jdk/pull/9645.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9645/head:pull/9645 PR: https://git.openjdk.org/jdk/pull/9645 From lmesnik at openjdk.org Tue Jul 26 18:25:50 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 26 Jul 2022 18:25:50 GMT Subject: RFR: 8282651: ZGC: vmTestbase/gc/ArrayJuggle/ tests fails intermittently with exit code 97 In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 16:18:30 GMT, Ramkumar Sunderbabu wrote: > Fixing JuggleTests for OOME. > The JuggleTests continuously allocate memory and juggle them in various array positions. Over the course of allocation, heap might be fully filled, esp in high memory strategy. The test doesn't take into account OOME and run under the assumption that any freed memory would be immediately GCed. Immediate GC under memory stress is not guaranteed. Hence it is better to explicitly call WhiteBox API to do the job. Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle/Juggle01/Juggle01.java line 62: > 60: try { > 61: array[index] = garbageProducer.create(objectSize); > 62: } catch (OutOfMemoryError e) { OOME is thrown only when GC is unable to free enough memory. The test doesn't fill the whole heap and doesn't expect OOME. I think it is better to add -Xlog:gc=debug:gc.log, -XX:+HeapDumpOnOutOfMemoryError and might be -XX:+CrashOnOutOfMemoryError. to get more information about heap state when OOME happens Also, you could just reduce memory load by huge arrays ------------- PR: https://git.openjdk.org/jdk/pull/9645 From zgu at openjdk.org Tue Jul 26 19:34:47 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Tue, 26 Jul 2022 19:34:47 GMT Subject: RFR: 8291056: Remove unused Generation::par_promote*() Message-ID: Please review this trivial cleanup to remove unused Generation::par_promote() and Generation::par_promote_alloc_done() methods. ------------- Commit messages: - Removed unused par_promote_xxx methods Changes: https://git.openjdk.org/jdk/pull/9648/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9648&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291056 Stats: 21 lines in 2 files changed: 0 ins; 21 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9648.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9648/head:pull/9648 PR: https://git.openjdk.org/jdk/pull/9648 From lmesnik at openjdk.org Wed Jul 27 02:07:11 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 27 Jul 2022 02:07:11 GMT Subject: RFR: 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 [v2] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 08:52:51 GMT, Ramkumar Sunderbabu wrote: >> LoadUnloadGC2 tests the Class unloading during GC. In order to trigger the GC, lots of memory is created at a short interval. Instead of GC getting triggered, the test quickly gets into OOME. >> Using WhiteBox.fullGC is a cleaner and deterministic way to trigger GC. > > Ramkumar Sunderbabu has updated the pull request incrementally with one additional commit since the last revision: > > 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 Looks good, please verify that it works with ZGC, ParallelGC, SerialGC. ------------- Marked as reviewed by lmesnik (Reviewer). PR: https://git.openjdk.org/jdk/pull/9628 From sangheki at openjdk.org Wed Jul 27 02:37:20 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Wed, 27 Jul 2022 02:37:20 GMT Subject: RFR: 8291037: Move PLAB resizing mechanism to G1EvacStats [v2] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 16:05:57 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this refactoring that moves the PLAB resizing mechanism to `G1EvacStats` as G1 is the only user for this functionality. >> >> The change is split into two commits for easier review: 65eef6482cc0a995d29e822c9c26063bb42c7679 only moves the code, 028e3adeca1d496520f0c79f3b4bcedd7e7f0f15 tries to improve it a bit. >> >> Note that this change also removes the old, unused PLAB re-sizing algorithm previously used by CMS, hence the relatively large count of deleted LOC. >> >> Testing: gha, gc/g1 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > improve one comment Lgtm. ------------- Marked as reviewed by sangheki (Reviewer). PR: https://git.openjdk.org/jdk/pull/9644 From kbarrett at openjdk.org Wed Jul 27 05:39:03 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 27 Jul 2022 05:39:03 GMT Subject: RFR: 8291056: Remove unused Generation::par_promote*() In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 19:26:27 GMT, Zhengyu Gu wrote: > Please review this trivial cleanup to remove unused Generation::par_promote() and Generation::par_promote_alloc_done() methods. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9648 From eosterlund at openjdk.org Wed Jul 27 07:11:09 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 27 Jul 2022 07:11:09 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant due to it can not be modified In-Reply-To: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: On Thu, 21 Jul 2022 02:17:33 GMT, Leslie Zhai wrote: > Hi, > > When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: > > > const size_t ZPlatformGranuleSizeShift = 24; // 16MB > > // Granule shift/size > const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; > > // Page size shifts > const size_t ZPageSizeSmallShift = ZGranuleSizeShift; > > // Page sizes > const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; > > > `zBitField` failed to work: > > > Internal Error > (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 > # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) > > > Perhaps `mask` also need to be adjusted: > > > static size_t object_index(oop obj) { > const uintptr_t addr = ZOop::to_address(obj); > const uintptr_t offset = ZAddress::offset(addr); > const uintptr_t mask = ZGranuleSize - 1; > return (offset & mask) >> ZObjectAlignmentSmallShift; > } > > > Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. > > Please review my patch. > > Thanks, > Leslie Zhai I have many comments. But before diving into that - what is the actual problem that you are trying to solve? Do you have an AArch64 CPU that does not support 2M large pages, but does support 16M large pages? ------------- PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Wed Jul 27 07:39:46 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Wed, 27 Jul 2022 07:39:46 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant due to it can not be modified In-Reply-To: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: On Thu, 21 Jul 2022 02:17:33 GMT, Leslie Zhai wrote: > Hi, > > When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: > > > const size_t ZPlatformGranuleSizeShift = 24; // 16MB > > // Granule shift/size > const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; > > // Page size shifts > const size_t ZPageSizeSmallShift = ZGranuleSizeShift; > > // Page sizes > const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; > > > `zBitField` failed to work: > > > Internal Error > (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 > # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) > > > Perhaps `mask` also need to be adjusted: > > > static size_t object_index(oop obj) { > const uintptr_t addr = ZOop::to_address(obj); > const uintptr_t offset = ZAddress::offset(addr); > const uintptr_t mask = ZGranuleSize - 1; > return (offset & mask) >> ZObjectAlignmentSmallShift; > } > > > Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. > > Please review my patch. > > Thanks, > Leslie Zhai Hi Erik, Thanks for your response! > Do you have an AArch64 CPU that does not support 2M large pages, but does support 16M large pages? Yup: ./build/linux-aarch64-server-fastdebug/images/jdk/bin/java -Xlog:gc*=debug -XX:+UseZGC -version [0.007s][debug][gc,heap] Minimum heap 16777216 Initial heap 2147483648 Maximum heap 32178700288 [0.007s][info ][gc,init] Initializing The Z Garbage Collector [0.007s][info ][gc,init] Version: 20-internal-adhoc.root.jdk (fastdebug) [0.007s][info ][gc,init] Probing address space for the highest valid bit: 47 [0.007s][info ][gc,init] NUMA Support: Enabled [0.007s][info ][gc,init] NUMA Nodes: 4 [0.007s][info ][gc,init] CPUs: 96 total, 96 available [0.007s][info ][gc,init] Memory: 292969M [0.007s][info ][gc,init] Large Page Support: Disabled [0.007s][info ][gc,init] GC Workers: 24 (dynamic) [0.009s][info ][gc,init] Address Space Type: Contiguous/Unrestricted/Complete [0.009s][info ][gc,init] Address Space Size: 491008M x 3 = 1473024M [0.009s][info ][gc,init] Heap Backing File: /memfd:java_heap [0.009s][info ][gc,init] Heap Backing Filesystem: tmpfs (0x1021994) [0.009s][info ][gc,init] Min Capacity: 16M [0.009s][info ][gc,init] Initial Capacity: 2048M [0.009s][info ][gc,init] Max Capacity: 30688M [0.009s][info ][gc,init] Medium Page Size: 256M [0.009s][info ][gc,init] Pre-touch: Disabled [0.009s][info ][gc,init] Available space on backing filesystem: N/A [0.009s][info ][gc,init] Uncommit: Enabled [0.009s][info ][gc,init] Uncommit Delay: 300s [0.036s][debug][gc,marking] Expanding mark stack space: 0M->32M [0.036s][info ][gc,init ] Runtime Workers: 38 [0.039s][info ][gc ] Using The Z Garbage Collector [0.039s][info ][gc,metaspace] CDS archive(s) mapped at: [0x0000000800000000-0x0000000800cf0000-0x0000000800cf0000), size 13565952, SharedBaseAddress: 0x0000000800000000, ArchiveRelocationMode: 0. [0.039s][info ][gc,metaspace] Compressed class space mapped at: 0x0000000801000000-0x0000000841000000, reserved size: 1073741824 [0.039s][info ][gc,metaspace] Narrow klass base: 0x0000000800000000, Narrow klass shift: 0, Narrow klass range: 0x100000000 [0.088s][debug][gc,heap ] Uncommit Timeout: 301s [0.094s][debug][gc,nmethod ] Rebuilding NMethod Table: 0->1024 entries, 0(0%->0%) registered, 0(0%->0%) unregistered openjdk version "20-internal" 2023-03-21 OpenJDK Runtime Environment (fastdebug build 20-internal-adhoc.root.jdk) OpenJDK 64-Bit Server VM (fastdebug build 20-internal-adhoc.root.jdk, mixed mode, sharing) [0.132s][info ][gc,heap,exit] Heap [0.132s][info ][gc,heap,exit] ZHeap used 16M, capacity 2048M, max capacity 30688M [0.132s][info ][gc,heap,exit] Metaspace used 130K, committed 256K, reserved 1114112K [0.132s][info ][gc,heap,exit] class space used 2K, committed 64K, reserved 1048576K Created file descriptor successfully, see goto `Heap Backing File` line indicated from above xlog: int ZPhysicalMemoryBacking::create_mem_fd(const char* name) const { #ifdef AARCH64 assert(ZGranuleSize == 16 * M, "Granule size must match MFD_HUGE_16MB"); #else assert(ZGranuleSize == 2 * M, "Granule size must match MFD_HUGE_2MB"); #endif // Create file name char filename[PATH_MAX]; snprintf(filename, sizeof(filename), "%s%s", name, ZLargePages::is_explicit() ? ".hugetlb" : ""); // Create file #ifdef AARCH64 const int extra_flags = ZLargePages::is_explicit() ? (MFD_HUGETLB | MFD_HUGE_16MB) : 0; #else const int extra_flags = ZLargePages::is_explicit() ? (MFD_HUGETLB | MFD_HUGE_2MB) : 0; #endif const int fd = ZSyscall::memfd_create(filename, MFD_CLOEXEC | extra_flags); if (fd == -1) { ZErrno err; log_debug_p(gc, init)("Failed to create memfd file (%s)", (ZLargePages::is_explicit() && (err == EINVAL || err == ENODEV)) ? "Hugepages (2M) not available" : err.to_string()); return -1; } => log_info_p(gc, init)("Heap Backing File: /memfd:%s", filename); return fd; } > what is the actual problem that you are trying to solve? Back to the topic: I just want to remove the `ZPlatformGranuleSizeShift` from cpu backends. And I will update the patch about AArch64 debugging part. Thanks, Leslie Zhai ------------- PR: https://git.openjdk.org/jdk/pull/9582 From eosterlund at openjdk.org Wed Jul 27 08:13:02 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 27 Jul 2022 08:13:02 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant due to it can not be modified In-Reply-To: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: <2hCDQK-6DoA9zsSvHR_UyvjOI2PcBeWy6nxeSrO7JdM=.01092caf-58a0-4853-a111-90aa53e89ca8@github.com> On Thu, 21 Jul 2022 02:17:33 GMT, Leslie Zhai wrote: > Hi, > > When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: > > > const size_t ZPlatformGranuleSizeShift = 24; // 16MB > > // Granule shift/size > const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; > > // Page size shifts > const size_t ZPageSizeSmallShift = ZGranuleSizeShift; > > // Page sizes > const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; > > > `zBitField` failed to work: > > > Internal Error > (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 > # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) > > > Perhaps `mask` also need to be adjusted: > > > static size_t object_index(oop obj) { > const uintptr_t addr = ZOop::to_address(obj); > const uintptr_t offset = ZAddress::offset(addr); > const uintptr_t mask = ZGranuleSize - 1; > return (offset & mask) >> ZObjectAlignmentSmallShift; > } > > > Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. > > Please review my patch. > > Thanks, > Leslie Zhai Okay please update your patch so I can see what changes you are actually proposing to integrate. ------------- PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Wed Jul 27 08:33:04 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Wed, 27 Jul 2022 08:33:04 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant due to it can not be modified [v2] In-Reply-To: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: <30CT6vngfr7KMc4jwt_F51C9_BzK9eRigAFjVOBpbMk=.797ec2fa-0cb6-4c46-b8d8-b6873b590ab3@github.com> > Hi, > > When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: > > > const size_t ZPlatformGranuleSizeShift = 24; // 16MB > > // Granule shift/size > const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; > > // Page size shifts > const size_t ZPageSizeSmallShift = ZGranuleSizeShift; > > // Page sizes > const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; > > > `zBitField` failed to work: > > > Internal Error > (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 > # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) > > > Perhaps `mask` also need to be adjusted: > > > static size_t object_index(oop obj) { > const uintptr_t addr = ZOop::to_address(obj); > const uintptr_t offset = ZAddress::offset(addr); > const uintptr_t mask = ZGranuleSize - 1; > return (offset & mask) >> ZObjectAlignmentSmallShift; > } > > > Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. > > Please review my patch. > > Thanks, > Leslie Zhai Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: 8291106: ZPlatformGranuleSizeShift is redundant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9582/files - new: https://git.openjdk.org/jdk/pull/9582/files/66c4e70a..78085135 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9582&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9582&range=00-01 Stats: 16 lines in 3 files changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9582.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9582/head:pull/9582 PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Wed Jul 27 08:37:31 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Wed, 27 Jul 2022 08:37:31 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant due to it can not be modified [v3] In-Reply-To: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> > Hi, > > When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: > > > const size_t ZPlatformGranuleSizeShift = 24; // 16MB > > // Granule shift/size > const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; > > // Page size shifts > const size_t ZPageSizeSmallShift = ZGranuleSizeShift; > > // Page sizes > const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; > > > `zBitField` failed to work: > > > Internal Error > (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 > # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) > > > Perhaps `mask` also need to be adjusted: > > > static size_t object_index(oop obj) { > const uintptr_t addr = ZOop::to_address(obj); > const uintptr_t offset = ZAddress::offset(addr); > const uintptr_t mask = ZGranuleSize - 1; > return (offset & mask) >> ZObjectAlignmentSmallShift; > } > > > Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. > > Please review my patch. > > Thanks, > Leslie Zhai Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: 8291106: ZPlatformGranuleSizeShift is redundant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9582/files - new: https://git.openjdk.org/jdk/pull/9582/files/78085135..cf6032ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9582&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9582&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9582.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9582/head:pull/9582 PR: https://git.openjdk.org/jdk/pull/9582 From eosterlund at openjdk.org Wed Jul 27 08:44:17 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 27 Jul 2022 08:44:17 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v3] In-Reply-To: <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> Message-ID: On Wed, 27 Jul 2022 08:37:31 GMT, Leslie Zhai wrote: >> Hi, >> >> When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: >> >> >> const size_t ZPlatformGranuleSizeShift = 24; // 16MB >> >> // Granule shift/size >> const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; >> >> // Page size shifts >> const size_t ZPageSizeSmallShift = ZGranuleSizeShift; >> >> // Page sizes >> const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; >> >> >> `zBitField` failed to work: >> >> >> Internal Error >> (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 >> # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value >> # >> # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) >> >> >> Perhaps `mask` also need to be adjusted: >> >> >> static size_t object_index(oop obj) { >> const uintptr_t addr = ZOop::to_address(obj); >> const uintptr_t offset = ZAddress::offset(addr); >> const uintptr_t mask = ZGranuleSize - 1; >> return (offset & mask) >> ZObjectAlignmentSmallShift; >> } >> >> >> Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. >> >> Please review my patch. >> >> Thanks, >> Leslie Zhai > > Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: > > 8291106: ZPlatformGranuleSizeShift is redundant Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Wed Jul 27 08:44:17 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Wed, 27 Jul 2022 08:44:17 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v3] In-Reply-To: <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> Message-ID: On Wed, 27 Jul 2022 08:37:31 GMT, Leslie Zhai wrote: >> Hi, >> >> When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: >> >> >> const size_t ZPlatformGranuleSizeShift = 24; // 16MB >> >> // Granule shift/size >> const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; >> >> // Page size shifts >> const size_t ZPageSizeSmallShift = ZGranuleSizeShift; >> >> // Page sizes >> const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; >> >> >> `zBitField` failed to work: >> >> >> Internal Error >> (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 >> # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value >> # >> # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) >> >> >> Perhaps `mask` also need to be adjusted: >> >> >> static size_t object_index(oop obj) { >> const uintptr_t addr = ZOop::to_address(obj); >> const uintptr_t offset = ZAddress::offset(addr); >> const uintptr_t mask = ZGranuleSize - 1; >> return (offset & mask) >> ZObjectAlignmentSmallShift; >> } >> >> >> Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. >> >> Please review my patch. >> >> Thanks, >> Leslie Zhai > > Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: > > 8291106: ZPlatformGranuleSizeShift is redundant Hi Erik, Please review it again. Thanks, Leslie Zhai Hi Erik, Thanks for your review. Cheers, Leslie Zhai ------------- PR: https://git.openjdk.org/jdk/pull/9582 From jiefu at openjdk.org Wed Jul 27 08:52:04 2022 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 27 Jul 2022 08:52:04 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v3] In-Reply-To: <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> Message-ID: <-K71YW4d7w0lqmFkkFp-4AVgnXtPgMahpnIVVHqM4pA=.1b14f89b-a38e-43e3-b5dc-b013aed5998e@github.com> On Wed, 27 Jul 2022 08:37:31 GMT, Leslie Zhai wrote: >> Hi, >> >> When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: >> >> >> const size_t ZPlatformGranuleSizeShift = 24; // 16MB >> >> // Granule shift/size >> const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; >> >> // Page size shifts >> const size_t ZPageSizeSmallShift = ZGranuleSizeShift; >> >> // Page sizes >> const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; >> >> >> `zBitField` failed to work: >> >> >> Internal Error >> (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 >> # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value >> # >> # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) >> >> >> Perhaps `mask` also need to be adjusted: >> >> >> static size_t object_index(oop obj) { >> const uintptr_t addr = ZOop::to_address(obj); >> const uintptr_t offset = ZAddress::offset(addr); >> const uintptr_t mask = ZGranuleSize - 1; >> return (offset & mask) >> ZObjectAlignmentSmallShift; >> } >> >> >> Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. >> >> Please review my patch. >> >> Thanks, >> Leslie Zhai > > Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: > > 8291106: ZPlatformGranuleSizeShift is redundant Maybe, we should also update the copyright year? ------------- PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Wed Jul 27 08:55:02 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Wed, 27 Jul 2022 08:55:02 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v4] In-Reply-To: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: > Hi, > > When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: > > > const size_t ZPlatformGranuleSizeShift = 24; // 16MB > > // Granule shift/size > const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; > > // Page size shifts > const size_t ZPageSizeSmallShift = ZGranuleSizeShift; > > // Page sizes > const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; > > > `zBitField` failed to work: > > > Internal Error > (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 > # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) > > > Perhaps `mask` also need to be adjusted: > > > static size_t object_index(oop obj) { > const uintptr_t addr = ZOop::to_address(obj); > const uintptr_t offset = ZAddress::offset(addr); > const uintptr_t mask = ZGranuleSize - 1; > return (offset & mask) >> ZObjectAlignmentSmallShift; > } > > > Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. > > Please review my patch. > > Thanks, > Leslie Zhai Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: 8291106: ZPlatformGranuleSizeShift is redundant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9582/files - new: https://git.openjdk.org/jdk/pull/9582/files/cf6032ce..62b3f871 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9582&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9582&range=02-03 Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9582.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9582/head:pull/9582 PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Wed Jul 27 08:56:14 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Wed, 27 Jul 2022 08:56:14 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v3] In-Reply-To: <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> <5Epoo-68w3FLpR4I8JqhHa9yKWWqccjW7po8vc6P8Zw=.9ba1ac30-d97f-4c50-b1a1-5da716cc6216@github.com> Message-ID: On Wed, 27 Jul 2022 08:37:31 GMT, Leslie Zhai wrote: >> Hi, >> >> When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: >> >> >> const size_t ZPlatformGranuleSizeShift = 24; // 16MB >> >> // Granule shift/size >> const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; >> >> // Page size shifts >> const size_t ZPageSizeSmallShift = ZGranuleSizeShift; >> >> // Page sizes >> const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; >> >> >> `zBitField` failed to work: >> >> >> Internal Error >> (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 >> # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value >> # >> # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) >> >> >> Perhaps `mask` also need to be adjusted: >> >> >> static size_t object_index(oop obj) { >> const uintptr_t addr = ZOop::to_address(obj); >> const uintptr_t offset = ZAddress::offset(addr); >> const uintptr_t mask = ZGranuleSize - 1; >> return (offset & mask) >> ZObjectAlignmentSmallShift; >> } >> >> >> Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. >> >> Please review my patch. >> >> Thanks, >> Leslie Zhai > > Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: > > 8291106: ZPlatformGranuleSizeShift is redundant Hi Jie Fu, Thanks for your hint! Please review it again. Miss you, Leslie Zhai ------------- PR: https://git.openjdk.org/jdk/pull/9582 From jiefu at openjdk.org Wed Jul 27 09:09:36 2022 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 27 Jul 2022 09:09:36 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v4] In-Reply-To: References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: On Wed, 27 Jul 2022 08:55:02 GMT, Leslie Zhai wrote: >> Hi, >> >> When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: >> >> >> const size_t ZPlatformGranuleSizeShift = 24; // 16MB >> >> // Granule shift/size >> const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; >> >> // Page size shifts >> const size_t ZPageSizeSmallShift = ZGranuleSizeShift; >> >> // Page sizes >> const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; >> >> >> `zBitField` failed to work: >> >> >> Internal Error >> (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 >> # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value >> # >> # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) >> >> >> Perhaps `mask` also need to be adjusted: >> >> >> static size_t object_index(oop obj) { >> const uintptr_t addr = ZOop::to_address(obj); >> const uintptr_t offset = ZAddress::offset(addr); >> const uintptr_t mask = ZGranuleSize - 1; >> return (offset & mask) >> ZObjectAlignmentSmallShift; >> } >> >> >> Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. >> >> Please review my patch. >> >> Thanks, >> Leslie Zhai > > Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: > > 8291106: ZPlatformGranuleSizeShift is redundant src/hotspot/cpu/riscv/gc/z/zGlobals_riscv.hpp line 2: > 1: /* > 2: * Copyright (c) 2015, 2019, Oracle and/or its affiliates. All rights reserved. I think we'd better modify the copyright year of Oracle's. ------------- PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Wed Jul 27 09:18:09 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Wed, 27 Jul 2022 09:18:09 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v5] In-Reply-To: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: > Hi, > > When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: > > > const size_t ZPlatformGranuleSizeShift = 24; // 16MB > > // Granule shift/size > const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; > > // Page size shifts > const size_t ZPageSizeSmallShift = ZGranuleSizeShift; > > // Page sizes > const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; > > > `zBitField` failed to work: > > > Internal Error > (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 > # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) > > > Perhaps `mask` also need to be adjusted: > > > static size_t object_index(oop obj) { > const uintptr_t addr = ZOop::to_address(obj); > const uintptr_t offset = ZAddress::offset(addr); > const uintptr_t mask = ZGranuleSize - 1; > return (offset & mask) >> ZObjectAlignmentSmallShift; > } > > > Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. > > Please review my patch. > > Thanks, > Leslie Zhai Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: 8291106: ZPlatformGranuleSizeShift is redundant ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9582/files - new: https://git.openjdk.org/jdk/pull/9582/files/62b3f871..a8c3d671 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9582&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9582&range=03-04 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9582.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9582/head:pull/9582 PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Wed Jul 27 09:18:12 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Wed, 27 Jul 2022 09:18:12 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v4] In-Reply-To: References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: On Wed, 27 Jul 2022 09:07:01 GMT, Jie Fu wrote: >> Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: >> >> 8291106: ZPlatformGranuleSizeShift is redundant > > src/hotspot/cpu/riscv/gc/z/zGlobals_riscv.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2015, 2019, Oracle and/or its affiliates. All rights reserved. > > I think we'd better modify the copyright year of Oracle's. Done. ------------- PR: https://git.openjdk.org/jdk/pull/9582 From eosterlund at openjdk.org Wed Jul 27 12:53:10 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 27 Jul 2022 12:53:10 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v5] In-Reply-To: References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: <9B5zHeZYZHKJ_pFB6ace9sYfqwvIkEGv3qWShnDYB2I=.fdf023b8-cb54-4569-9e55-ba73ae518b1a@github.com> On Wed, 27 Jul 2022 09:18:09 GMT, Leslie Zhai wrote: >> Hi, >> >> When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: >> >> >> const size_t ZPlatformGranuleSizeShift = 24; // 16MB >> >> // Granule shift/size >> const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; >> >> // Page size shifts >> const size_t ZPageSizeSmallShift = ZGranuleSizeShift; >> >> // Page sizes >> const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; >> >> >> `zBitField` failed to work: >> >> >> Internal Error >> (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 >> # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value >> # >> # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) >> >> >> Perhaps `mask` also need to be adjusted: >> >> >> static size_t object_index(oop obj) { >> const uintptr_t addr = ZOop::to_address(obj); >> const uintptr_t offset = ZAddress::offset(addr); >> const uintptr_t mask = ZGranuleSize - 1; >> return (offset & mask) >> ZObjectAlignmentSmallShift; >> } >> >> >> Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. >> >> Please review my patch. >> >> Thanks, >> Leslie Zhai > > Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: > > 8291106: ZPlatformGranuleSizeShift is redundant Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9582 From zgu at openjdk.org Wed Jul 27 12:55:29 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 27 Jul 2022 12:55:29 GMT Subject: RFR: 8291056: Remove unused Generation::par_promote*() In-Reply-To: References: Message-ID: <8_r-aK6_7AUrJwB-q9HR6Hxy0rEYgwOve3UQ1VZzaj4=.79c5892e-39a6-49b5-ba0c-4d80a91ea009@github.com> On Wed, 27 Jul 2022 05:35:01 GMT, Kim Barrett wrote: >> Please review this trivial cleanup to remove unused Generation::par_promote() and Generation::par_promote_alloc_done() methods. > > Looks good, and trivial. Thanks, @kimbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9648 From zgu at openjdk.org Wed Jul 27 12:55:32 2022 From: zgu at openjdk.org (Zhengyu Gu) Date: Wed, 27 Jul 2022 12:55:32 GMT Subject: Integrated: 8291056: Remove unused Generation::par_promote*() In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 19:26:27 GMT, Zhengyu Gu wrote: > Please review this trivial cleanup to remove unused Generation::par_promote() and Generation::par_promote_alloc_done() methods. This pull request has now been integrated. Changeset: adaf3b90 Author: Zhengyu Gu URL: https://git.openjdk.org/jdk/commit/adaf3b9014d7bca95b5cbe34f0cbe04b43c6b49d Stats: 21 lines in 2 files changed: 0 ins; 21 del; 0 mod 8291056: Remove unused Generation::par_promote*() Reviewed-by: kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/9648 From tschatzl at openjdk.org Wed Jul 27 12:58:35 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Jul 2022 12:58:35 GMT Subject: Integrated: 8291289: gc/TestPLABAdaptToMinTLABSize fails after JDK-8289137 Message-ID: <-ubWjIwS31nA4z-bNFsfJzCK7gOsVD2s_Sm1dTbLx7M=.fcb9e8fd-cee3-4749-8b03-af31c02cd80c@github.com> Hi all, can I get reviews for this change to the gc/TestPLABAdaptToMinTLABSize test to only let Parallel GC and G1 run the test as they are the only ones that use `Young/OldPLABSize` that is tested here? The constraint function for these flags on other collectors always succeeds, so the failure tests with invalid options fail there. Testing: local testing of all collectors, only Parallel and G1 succesfully complete them now Thanks, Thomas ------------- Commit messages: - Only execute test on parallel and g1 Changes: https://git.openjdk.org/jdk/pull/9654/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9654&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291289 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9654.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9654/head:pull/9654 PR: https://git.openjdk.org/jdk/pull/9654 From shade at openjdk.org Wed Jul 27 12:58:36 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 27 Jul 2022 12:58:36 GMT Subject: Integrated: 8291289: gc/TestPLABAdaptToMinTLABSize fails after JDK-8289137 In-Reply-To: <-ubWjIwS31nA4z-bNFsfJzCK7gOsVD2s_Sm1dTbLx7M=.fcb9e8fd-cee3-4749-8b03-af31c02cd80c@github.com> References: <-ubWjIwS31nA4z-bNFsfJzCK7gOsVD2s_Sm1dTbLx7M=.fcb9e8fd-cee3-4749-8b03-af31c02cd80c@github.com> Message-ID: On Wed, 27 Jul 2022 12:21:27 GMT, Thomas Schatzl wrote: > Hi all, > > can I get reviews for this change to the gc/TestPLABAdaptToMinTLABSize test to only let Parallel GC and G1 run the test as they are the only ones that use `Young/OldPLABSize` that is tested here? > The constraint function for these flags on other collectors always succeeds, so the failure tests with invalid options fail there. > > Testing: local testing of all collectors, only Parallel and G1 succesfully complete them now > > Thanks, > Thomas Looks fine! Yes, this is trivial. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.org/jdk/pull/9654 From tschatzl at openjdk.org Wed Jul 27 12:58:37 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Jul 2022 12:58:37 GMT Subject: Integrated: 8291289: gc/TestPLABAdaptToMinTLABSize fails after JDK-8289137 In-Reply-To: References: <-ubWjIwS31nA4z-bNFsfJzCK7gOsVD2s_Sm1dTbLx7M=.fcb9e8fd-cee3-4749-8b03-af31c02cd80c@github.com> Message-ID: On Wed, 27 Jul 2022 12:31:32 GMT, Aleksey Shipilev wrote: >> Hi all, >> >> can I get reviews for this change to the gc/TestPLABAdaptToMinTLABSize test to only let Parallel GC and G1 run the test as they are the only ones that use `Young/OldPLABSize` that is tested here? >> The constraint function for these flags on other collectors always succeeds, so the failure tests with invalid options fail there. >> >> Testing: local testing of all collectors, only Parallel and G1 succesfully complete them now >> >> Thanks, >> Thomas > > Looks fine! Thanks @shipilev , I'll push right away as trivial to reduce the noise in CI. Thanks, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/9654 From tschatzl at openjdk.org Wed Jul 27 12:58:39 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Jul 2022 12:58:39 GMT Subject: Integrated: 8291289: gc/TestPLABAdaptToMinTLABSize fails after JDK-8289137 In-Reply-To: <-ubWjIwS31nA4z-bNFsfJzCK7gOsVD2s_Sm1dTbLx7M=.fcb9e8fd-cee3-4749-8b03-af31c02cd80c@github.com> References: <-ubWjIwS31nA4z-bNFsfJzCK7gOsVD2s_Sm1dTbLx7M=.fcb9e8fd-cee3-4749-8b03-af31c02cd80c@github.com> Message-ID: On Wed, 27 Jul 2022 12:21:27 GMT, Thomas Schatzl wrote: > Hi all, > > can I get reviews for this change to the gc/TestPLABAdaptToMinTLABSize test to only let Parallel GC and G1 run the test as they are the only ones that use `Young/OldPLABSize` that is tested here? > The constraint function for these flags on other collectors always succeeds, so the failure tests with invalid options fail there. > > Testing: local testing of all collectors, only Parallel and G1 succesfully complete them now > > Thanks, > Thomas This pull request has now been integrated. Changeset: e804236f Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/e804236f05ff8f7bf941dcbc26284474d2cbc67b Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8291289: gc/TestPLABAdaptToMinTLABSize fails after JDK-8289137 Reviewed-by: shade ------------- PR: https://git.openjdk.org/jdk/pull/9654 From rsunderbabu at openjdk.org Wed Jul 27 15:42:50 2022 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Wed, 27 Jul 2022 15:42:50 GMT Subject: RFR: 8282642: vmTestbase/gc/gctests/LoadUnloadGC2/LoadUnloadGC2.java fails intermittently with exit code 1 [v2] In-Reply-To: References: Message-ID: <43ilTHNpJLnKzEUBDoAzTj2bit8supg1R7_A0akxBJ4=.79cf179d-da96-4fdc-95c1-42830d5373ec@github.com> On Wed, 27 Jul 2022 02:03:47 GMT, Leonid Mesnik wrote: > Looks good, please verify that it works with ZGC, ParallelGC, SerialGC. @lmesnik I have tested with all the GC options. ------------- PR: https://git.openjdk.org/jdk/pull/9628 From duke at openjdk.org Wed Jul 27 18:11:33 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Wed, 27 Jul 2022 18:11:33 GMT Subject: RFR: 8282729: Serial: Move BOT implementation to collector specific directory Message-ID: <7AqN4rWBdS4MXP0DToGpzOq5ofmZdsCDjKOgyb7-YlI=.614daef8-6c39-4880-a003-6db02f246c55@github.com> Moves serial code from `share/gc/shared/blockOffsetTable.*` to `share/gc/serial/serialBlockOffsetTable.*` Move required fixing up some missing header files. Refactoring tries to respect `INCLUDE_SERIALGC` without changing any behaviour. Given that `--disable-jvm-feature-serialgc` will not build before this change, it will not build afterwards either. However it does now compile, but will fail to link. The diff below is enough to for `make hotspot` to run (on `macosx-aarch64`), but it will not build the complete JDK as the build system will use the compiled binaries with `-XX:+UseSerialGC` which obviously won't work as that GC is missing. diff --git a/src/hotspot/share/gc/shared/genCollectedHeap.cpp b/src/hotspot/share/gc/shared/genCollectedHeap.cpp index 5558f1a4a32..79b465b3e0a 100644 --- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp +++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp @@ -31,7 +31,6 @@ #include "code/icBuffer.hpp" #include "compiler/oopMap.hpp" #include "gc/serial/defNewGeneration.hpp" -#include "gc/serial/markSweep.hpp" #include "gc/shared/adaptiveSizePolicy.hpp" #include "gc/shared/cardTableBarrierSet.hpp" #include "gc/shared/cardTableRS.hpp" @@ -80,6 +79,9 @@ #if INCLUDE_JVMCI #include "jvmci/jvmci.hpp" #endif +#if INCLUDE_SERIALGC +#include "gc/serial/markSweep.hpp" +#endif GenCollectedHeap::GenCollectedHeap(Generation::Name young, Generation::Name old, @@ -204,9 +206,9 @@ void GenCollectedHeap::post_initialize() { initialize_size_policy(def_new_gen->eden()->capacity(), _old_gen->capacity(), def_new_gen->from()->capacity()); - +#if INCLUDE_SERIALGC MarkSweep::initialize(); - +#endif ScavengableNMethods::initialize(&_is_scavengable); } diff --git a/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp b/test/hotspot/gtest/gc/shared/test_collect orPolicy.cpp index dfe096248c7..30a24fd9232 100644 --- a/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp +++ b/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp @@ -31,6 +31,7 @@ #include "utilities/macros.hpp" #include "unittest.hpp" +#if INCLUDE_SERIALGC class TestGenCollectorPolicy { public: @@ -279,3 +280,4 @@ TEST_OTHER_VM(CollectorPolicy, old_cmd) { TestGenCollectorPolicy::TestWrapper::test(&setter_old_size, &setter_max_new_size, &checker_large); } +#endif There is still a lot of Serial only code in the shared code base. The `share/gc/shared/space.*` is a clear next candidate for refactoring as this change required a bunch of code in there to depend on `INCLUDE_SERIALGC` to build. Testing: Tier 1 ------------- Commit messages: - 8282729: Serial: Move BOT implementation to collector specific directory Changes: https://git.openjdk.org/jdk/pull/9662/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9662&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282729 Stats: 1018 lines in 23 files changed: 73 ins; 909 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/9662.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9662/head:pull/9662 PR: https://git.openjdk.org/jdk/pull/9662 From sangheki at openjdk.org Wed Jul 27 19:25:38 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Wed, 27 Jul 2022 19:25:38 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 08:00:01 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that removes the templates and casts around `G1CollectedHeap::heap_region_containing`? >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp line 108: > 106: } > 107: > 108: inline HeapRegion* G1CollectedHeap::heap_region_containing_or_null(HeapWord* addr) const { Why 2 asserts are removed? Because the only caller has already checked such things? ------------- PR: https://git.openjdk.org/jdk/pull/9572 From tschatzl at openjdk.org Wed Jul 27 19:25:39 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Jul 2022 19:25:39 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template [v2] In-Reply-To: References: Message-ID: On Tue, 26 Jul 2022 21:37:26 GMT, Sangheon Kim wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett review > > src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp line 108: > >> 106: } >> 107: >> 108: inline HeapRegion* G1CollectedHeap::heap_region_containing_or_null(HeapWord* addr) const { > > Why 2 asserts are removed? > Because the only caller has already checked such things? The `addr_to_region` call in this method already checks whether the given address is in the heap and `nullptr` is always outside the heap, so redundant anyway. ------------- PR: https://git.openjdk.org/jdk/pull/9572 From sangheki at openjdk.org Wed Jul 27 20:01:42 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Wed, 27 Jul 2022 20:01:42 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template [v2] In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 08:00:01 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that removes the templates and casts around `G1CollectedHeap::heap_region_containing`? >> >> Testing: tier1-5 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review Looks good. ------------- Marked as reviewed by sangheki (Reviewer). PR: https://git.openjdk.org/jdk/pull/9572 From tschatzl at openjdk.org Wed Jul 27 20:06:42 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Jul 2022 20:06:42 GMT Subject: RFR: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template [v2] In-Reply-To: References: Message-ID: On Wed, 27 Jul 2022 19:59:35 GMT, Sangheon Kim wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett review > > Looks good. Thanks @sangheon @kimbarrett for your reviews ------------- PR: https://git.openjdk.org/jdk/pull/9572 From tschatzl at openjdk.org Wed Jul 27 20:08:46 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Jul 2022 20:08:46 GMT Subject: Integrated: 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template In-Reply-To: References: Message-ID: On Wed, 20 Jul 2022 15:00:52 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that removes the templates and casts around `G1CollectedHeap::heap_region_containing`? > > Testing: tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 37b08c7b Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/37b08c7bf9f76a5a984bf266614dfd105dc6c055 Stats: 35 lines in 10 files changed: 0 ins; 10 del; 25 mod 8237913: G1CollectedHeap::heap_region_containing shouldn't be a template Reviewed-by: kbarrett, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/9572 From tschatzl at openjdk.org Wed Jul 27 20:17:39 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 27 Jul 2022 20:17:39 GMT Subject: RFR: 8290715: Fix incorrect uses of G1CollectedHeap::heap_region_containing() [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that fixes some callers of `G1CollectedHeap::heap_region_containing` to a) fail on trying to get the `Heapregion*` on uncommitted regions and b) change some callers to use the correct `heap_region_containing_or_null` method that had been intended there. > > Also remove some now unneccessary asserts as `heap_region_containing` will fail when it previously returned `nullptr`. > > Testing: tier1-5 > > Thanks, > Thomas Thomas Schatzl 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9584/files - new: https://git.openjdk.org/jdk/pull/9584/files/b6afb444..b6afb444 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9584&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9584&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9584.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9584/head:pull/9584 PR: https://git.openjdk.org/jdk/pull/9584 From kbarrett at openjdk.org Thu Jul 28 00:07:37 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 28 Jul 2022 00:07:37 GMT Subject: RFR: 8287555: Tighten G1 G1BlockOffsetTable::block_start() code [v8] In-Reply-To: References: Message-ID: On Tue, 12 Jul 2022 16:52:22 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 > > Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: > > - Remove change > - Merge branch 'master' into pull/9059 > - Merge branch 'master' into pull/9059 > - Refactoring > - Improve merge, remove unneeded declarations > - Merge branch 'master' into pull/9059 > - 828755:5 Tighten G1BlockOffsetTable::block_start() code > > initial version > > Cleanup > - Make block_start_reaching_into_card() const > - initial version Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9059 From jiefu at openjdk.org Thu Jul 28 08:58:39 2022 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 28 Jul 2022 08:58:39 GMT Subject: RFR: 8291106: ZPlatformGranuleSizeShift is redundant [v5] In-Reply-To: References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: On Wed, 27 Jul 2022 09:18:09 GMT, Leslie Zhai wrote: >> Hi, >> >> When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: >> >> >> const size_t ZPlatformGranuleSizeShift = 24; // 16MB >> >> // Granule shift/size >> const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; >> >> // Page size shifts >> const size_t ZPageSizeSmallShift = ZGranuleSizeShift; >> >> // Page sizes >> const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; >> >> >> `zBitField` failed to work: >> >> >> Internal Error >> (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 >> # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value >> # >> # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) >> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) >> >> >> Perhaps `mask` also need to be adjusted: >> >> >> static size_t object_index(oop obj) { >> const uintptr_t addr = ZOop::to_address(obj); >> const uintptr_t offset = ZAddress::offset(addr); >> const uintptr_t mask = ZGranuleSize - 1; >> return (offset & mask) >> ZObjectAlignmentSmallShift; >> } >> >> >> Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. >> >> Please review my patch. >> >> Thanks, >> Leslie Zhai > > Leslie Zhai has updated the pull request incrementally with one additional commit since the last revision: > > 8291106: ZPlatformGranuleSizeShift is redundant Marked as reviewed by jiefu (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9582 From lzhai at openjdk.org Thu Jul 28 09:02:01 2022 From: lzhai at openjdk.org (Leslie Zhai) Date: Thu, 28 Jul 2022 09:02:01 GMT Subject: Integrated: 8291106: ZPlatformGranuleSizeShift is redundant In-Reply-To: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> References: <_FnzZYPNYxiAi9jAUQWdAxJA6opZCl1aItEC2gP2OtI=.6d3d4a78-0195-43f0-bf50-e1bec728c9da@github.com> Message-ID: On Thu, 21 Jul 2022 02:17:33 GMT, Leslie Zhai wrote: > Hi, > > When I am tunning `ZPageSizeSmall` to 16 MB from 2MB: > > > const size_t ZPlatformGranuleSizeShift = 24; // 16MB > > // Granule shift/size > const size_t ZGranuleSizeShift = ZPlatformGranuleSizeShift; > > // Page size shifts > const size_t ZPageSizeSmallShift = ZGranuleSizeShift; > > // Page sizes > const size_t ZPageSizeSmall = (size_t)1 << ZPageSizeSmallShift; > > > `zBitField` failed to work: > > > Internal Error > (/home/zhaixiang/jdk/src/hotspot/share/gc/z/zBitField.hpp:76), pid=923047, tid=923069 > # assert(((ContainerType)value & (FieldMask << ValueShift)) == (ContainerType)value) failed: Invalid value > # > # JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.root.jdk) > # Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.root.jdk, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-aarch64) > > > Perhaps `mask` also need to be adjusted: > > > static size_t object_index(oop obj) { > const uintptr_t addr = ZOop::to_address(obj); > const uintptr_t offset = ZAddress::offset(addr); > const uintptr_t mask = ZGranuleSize - 1; > return (offset & mask) >> ZObjectAlignmentSmallShift; > } > > > Back to the point: ZPlatformGranuleSizeShift is redundant due to it can not be modified, for example, `24`, so I removed the `ZPlatformGranuleSizeShift` from cpu backends, just keep it for debugging AArch64 to see the issue. > > Please review my patch. > > Thanks, > Leslie Zhai This pull request has now been integrated. Changeset: 97fc8deb Author: Leslie Zhai Committer: Jie Fu URL: https://git.openjdk.org/jdk/commit/97fc8deb1db6deb5f841d64f5e8e3b825783a680 Stats: 10 lines in 5 files changed: 0 ins; 4 del; 6 mod 8291106: ZPlatformGranuleSizeShift is redundant Reviewed-by: eosterlund, jiefu ------------- PR: https://git.openjdk.org/jdk/pull/9582 From tschatzl at openjdk.org Thu Jul 28 10:00:21 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Jul 2022 10:00:21 GMT Subject: RFR: 8282729: Serial: Move BOT implementation to collector specific directory In-Reply-To: <7AqN4rWBdS4MXP0DToGpzOq5ofmZdsCDjKOgyb7-YlI=.614daef8-6c39-4880-a003-6db02f246c55@github.com> References: <7AqN4rWBdS4MXP0DToGpzOq5ofmZdsCDjKOgyb7-YlI=.614daef8-6c39-4880-a003-6db02f246c55@github.com> Message-ID: On Wed, 27 Jul 2022 18:04:36 GMT, Axel Boldt-Christmas wrote: > Moves serial code from `share/gc/shared/blockOffsetTable.*` to `share/gc/serial/serialBlockOffsetTable.*` > Move required fixing up some missing header files. > Refactoring tries to respect `INCLUDE_SERIALGC` without changing any behaviour. > > Given that `--disable-jvm-feature-serialgc` will not build before this change, it will not build afterwards either. However it does now compile, but will fail to link. > > The diff below is enough to for `make hotspot` to run (on `macosx-aarch64`), but it will not build the complete JDK as the build system will use the compiled binaries with `-XX:+UseSerialGC` which obviously won't work as that GC is missing. > > diff --git a/src/hotspot/share/gc/shared/genCollectedHeap.cpp b/src/hotspot/share/gc/shared/genCollectedHeap.cpp > index 5558f1a4a32..79b465b3e0a 100644 > --- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp > +++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp > @@ -31,7 +31,6 @@ > #include "code/icBuffer.hpp" > #include "compiler/oopMap.hpp" > #include "gc/serial/defNewGeneration.hpp" > -#include "gc/serial/markSweep.hpp" > #include "gc/shared/adaptiveSizePolicy.hpp" > #include "gc/shared/cardTableBarrierSet.hpp" > #include "gc/shared/cardTableRS.hpp" > @@ -80,6 +79,9 @@ > #if INCLUDE_JVMCI > #include "jvmci/jvmci.hpp" > #endif > +#if INCLUDE_SERIALGC > +#include "gc/serial/markSweep.hpp" > +#endif > > GenCollectedHeap::GenCollectedHeap(Generation::Name young, > Generation::Name old, > @@ -204,9 +206,9 @@ void GenCollectedHeap::post_initialize() { > initialize_size_policy(def_new_gen->eden()->capacity(), > _old_gen->capacity(), > def_new_gen->from()->capacity()); > - > +#if INCLUDE_SERIALGC > MarkSweep::initialize(); > - > +#endif > ScavengableNMethods::initialize(&_is_scavengable); > } > > diff --git a/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp b/test/hotspot/gtest/gc/shared/test_collect > orPolicy.cpp > index dfe096248c7..30a24fd9232 100644 > --- a/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp > +++ b/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp > @@ -31,6 +31,7 @@ > #include "utilities/macros.hpp" > #include "unittest.hpp" > > +#if INCLUDE_SERIALGC > class TestGenCollectorPolicy { > public: > > @@ -279,3 +280,4 @@ TEST_OTHER_VM(CollectorPolicy, old_cmd) { > > TestGenCollectorPolicy::TestWrapper::test(&setter_old_size, &setter_max_new_size, &checker_large); > } > +#endif > > > There is still a lot of Serial only code in the shared code base. The `share/gc/shared/space.*` is a clear next candidate for refactoring as this change required a bunch of code in there to depend on `INCLUDE_SERIALGC` to build. > > Testing: Tier 1 Can you check tier4/tier5, which includes the serviceability tests after these changes (just do tier1-5 to be safe). Looks good apart from this request to rerun testing. ------------- Changes requested by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9662 From tschatzl at openjdk.org Thu Jul 28 10:15:41 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 28 Jul 2022 10:15:41 GMT Subject: RFR: 8290715: Fix incorrect uses of G1CollectedHeap::heap_region_containing() [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that fixes some callers of `G1CollectedHeap::heap_region_containing` to a) fail on trying to get the `Heapregion*` on uncommitted regions and b) change some callers to use the correct `heap_region_containing_or_null` method that had been intended there. > > Also remove some now unneccessary asserts as `heap_region_containing` will fail when it previously returned `nullptr`. > > Testing: tier1-5 > > 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 11 commits: - Merge branch 'master' into 8290715-heapregion-containing-no-null - Some more removal of unnecessary checks - Initial changes - Fix the places where the wrong heap_region_containing() method has been used - kbarrett review - Remove some more casts - Revert changes to heap_region_containing() - Remove cast - Remove unnecessary changes - some changes - ... and 1 more: https://git.openjdk.org/jdk/compare/97fc8deb...5dc2fc08 ------------- Changes: https://git.openjdk.org/jdk/pull/9584/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9584&range=02 Stats: 23 lines in 5 files changed: 1 ins; 8 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/9584.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9584/head:pull/9584 PR: https://git.openjdk.org/jdk/pull/9584 From kbarrett at openjdk.org Thu Jul 28 20:08:45 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 28 Jul 2022 20:08:45 GMT Subject: RFR: 8290715: Fix incorrect uses of G1CollectedHeap::heap_region_containing() [v3] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 10:15:41 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that fixes some callers of `G1CollectedHeap::heap_region_containing` to a) fail on trying to get the `Heapregion*` on uncommitted regions and b) change some callers to use the correct `heap_region_containing_or_null` method that had been intended there. >> >> Also remove some now unneccessary asserts as `heap_region_containing` will fail when it previously returned `nullptr`. >> >> Testing: tier1-5 >> >> 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 11 commits: > > - Merge branch 'master' into 8290715-heapregion-containing-no-null > - Some more removal of unnecessary checks > - Initial changes > - Fix the places where the wrong heap_region_containing() method has been used > - kbarrett review > - Remove some more casts > - Revert changes to heap_region_containing() > - Remove cast > - Remove unnecessary changes > - some changes > - ... and 1 more: https://git.openjdk.org/jdk/compare/97fc8deb...5dc2fc08 Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/9584 From sangheki at openjdk.org Thu Jul 28 21:11:34 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Thu, 28 Jul 2022 21:11:34 GMT Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector [v2] In-Reply-To: References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> Message-ID: On Thu, 21 Jul 2022 08:02:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read. >> >> Testing: tier1-3 >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > kbarrett review Looks good. ------------- Marked as reviewed by sangheki (Reviewer). PR: https://git.openjdk.org/jdk/pull/9560 From duke at openjdk.org Fri Jul 29 07:22:32 2022 From: duke at openjdk.org (Axel Boldt-Christmas) Date: Fri, 29 Jul 2022 07:22:32 GMT Subject: RFR: 8282729: Serial: Move BOT implementation to collector specific directory In-Reply-To: <7AqN4rWBdS4MXP0DToGpzOq5ofmZdsCDjKOgyb7-YlI=.614daef8-6c39-4880-a003-6db02f246c55@github.com> References: <7AqN4rWBdS4MXP0DToGpzOq5ofmZdsCDjKOgyb7-YlI=.614daef8-6c39-4880-a003-6db02f246c55@github.com> Message-ID: On Wed, 27 Jul 2022 18:04:36 GMT, Axel Boldt-Christmas wrote: > Moves serial code from `share/gc/shared/blockOffsetTable.*` to `share/gc/serial/serialBlockOffsetTable.*` > Move required fixing up some missing header files. > Refactoring tries to respect `INCLUDE_SERIALGC` without changing any behaviour. > > Given that `--disable-jvm-feature-serialgc` will not build before this change, it will not build afterwards either. However it does now compile, but will fail to link. > > The diff below is enough to for `make hotspot` to run (on `macosx-aarch64`), but it will not build the complete JDK as the build system will use the compiled binaries with `-XX:+UseSerialGC` which obviously won't work as that GC is missing. > > diff --git a/src/hotspot/share/gc/shared/genCollectedHeap.cpp b/src/hotspot/share/gc/shared/genCollectedHeap.cpp > index 5558f1a4a32..79b465b3e0a 100644 > --- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp > +++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp > @@ -31,7 +31,6 @@ > #include "code/icBuffer.hpp" > #include "compiler/oopMap.hpp" > #include "gc/serial/defNewGeneration.hpp" > -#include "gc/serial/markSweep.hpp" > #include "gc/shared/adaptiveSizePolicy.hpp" > #include "gc/shared/cardTableBarrierSet.hpp" > #include "gc/shared/cardTableRS.hpp" > @@ -80,6 +79,9 @@ > #if INCLUDE_JVMCI > #include "jvmci/jvmci.hpp" > #endif > +#if INCLUDE_SERIALGC > +#include "gc/serial/markSweep.hpp" > +#endif > > GenCollectedHeap::GenCollectedHeap(Generation::Name young, > Generation::Name old, > @@ -204,9 +206,9 @@ void GenCollectedHeap::post_initialize() { > initialize_size_policy(def_new_gen->eden()->capacity(), > _old_gen->capacity(), > def_new_gen->from()->capacity()); > - > +#if INCLUDE_SERIALGC > MarkSweep::initialize(); > - > +#endif > ScavengableNMethods::initialize(&_is_scavengable); > } > > diff --git a/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp b/test/hotspot/gtest/gc/shared/test_collect > orPolicy.cpp > index dfe096248c7..30a24fd9232 100644 > --- a/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp > +++ b/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp > @@ -31,6 +31,7 @@ > #include "utilities/macros.hpp" > #include "unittest.hpp" > > +#if INCLUDE_SERIALGC > class TestGenCollectorPolicy { > public: > > @@ -279,3 +280,4 @@ TEST_OTHER_VM(CollectorPolicy, old_cmd) { > > TestGenCollectorPolicy::TestWrapper::test(&setter_old_size, &setter_max_new_size, &checker_large); > } > +#endif > > > There is still a lot of Serial only code in the shared code base. The `share/gc/shared/space.*` is a clear next candidate for refactoring as this change required a bunch of code in there to depend on `INCLUDE_SERIALGC` to build. > > Testing: Tier 1 Passed: tier 2-5 `java/lang/ProcessBuilder/PipelineLeaksFD.java` failed in tier 1. But it succeeded in the previous run (same source) and succeeded when I reran tier 1. Given that the test is working with os pipes it seems unrelated to this PR. ------------- PR: https://git.openjdk.org/jdk/pull/9662 From sangheki at openjdk.org Fri Jul 29 13:40:48 2022 From: sangheki at openjdk.org (Sangheon Kim) Date: Fri, 29 Jul 2022 13:40:48 GMT Subject: RFR: 8290715: Fix incorrect uses of G1CollectedHeap::heap_region_containing() [v3] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 10:15:41 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that fixes some callers of `G1CollectedHeap::heap_region_containing` to a) fail on trying to get the `Heapregion*` on uncommitted regions and b) change some callers to use the correct `heap_region_containing_or_null` method that had been intended there. >> >> Also remove some now unneccessary asserts as `heap_region_containing` will fail when it previously returned `nullptr`. >> >> Testing: tier1-5 >> >> 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 11 commits: > > - Merge branch 'master' into 8290715-heapregion-containing-no-null > - Some more removal of unnecessary checks > - Initial changes > - Fix the places where the wrong heap_region_containing() method has been used > - kbarrett review > - Remove some more casts > - Revert changes to heap_region_containing() > - Remove cast > - Remove unnecessary changes > - some changes > - ... and 1 more: https://git.openjdk.org/jdk/compare/97fc8deb...5dc2fc08 Looks good. ------------- Marked as reviewed by sangheki (Reviewer). PR: https://git.openjdk.org/jdk/pull/9584 From tschatzl at openjdk.org Fri Jul 29 15:43:47 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 29 Jul 2022 15:43:47 GMT Subject: RFR: 8282729: Serial: Move BOT implementation to collector specific directory In-Reply-To: <7AqN4rWBdS4MXP0DToGpzOq5ofmZdsCDjKOgyb7-YlI=.614daef8-6c39-4880-a003-6db02f246c55@github.com> References: <7AqN4rWBdS4MXP0DToGpzOq5ofmZdsCDjKOgyb7-YlI=.614daef8-6c39-4880-a003-6db02f246c55@github.com> Message-ID: On Wed, 27 Jul 2022 18:04:36 GMT, Axel Boldt-Christmas wrote: > Moves serial code from `share/gc/shared/blockOffsetTable.*` to `share/gc/serial/serialBlockOffsetTable.*` > Move required fixing up some missing header files. > Refactoring tries to respect `INCLUDE_SERIALGC` without changing any behaviour. > > Given that `--disable-jvm-feature-serialgc` will not build before this change, it will not build afterwards either. However it does now compile, but will fail to link. > > The diff below is enough to for `make hotspot` to run (on `macosx-aarch64`), but it will not build the complete JDK as the build system will use the compiled binaries with `-XX:+UseSerialGC` which obviously won't work as that GC is missing. > > diff --git a/src/hotspot/share/gc/shared/genCollectedHeap.cpp b/src/hotspot/share/gc/shared/genCollectedHeap.cpp > index 5558f1a4a32..79b465b3e0a 100644 > --- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp > +++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp > @@ -31,7 +31,6 @@ > #include "code/icBuffer.hpp" > #include "compiler/oopMap.hpp" > #include "gc/serial/defNewGeneration.hpp" > -#include "gc/serial/markSweep.hpp" > #include "gc/shared/adaptiveSizePolicy.hpp" > #include "gc/shared/cardTableBarrierSet.hpp" > #include "gc/shared/cardTableRS.hpp" > @@ -80,6 +79,9 @@ > #if INCLUDE_JVMCI > #include "jvmci/jvmci.hpp" > #endif > +#if INCLUDE_SERIALGC > +#include "gc/serial/markSweep.hpp" > +#endif > > GenCollectedHeap::GenCollectedHeap(Generation::Name young, > Generation::Name old, > @@ -204,9 +206,9 @@ void GenCollectedHeap::post_initialize() { > initialize_size_policy(def_new_gen->eden()->capacity(), > _old_gen->capacity(), > def_new_gen->from()->capacity()); > - > +#if INCLUDE_SERIALGC > MarkSweep::initialize(); > - > +#endif > ScavengableNMethods::initialize(&_is_scavengable); > } > > diff --git a/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp b/test/hotspot/gtest/gc/shared/test_collect > orPolicy.cpp > index dfe096248c7..30a24fd9232 100644 > --- a/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp > +++ b/test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp > @@ -31,6 +31,7 @@ > #include "utilities/macros.hpp" > #include "unittest.hpp" > > +#if INCLUDE_SERIALGC > class TestGenCollectorPolicy { > public: > > @@ -279,3 +280,4 @@ TEST_OTHER_VM(CollectorPolicy, old_cmd) { > > TestGenCollectorPolicy::TestWrapper::test(&setter_old_size, &setter_max_new_size, &checker_large); > } > +#endif > > > There is still a lot of Serial only code in the shared code base. The `share/gc/shared/space.*` is a clear next candidate for refactoring as this change required a bunch of code in there to depend on `INCLUDE_SERIALGC` to build. > > Testing: Tier 1 Thanks. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.org/jdk/pull/9662 From tschatzl at openjdk.org Fri Jul 29 15:44:39 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 29 Jul 2022 15:44:39 GMT Subject: RFR: 8290715: Fix incorrect uses of G1CollectedHeap::heap_region_containing() [v3] In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 20:04:43 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge branch 'master' into 8290715-heapregion-containing-no-null >> - Some more removal of unnecessary checks >> - Initial changes >> - Fix the places where the wrong heap_region_containing() method has been used >> - kbarrett review >> - Remove some more casts >> - Revert changes to heap_region_containing() >> - Remove cast >> - Remove unnecessary changes >> - some changes >> - ... and 1 more: https://git.openjdk.org/jdk/compare/97fc8deb...5dc2fc08 > > Looks good. Thanks @kimbarrett @sangheon for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9584 From tschatzl at openjdk.org Fri Jul 29 15:45:45 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 29 Jul 2022 15:45:45 GMT Subject: RFR: 8290525: Move HeapRegion::_compaction_top to G1FullCollector [v2] In-Reply-To: References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> Message-ID: On Thu, 21 Jul 2022 11:14:01 GMT, Kim Barrett wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> kbarrett review > > Marked as reviewed by kbarrett (Reviewer). Thanks @kimbarrett @sangheon for your reviews. ------------- PR: https://git.openjdk.org/jdk/pull/9560 From tschatzl at openjdk.org Fri Jul 29 15:48:43 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 29 Jul 2022 15:48:43 GMT Subject: Integrated: 8290715: Fix incorrect uses of G1CollectedHeap::heap_region_containing() In-Reply-To: References: Message-ID: <9hC86H3VKrQ6Jg5TmS4yZNBoqExANdv2i7tUvlORwxE=.1e655863-0d3a-42e7-bfc1-098c837a35b6@github.com> On Thu, 21 Jul 2022 08:06:04 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that fixes some callers of `G1CollectedHeap::heap_region_containing` to a) fail on trying to get the `Heapregion*` on uncommitted regions and b) change some callers to use the correct `heap_region_containing_or_null` method that had been intended there. > > Also remove some now unneccessary asserts as `heap_region_containing` will fail when it previously returned `nullptr`. > > Testing: tier1-5 > > Thanks, > Thomas This pull request has now been integrated. Changeset: f58e08e2 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/f58e08e2585186e1b3ca2cad20b342d83a8ab133 Stats: 23 lines in 5 files changed: 1 ins; 8 del; 14 mod 8290715: Fix incorrect uses of G1CollectedHeap::heap_region_containing() Reviewed-by: kbarrett, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/9584 From tschatzl at openjdk.org Fri Jul 29 15:48:45 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 29 Jul 2022 15:48:45 GMT Subject: Integrated: 8290525: Move HeapRegion::_compaction_top to G1FullCollector In-Reply-To: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> References: <8KeNH05YxXA1dEA9a4x9aA__Prts1z0m8jHnAmKkXMY=.da4dfb66-9119-428f-9628-7006f3436a93@github.com> Message-ID: On Tue, 19 Jul 2022 15:47:01 GMT, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that moves `HeapRegion::_compaction_top` into the `G1FullCollector` class; my reasoning is that these values are transient temporary values only ever useful for the full collection algorithm, basically results of the application of the algorithm, that are otherwise unused. This makes `HeapRegion` a bit easier to understand/read. > > Testing: tier1-3 > > Thanks, > Thomas This pull request has now been integrated. Changeset: 95fc16bd Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/95fc16bdfa7325ce9f6f8220964f78e6ab63078e Stats: 79 lines in 14 files changed: 28 ins; 32 del; 19 mod 8290525: Move HeapRegion::_compaction_top to G1FullCollector Reviewed-by: kbarrett, sangheki ------------- PR: https://git.openjdk.org/jdk/pull/9560