From wkemper at openjdk.org  Thu Aug  1 14:23:30 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 Aug 2024 14:23:30 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <ifJ35MHPxe2WBy6fKhuodLicTei8Ac1u5rT1SdUfiM4=.e03b9db4-b348-4783-8902-e3d320f31b5a@github.com>

Merges tag jdk-21.0.5+1

-------------

Commit messages:
 - 8337038: Test java/nio/file/attribute/BasicFileAttributeView/CreationTime.java shoud set as /native
 - 8335283: Build failure due to 'no_sanitize' attribute directive ignored
 - 8332903: ubsan: opto/output.cpp:1002:18: runtime error: load of value 171, which is not a valid value for type 'bool'
 - 8269657: Test java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
 - 8326332: Unclosed inline tags cause misalignment in summary tables
 - 8333361: ubsan,test : libHeapMonitorTest.cpp:518:9: runtime error: null pointer passed as argument 2, which is declared to never be null
 - 8334769: Shenandoah: Move CodeCache_lock close to its use in ShenandoahConcurrentNMethodIterator
 - 8310628: GcInfoBuilder.c missing JNI Exception checks
 - 8316131: runtime/cds/appcds/TestParallelGCWithCDS.java fails with JNI error
 - 8334339: Test java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on alinux3
 - ... and 259 more: https://git.openjdk.org/shenandoah-jdk21u/compare/a0b3c6cd...2c9f741d

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=70&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/70/files
  Stats: 46611 lines in 811 files changed: 28490 ins; 14335 del; 3786 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/70.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/70/head:pull/70

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/70

From ysr at openjdk.org  Thu Aug  1 17:53:06 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 1 Aug 2024 17:53:06 GMT
Subject: RFR: 8335126: Shenandoah: Improve OOM handling
In-Reply-To: <A4VthAcH_uoFW85KEhYkHShHsxJ3IQ6W_AWalEHcF64=.1444b757-c1a6-4f7c-b10f-9c458fcfd567@github.com>
References: <A4VthAcH_uoFW85KEhYkHShHsxJ3IQ6W_AWalEHcF64=.1444b757-c1a6-4f7c-b10f-9c458fcfd567@github.com>
Message-ID: <72l6B7XGv2dUFmFCJd8P7p2CArsLN-1cjvu9MblvXRY=.8dcc0208-b25a-417d-b35c-af6a56e04b58@github.com>

On Wed, 31 Jul 2024 19:11:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Mostly clean backport. This commit prevents tests that try to exhaust the heap from running continuous back-to-back full GCs (resulting in timeouts).

Marked as reviewed by ysr (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/69#pullrequestreview-2213483368

From wkemper at openjdk.org  Thu Aug  1 20:22:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 1 Aug 2024 20:22:59 GMT
Subject: Integrated: 8335126: Shenandoah: Improve OOM handling
In-Reply-To: <A4VthAcH_uoFW85KEhYkHShHsxJ3IQ6W_AWalEHcF64=.1444b757-c1a6-4f7c-b10f-9c458fcfd567@github.com>
References: <A4VthAcH_uoFW85KEhYkHShHsxJ3IQ6W_AWalEHcF64=.1444b757-c1a6-4f7c-b10f-9c458fcfd567@github.com>
Message-ID: <lo_UZDPKfznoasD9N6tSLYQKQChQy3gjtrdpmAR0oHQ=.3b62a1c6-0df1-45d4-8664-a8c39141403c@github.com>

On Wed, 31 Jul 2024 19:11:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Mostly clean backport. This commit prevents tests that try to exhaust the heap from running continuous back-to-back full GCs (resulting in timeouts).

This pull request has now been integrated.

Changeset: 2cc704b1
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/2cc704b1fab4fb6b0c023f24c35b46b1a1162feb
Stats:     33 lines in 3 files changed: 13 ins; 1 del; 19 mod

8335126: Shenandoah: Improve OOM handling

Reviewed-by: ysr
Backport-of: 3a87eb5c4606ce39970962895315567e8606eba7

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/69

From wkemper at openjdk.org  Fri Aug  2 14:15:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 2 Aug 2024 14:15:59 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <GYSYkeTt6OJjwSTXboRweQzRYYKk6dv4buunhlverGk=.c2c0e959-829c-4f8e-9b9f-79e8179c09e5@github.com>

Merges tag jdk-24+9

-------------

Commit messages:
 - 8337027: Parallel: Obsolete BaseFootPrintEstimate
 - 8324345: Stack overflow during C2 compilation when splitting memory phi
 - 8331090: Run Ideal_minmax before de-canonicalizing CMoves
 - 8337421: RISC-V: client VM build failure after JDK-8335191
 - 8337523: Fix -Wzero-as-null-pointer-constant warnings in jvmci code
 - 8337418: Fix -Wzero-as-null-pointer-constant warnings in prims code
 - 8336635: Add IR test for Reference.refersTo intrinsic
 - 8336242: compiler/jvmci/jdk.vm.ci.code.test/src/jdk/vm/ci/code/test/SimpleDebugInfoTest.java failed assert(oopDesc::is_oop_or_null(val)) failed: bad oop found (again)
 - 8336912: G1: Undefined behavior for G1ConfidencePercent=0
 - 8337031: Improvements to CompilationMemoryStatistic
 - ... and 20 more: https://git.openjdk.org/shenandoah/compare/bd36b6ae...e4c7850c

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah/pull/465/files
  Stats: 3344 lines in 154 files changed: 2135 ins; 784 del; 425 mod
  Patch: https://git.openjdk.org/shenandoah/pull/465.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/465/head:pull/465

PR: https://git.openjdk.org/shenandoah/pull/465

From shade at openjdk.org  Mon Aug  5 16:38:05 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Aug 2024 16:38:05 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects
Message-ID: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>

This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.

Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).

Additional testing:
 - [x] New test
 - [ ] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
 - [ ] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K

-------------

Commit messages:
 - Touchups in test
 - Basic implementation, works well, passes tests

Changes: https://git.openjdk.org/jdk/pull/20468/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293650
  Stats: 193 lines in 7 files changed: 183 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20468/head:pull/20468

PR: https://git.openjdk.org/jdk/pull/20468

From shade at openjdk.org  Mon Aug  5 17:13:06 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 5 Aug 2024 17:13:06 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v2]
In-Reply-To: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
Message-ID: <fUN_HwDHitJ2e0spqcQbCO2Bj_GJNCGsOeoyfpL9QV0=.1f869cd8-550c-4293-bd85-02f2927f6d10@github.com>

> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
> 
> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
> 
> Additional testing:
>  - [x] New test
>  - [ ] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>  - [ ] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Move constant to separate class to unbreak Windows builds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20468/files
  - new: https://git.openjdk.org/jdk/pull/20468/files/a86686f7..3a8fa655

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=00-01

  Stats: 17 lines in 2 files changed: 9 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20468/head:pull/20468

PR: https://git.openjdk.org/jdk/pull/20468

From ysr at openjdk.org  Tue Aug  6 01:37:11 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 6 Aug 2024 01:37:11 GMT
Subject: RFR: 8337847: [GenShen] jdk.test.whitebox.Whitebox.isObjectInOldGen
 misreports
Message-ID: <tXJXvzFhj2GCooH6Z6oSqemFj3Qf01c6BAEZ6Pl460E=.3555595f-a691-4c4a-b15f-43cdbab9b3fc@github.com>

**Summary**

The whitebox test method `jdk.test.whitebox.Whitebox.isObjectInOldGen` was not correctly implemented for GenShen. It reports only whether the object is in the heap, not whether it's in the old gen, which is its specification.

Upon fixing the implementation for GenShen, a regression test was found to be too tight in insisting that a full GC should promote objects into the old generation. The test was fixed, for the case of GenShen, such that it would not insist on this behavior.

**Testing:**

- [x] GHA
- [x] hotspot/jtreg

-------------

Commit messages:
 - Relax a test that insists that objects are promoted after a full gc,
 - Fix WB_isObjectInOldGen for GenShen.

Changes: https://git.openjdk.org/shenandoah/pull/466/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=466&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337847
  Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah/pull/466.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/466/head:pull/466

PR: https://git.openjdk.org/shenandoah/pull/466

From gziemski at openjdk.org  Tue Aug  6 13:42:04 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 6 Aug 2024 13:42:04 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag,
 use consistent name for the argument
Message-ID: <Il0I2m_qbiFGbp_Oqz6B3-RPKq9zyF0g2TYtGNpMd3M=.d2b42d6c-8823-43f5-8b13-a902d873fd94@github.com>

Please review this NMT cleanup change that mainly renames `MEMFLAGS` to `MemType`, as well as cleanups the related arguments names.

This avoids the inconsistencies and confusion currently on display in our code, where we use `flag`, `flags`, `mem_flag`,  `memflags` for the same argument, even in the same file in related APIs.

I made sure to change the related copyright years in all touched files.

This change is rather simple - we are just renaming names, but it touches 103 files unfortunately.

I did not rename any `NMTUtil::flag` (ex. `NMTUtil::flag_to_index()` -> `NMTUtil::type_to_index()`) to keep the amount of code changes smaller. Those APIs should be renamed, but I filed  a followup issue for this [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

There are also further cleanup opportunities here (ex. renaming internal fields from `_memflags` to `_mem_type`), but again these can be addressed in followup issues.

-------------

Commit messages:
 - undo incorrect rename
 - undo incorrect rename
 - more flag cleanup
 - rename MEMFLAGS to MemType and any related arguments that make sense

Changes: https://git.openjdk.org/jdk/pull/20472/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337563
  Stats: 850 lines in 103 files changed: 1 ins; 0 del; 849 mod
  Patch: https://git.openjdk.org/jdk/pull/20472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20472/head:pull/20472

PR: https://git.openjdk.org/jdk/pull/20472

From nprasad at openjdk.org  Tue Aug  6 18:11:05 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 6 Aug 2024 18:11:05 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v2]
In-Reply-To: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
Message-ID: <gopqhxcNwBPv7OysZ9FEJg0C2lBeBHieeysdddz0TBA=.ca0be5a9-05d9-4b89-95e1-11e2dd96b25f@github.com>

> **Notes**
> This PR adds the following
> 1.  info logging on number of SATB flush attempts
> 2. total time spend on handshaking all threads requesting them to flush their SATB buffers.
> 
> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
> 
> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
> 
> 
> **Testing**
> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
> 2. **-Xlog:gc+stats=info**
> 
> 
> [4.058s][info][gc,stats    ] Concurrent Marking             =    0.080 s (a =     5351 us) (n =    15) (lvls, us =     4746,     5000,     5156,     5684,     5988)
> [4.058s][info][gc,stats    ]   SATB Flush Rendezvous        =    0.013 s (a =      860 us) (n =    15) (lvls, us =      764,      814,      836,      885,      961)
> [4.058s][info][gc,stats    ] Pause Final Mark (G)           =    0.058 s (a =     3839 us) (n =    15) (lvls, us =     3047,     3320,     3867,     4121,     4930)
> [4.058s][info][gc,stats    ] Pause Final Mark (N)           =    0.054 s (a =     3592 us) (n =    15) (lvls, us =     2812,     3047,     3574,     3887,     4597)
> [4.058s][info][gc,stats    ]   Finish Mark                  =    0.028 s (a =     1843 us) (n =    15) (lvls, us =     1602,     1641,     1816,     1934,     2045)
> [4.058s][info][gc,stats    ]   Update Region States         =    0.006 s (a =      386 us) (n =    15) (lvls, us =      375,      375,      381,      389,      413)
> [4.058s][info][gc,stats    ]   Choose Collection Set        =    0.018 s (a =     1186 us) (n =    15) (lvls, us =      609,      619,     1309,     1387,     2109)
> [4.058s][info][gc,stats    ]   Rebuild Free Set             =    0.001 s (a =       43 us) (n =    15) (lvls, us =       40,       41,       42,       43,       53)
> [4.058s][info][gc,stats    ] Concurrent Weak References     =    0.007 s (a =      452 us) (n =    15) (lvls, us =      420,      438,      443,      455,      487)
> 
> 
> on app termination
> 
> 
> [5.299s][info][gc,stats] GC STATISTICS:
> [5.299s][info][gc,stats]   "(G)" (gross) pauses include VM time: time to notify and block threads, do the pre-
> [5.299s][info][gc,stats]         and post-safepoint housekee...

Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:

  ShenandoahTimingsTracker to support aggregation of cycle times

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20318/files
  - new: https://git.openjdk.org/jdk/pull/20318/files/7c3d4a84..6e7fdd5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=00-01

  Stats: 31 lines in 5 files changed: 9 ins; 6 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/20318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20318/head:pull/20318

PR: https://git.openjdk.org/jdk/pull/20318

From gziemski at openjdk.org  Tue Aug  6 18:11:36 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 6 Aug 2024 18:11:36 GMT
Subject: Withdrawn: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <Il0I2m_qbiFGbp_Oqz6B3-RPKq9zyF0g2TYtGNpMd3M=.d2b42d6c-8823-43f5-8b13-a902d873fd94@github.com>
References: <Il0I2m_qbiFGbp_Oqz6B3-RPKq9zyF0g2TYtGNpMd3M=.d2b42d6c-8823-43f5-8b13-a902d873fd94@github.com>
Message-ID: <XK7KrpxToLcn5mKZ28CD64uVK3CoGz869O_Aa_Fef4Q=.9c61d328-51cd-4778-8a5e-d1ab1b96a94f@github.com>

On Mon, 5 Aug 2024 19:07:08 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this NMT cleanup change that renames `MEMFLAGS` to `MemType`.
> 
> To keep this change down I decided not to do any other cleanups as part of this fix. They will be handled in followup issues, such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20472

From shade at openjdk.org  Tue Aug  6 18:24:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 6 Aug 2024 18:24:35 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v2]
In-Reply-To: <gopqhxcNwBPv7OysZ9FEJg0C2lBeBHieeysdddz0TBA=.ca0be5a9-05d9-4b89-95e1-11e2dd96b25f@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <gopqhxcNwBPv7OysZ9FEJg0C2lBeBHieeysdddz0TBA=.ca0be5a9-05d9-4b89-95e1-11e2dd96b25f@github.com>
Message-ID: <MEL1vS1i1am1kn5QHIVOOhSHx1ma0Yjzw4MuNWd00Lc=.303e57ed-85ec-4dbc-8479-93723302682f@github.com>

On Tue, 6 Aug 2024 18:11:05 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [37.087s][info][gc,stats]   CMR: VM Strong Roots              413 us, workers (us):  64,  57,  52,  47,  38,  31,  30,  25,  20,  21,  17,  10, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats]   CMR: CLDG Roots                   449 us, workers (us):   4, ---, ---, 406, ---,  15, ---,   4,   4, ---, ---,  17, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats] Concurrent Marking                 5002 us
>> [37.087s][info][gc,stats]   SATB Flush Rendezvous            1748 us
>> [37.087s][info][gc,stats] Pause Final Mark (G)              57272 us
>> [37.087s][info][gc,stats] Pause Final Mark (N)              56985 us
>> [37.087s][info][gc,stats]   Finish Mark                       387 us
>> [37.087s][info][gc,stats]   Update Region States              109 us
>> [37.087s][info][gc,stats]   Choose Collection Set           56395 us
>> [37.087s][info][gc,stats]   Rebuild Free Set                   40 us
>> 
>> 
>> on app termination
>> 
>> 
>> [40.640s][info][gc,stats] Concurrent Reset               =    0.914 s (a =    65255 us) (n =    14) (lvls, us =    54883,    55859,    63867,    65234,    97096)
>> [40.640s][info][gc,stats] Pause Init Mark (G)            =    1.755 s (a =   125380 us) (n =    14) (lvls, us =   119141,   123047,   125000,   125000,   128042)
>> [40.640s][info][gc,stats] Pause Init Mark (N)            =    1.697 s (a =   121241 us...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ShenandoahTimingsTracker to support aggregation of cycle times

Looks okay, only stylistic comments:

src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 142:

> 140: void ShenandoahPhaseTimings::set_cycle_data(Phase phase, double time, bool should_aggregate_cycles) {
> 141:   if (should_aggregate_cycles) {
> 142:     _cycle_data[phase] = _cycle_data[phase] <= 0 ? time :  _cycle_data[phase] + time;

I *think* `<= 0` is too broad, and assumes things about the value of `uninitialized()`. Check for `uninitialized()` explicitly.

src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp line 127:

> 125:   const double end_time = os::elapsedTime();
> 126:   const double phase_elapsed_time = end_time - _start;
> 127:   _timings->record_phase_time(_phase, phase_elapsed_time, _should_aggregate_cycles);

No need to introduce local variables here, right? The expression can stay inlined.

src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 69:

> 67:   ShenandoahPhaseTimings::Phase         _parent_phase;
> 68:   double _start;
> 69:   bool _should_aggregate_cycles;

How about simplifying it to `_should_aggregate`?

src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 72:

> 70: 
> 71: public:
> 72:   ShenandoahTimingsTracker(ShenandoahPhaseTimings::Phase phase, bool should_aggregate_cycles=false);

Here and everywhere else, need whitespaces: `bool should_aggregate_cycles = false`

-------------

PR Review: https://git.openjdk.org/jdk/pull/20318#pullrequestreview-2221968957
PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1705945023
PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1705943889
PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1705943175
PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1705943455

From nprasad at openjdk.org  Tue Aug  6 19:23:46 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 6 Aug 2024 19:23:46 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v3]
In-Reply-To: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
Message-ID: <n7UUqXNHNG2PMQDQ8WlAng09fyg_VQDE0FL-IgVg43M=.5dce8ddb-9cd0-4da8-aecf-3ad69be24f0d@github.com>

> **Revision 2 Notes** 
> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
> 
> **Revision 1 Notes**
> This PR adds the following
> 1.  info logging on number of SATB flush attempts
> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
> 
> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
> 
> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
> 
> 
> **Testing**
> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
> 2. **-Xlog:gc+stats=info**
> 
> 
> [37.087s][info][gc,stats]   CMR: VM Strong Roots              413 us, workers (us):  64,  57,  52,  47,  38,  31,  30,  25,  20,  21,  17,  10, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [37.087s][info][gc,stats]   CMR: CLDG Roots                   449 us, workers (us):   4, ---, ---, 406, ---,  15, ---,   4,   4, ---, ---,  17, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [37.087s][info][gc,stats] Concurrent Marking                 5002 us
> [37.087s][info][gc,stats]   SATB Flush Rendezvous            1748 us
> [37.087s][info][gc,stats] Pause Final Mark (G)              57272 us
> [37.087s][info][gc,stats] Pause Final Mark (N)              56985 us
> [37.087s][info][gc,stats]   Finish Mark                       387 us
> [37.087s][info][gc,stats]   Update Region States              109 us
> [37.087s][info][gc,stats]   Choose Collection Set           56395 us
> [37.087s][info][gc,stats]   Rebuild Free Set                   40 us
> 
> 
> on app termination
> 
> 
> [40.640s][info][gc,stats] Concurrent Reset               =    0.914 s (a =    65255 us) (n =    14) (lvls, us =    54883,    55859,    63867,    65234,    97096)
> [40.640s][info][gc,stats] Pause Init Mark (G)            =    1.755 s (a =   125380 us) (n =    14) (lvls, us =   119141,   123047,   125000,   125000,   128042)
> [40.640s][info][gc,stats] Pause Init Mark (N)            =    1.697 s (a =   121241 us) (n =    14) (lvls, us =   117188,   119141,   121094,   121094,   123880)
> ...

Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:

  Address feedback on code style and uninitialized check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20318/files
  - new: https://git.openjdk.org/jdk/pull/20318/files/6e7fdd5e..a7c0514a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=01-02

  Stats: 17 lines in 4 files changed: 1 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20318/head:pull/20318

PR: https://git.openjdk.org/jdk/pull/20318

From kdnilsen at openjdk.org  Tue Aug  6 20:20:51 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 6 Aug 2024 20:20:51 GMT
Subject: RFR: 8337847: [GenShen]
 jdk.test.whitebox.Whitebox.isObjectInOldGen misreports
In-Reply-To: <tXJXvzFhj2GCooH6Z6oSqemFj3Qf01c6BAEZ6Pl460E=.3555595f-a691-4c4a-b15f-43cdbab9b3fc@github.com>
References: <tXJXvzFhj2GCooH6Z6oSqemFj3Qf01c6BAEZ6Pl460E=.3555595f-a691-4c4a-b15f-43cdbab9b3fc@github.com>
Message-ID: <FADJ7Fo8cFoHZktE5W-S6-9QE-cSVNYJQiX4EE0Fhnk=.1222adc0-677c-4ecc-b671-5203e2a045de@github.com>

On Tue, 6 Aug 2024 01:32:00 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> **Summary**
> 
> The whitebox test method `jdk.test.whitebox.Whitebox.isObjectInOldGen` was not correctly implemented for GenShen. It reports only whether the object is in the heap, not whether it's in the old gen, which is its specification.
> 
> Upon fixing the implementation for GenShen, a regression test was found to be too tight in insisting that a full GC should promote objects into the old generation. The test was fixed, for the case of GenShen, such that it would not insist on this behavior.
> 
> **Testing:**
> 
> - [x] GHA
> - [x] hotspot/jtreg

Thanks

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/466#pullrequestreview-2222165364

From shade at openjdk.org  Wed Aug  7 08:27:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 08:27:35 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v3]
In-Reply-To: <n7UUqXNHNG2PMQDQ8WlAng09fyg_VQDE0FL-IgVg43M=.5dce8ddb-9cd0-4da8-aecf-3ad69be24f0d@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <n7UUqXNHNG2PMQDQ8WlAng09fyg_VQDE0FL-IgVg43M=.5dce8ddb-9cd0-4da8-aecf-3ad69be24f0d@github.com>
Message-ID: <H0TuDrKjPVEdWcY2sk0_LKHa1mHD0osg5SiMxPnOncc=.5ca371b1-3c64-4f58-a625-54d253bf8e9d@github.com>

On Tue, 6 Aug 2024 19:23:46 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [37.087s][info][gc,stats]   CMR: VM Strong Roots              413 us, workers (us):  64,  57,  52,  47,  38,  31,  30,  25,  20,  21,  17,  10, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats]   CMR: CLDG Roots                   449 us, workers (us):   4, ---, ---, 406, ---,  15, ---,   4,   4, ---, ---,  17, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats] Concurrent Marking                 5002 us
>> [37.087s][info][gc,stats]   SATB Flush Rendezvous            1748 us
>> [37.087s][info][gc,stats] Pause Final Mark (G)              57272 us
>> [37.087s][info][gc,stats] Pause Final Mark (N)              56985 us
>> [37.087s][info][gc,stats]   Finish Mark                       387 us
>> [37.087s][info][gc,stats]   Update Region States              109 us
>> [37.087s][info][gc,stats]   Choose Collection Set           56395 us
>> [37.087s][info][gc,stats]   Rebuild Free Set                   40 us
>> 
>> 
>> on app termination
>> 
>> 
>> [40.640s][info][gc,stats] Concurrent Reset               =    0.914 s (a =    65255 us) (n =    14) (lvls, us =    54883,    55859,    63867,    65234,    97096)
>> [40.640s][info][gc,stats] Pause Init Mark (G)            =    1.755 s (a =   125380 us) (n =    14) (lvls, us =   119141,   123047,   125000,   125000,   128042)
>> [40.640s][info][gc,stats] Pause Init Mark (N)            =    1.697 s (a =   121241 us...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback on code style and uninitialized check

Looks fine. Consider the remaining nits:

src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 143:

> 141:   const double cycle_data = _cycle_data[phase];
> 142:   if (should_aggregate) {
> 143:     _cycle_data[phase] = (cycle_data == uninitialized()) ? time :  cycle_data + time;

Suggestion:

    _cycle_data[phase] = (cycle_data == uninitialized()) ? time : (cycle_data + time);

src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 69:

> 67:   ShenandoahPhaseTimings::Phase         _parent_phase;
> 68:   double _start;
> 69:   bool _should_aggregate;

Should probably be `const bool`?

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20318#pullrequestreview-2223286637
PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1706594323
PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1706595588

From shade at openjdk.org  Wed Aug  7 11:57:02 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 11:57:02 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
Message-ID: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>

The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap. This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. 

I also re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.

Additional testing:
 - [ ] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/20492/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20492&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337981
  Stats: 74 lines in 9 files changed: 35 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/20492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20492/head:pull/20492

PR: https://git.openjdk.org/jdk/pull/20492

From nprasad at openjdk.org  Wed Aug  7 13:19:12 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Wed, 7 Aug 2024 13:19:12 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v4]
In-Reply-To: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
Message-ID: <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>

> **Revision 2 Notes** 
> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
> 
> **Revision 1 Notes**
> This PR adds the following
> 1.  info logging on number of SATB flush attempts
> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
> 
> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
> 
> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
> 
> 
> **Testing**
> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
> 2. **-Xlog:gc+stats=info**
> 
> 
> [37.087s][info][gc,stats]   CMR: VM Strong Roots              413 us, workers (us):  64,  57,  52,  47,  38,  31,  30,  25,  20,  21,  17,  10, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [37.087s][info][gc,stats]   CMR: CLDG Roots                   449 us, workers (us):   4, ---, ---, 406, ---,  15, ---,   4,   4, ---, ---,  17, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [37.087s][info][gc,stats] Concurrent Marking                 5002 us
> [37.087s][info][gc,stats]   SATB Flush Rendezvous            1748 us
> [37.087s][info][gc,stats] Pause Final Mark (G)              57272 us
> [37.087s][info][gc,stats] Pause Final Mark (N)              56985 us
> [37.087s][info][gc,stats]   Finish Mark                       387 us
> [37.087s][info][gc,stats]   Update Region States              109 us
> [37.087s][info][gc,stats]   Choose Collection Set           56395 us
> [37.087s][info][gc,stats]   Rebuild Free Set                   40 us
> 
> 
> on app termination
> 
> 
> [40.640s][info][gc,stats] Concurrent Reset               =    0.914 s (a =    65255 us) (n =    14) (lvls, us =    54883,    55859,    63867,    65234,    97096)
> [40.640s][info][gc,stats] Pause Init Mark (G)            =    1.755 s (a =   125380 us) (n =    14) (lvls, us =   119141,   123047,   125000,   125000,   128042)
> [40.640s][info][gc,stats] Pause Init Mark (N)            =    1.697 s (a =   121241 us) (n =    14) (lvls, us =   117188,   119141,   121094,   121094,   123880)
> ...

Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:

  Address feedback on code style

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20318/files
  - new: https://git.openjdk.org/jdk/pull/20318/files/a7c0514a..9649c2ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=02-03

  Stats: 5 lines in 3 files changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20318/head:pull/20318

PR: https://git.openjdk.org/jdk/pull/20318

From shade at openjdk.org  Wed Aug  7 14:28:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 14:28:32 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v4]
In-Reply-To: <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>
Message-ID: <I13w0CQF6Pb9fy2YTyu6cHJkzYeOSkZvJzYd9aTQfjU=.d1170f9f-9d94-431e-969c-ef97c59f9f89@github.com>

On Wed, 7 Aug 2024 13:19:12 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [37.087s][info][gc,stats]   CMR: VM Strong Roots              413 us, workers (us):  64,  57,  52,  47,  38,  31,  30,  25,  20,  21,  17,  10, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats]   CMR: CLDG Roots                   449 us, workers (us):   4, ---, ---, 406, ---,  15, ---,   4,   4, ---, ---,  17, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats] Concurrent Marking                 5002 us
>> [37.087s][info][gc,stats]   SATB Flush Rendezvous            1748 us
>> [37.087s][info][gc,stats] Pause Final Mark (G)              57272 us
>> [37.087s][info][gc,stats] Pause Final Mark (N)              56985 us
>> [37.087s][info][gc,stats]   Finish Mark                       387 us
>> [37.087s][info][gc,stats]   Update Region States              109 us
>> [37.087s][info][gc,stats]   Choose Collection Set           56395 us
>> [37.087s][info][gc,stats]   Rebuild Free Set                   40 us
>> 
>> 
>> on app termination
>> 
>> 
>> [40.640s][info][gc,stats] Concurrent Reset               =    0.914 s (a =    65255 us) (n =    14) (lvls, us =    54883,    55859,    63867,    65234,    97096)
>> [40.640s][info][gc,stats] Pause Init Mark (G)            =    1.755 s (a =   125380 us) (n =    14) (lvls, us =   119141,   123047,   125000,   125000,   128042)
>> [40.640s][info][gc,stats] Pause Init Mark (N)            =    1.697 s (a =   121241 us...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback on code style

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20318#pullrequestreview-2225370812

From ysr at openjdk.org  Wed Aug  7 14:48:52 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Aug 2024 14:48:52 GMT
Subject: RFR: 8337847: [GenShen]
 jdk.test.whitebox.Whitebox.isObjectInOldGen misreports
In-Reply-To: <tXJXvzFhj2GCooH6Z6oSqemFj3Qf01c6BAEZ6Pl460E=.3555595f-a691-4c4a-b15f-43cdbab9b3fc@github.com>
References: <tXJXvzFhj2GCooH6Z6oSqemFj3Qf01c6BAEZ6Pl460E=.3555595f-a691-4c4a-b15f-43cdbab9b3fc@github.com>
Message-ID: <oSRph5G4dWGs5QfzBG84oFtr9fmZb_c_eDWdKZqwMQc=.1e9fc27a-025e-4e8d-9f5d-6837981fbccc@github.com>

On Tue, 6 Aug 2024 01:32:00 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> **Summary**
> 
> The whitebox test method `jdk.test.whitebox.Whitebox.isObjectInOldGen` was not correctly implemented for GenShen. It reports only whether the object is in the heap, not whether it's in the old gen, which is its specification.
> 
> Upon fixing the implementation for GenShen, a regression test was found to be too tight in insisting that a full GC should promote objects into the old generation. The test was fixed, for the case of GenShen, such that it would not insist on this behavior.
> 
> **Testing:**
> 
> - [x] GHA
> - [x] hotspot/jtreg

Thanks Kelvin.

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/466#issuecomment-2273648502

From ysr at openjdk.org  Wed Aug  7 14:48:52 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 7 Aug 2024 14:48:52 GMT
Subject: Integrated: 8337847: [GenShen]
 jdk.test.whitebox.Whitebox.isObjectInOldGen misreports
In-Reply-To: <tXJXvzFhj2GCooH6Z6oSqemFj3Qf01c6BAEZ6Pl460E=.3555595f-a691-4c4a-b15f-43cdbab9b3fc@github.com>
References: <tXJXvzFhj2GCooH6Z6oSqemFj3Qf01c6BAEZ6Pl460E=.3555595f-a691-4c4a-b15f-43cdbab9b3fc@github.com>
Message-ID: <Gr9p7uLlC0_WMOdVH6na_nnrSjq9oiU78yfGWZw-Dy8=.f4f779cf-8710-459f-852a-178adf1877da@github.com>

On Tue, 6 Aug 2024 01:32:00 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> **Summary**
> 
> The whitebox test method `jdk.test.whitebox.Whitebox.isObjectInOldGen` was not correctly implemented for GenShen. It reports only whether the object is in the heap, not whether it's in the old gen, which is its specification.
> 
> Upon fixing the implementation for GenShen, a regression test was found to be too tight in insisting that a full GC should promote objects into the old generation. The test was fixed, for the case of GenShen, such that it would not insist on this behavior.
> 
> **Testing:**
> 
> - [x] GHA
> - [x] hotspot/jtreg

This pull request has now been integrated.

Changeset: 44f5995b
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/44f5995bf87cb2e82176f2393517e4a11447b516
Stats:     11 lines in 2 files changed: 9 ins; 0 del; 2 mod

8337847: [GenShen] jdk.test.whitebox.Whitebox.isObjectInOldGen misreports

Reviewed-by: kdnilsen

-------------

PR: https://git.openjdk.org/shenandoah/pull/466

From shade at openjdk.org  Wed Aug  7 14:57:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 14:57:35 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
In-Reply-To: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
Message-ID: <ytKd627rD2Nsglg9QImt9OGBvUhR8LtAsPQNn8qpOCw=.09c6475b-273d-4768-ae95-b39e43fff40f@github.com>

On Wed, 7 Aug 2024 11:51:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap. This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. 
> 
> I also re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
> 
> Additional testing:
>  - [ ] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Test failures, there are verifier paths that touch dead Reference.referent, apparently. Figuring it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20492#issuecomment-2273672661

From shade at openjdk.org  Wed Aug  7 17:07:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 17:07:35 GMT
Subject: RFR: 8335865: Shenandoah: Improve THP pretouch after JDK-8315923
In-Reply-To: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
References: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
Message-ID: <1HLgUoF7ByaXQkgUB3UYK35VzxayzTXZl562fDBWKZ8=.3641cb43-c0f4-44c1-bbce-af168d02ead2@github.com>

On Fri, 19 Jul 2024 14:28:24 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

> **Notes**
> os::pretouch is now using madvice now when available and has a fall back to using vm page size [JDK-8315923](https://bugs.openjdk.org/browse/JDK-8315923)
> Hence removing code that sets _pretouch_heap_page_size & _pretouch_bitmap_page_size  in Shenandoah.
> 
> **Testing**
> 
> * Ran test in Linux 5.10 and Linux 6.x and confirmed that there is no regression. I could not replicate the issue or performance improvement though. [add results]
> * Ran [TestTransparentHugePageUsage](https://github.com/openjdk/jdk/commit/a65a89522d2f24b1767e1c74f6689a22ea32ca6a) for Shenandoah and verified that test passed
> * Ran tier 1, tier 2 , tier1_gc_shenandoah, tier2_gc_shenandoah, tier3_gc_shenandoah and hotspot_gc_shenandoah.

I am approving, since the "problem" appears to be a kernel version between 5.8 and 5.14. So THP is broken there, and MADV_POPULATE_WRITE is still not available. Reading the JDK-8315923 code, it essentially does what this code was doing, so we do not actually regress anything.

I think we only need to confirm using the one-liner I had above that >=5.14 really works, and <5.8 does not regress the speed with which we wire up `AnonHugePages`.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 287:

> 285:   // Reserve aux bitmap for use in object_iterate(). We don't commit it here.
> 286:   size_t aux_bitmap_page_size = bitmap_page_size;
> 287: 

I think this newline is unnecessary.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20254#pullrequestreview-2225728082
PR Review Comment: https://git.openjdk.org/jdk/pull/20254#discussion_r1707457414

From gziemski at openjdk.org  Wed Aug  7 17:47:47 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 7 Aug 2024 17:47:47 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
Message-ID: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>

Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.

`MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.

There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

-------------

Commit messages:
 - rename MEMFLAGS to MemType

Changes: https://git.openjdk.org/jdk/pull/20497/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20497&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337563
  Stats: 502 lines in 100 files changed: 1 ins; 0 del; 501 mod
  Patch: https://git.openjdk.org/jdk/pull/20497.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20497/head:pull/20497

PR: https://git.openjdk.org/jdk/pull/20497

From shade at openjdk.org  Wed Aug  7 18:48:36 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 18:48:36 GMT
Subject: RFR: 8335865: Shenandoah: Improve THP pretouch after JDK-8315923
In-Reply-To: <1HLgUoF7ByaXQkgUB3UYK35VzxayzTXZl562fDBWKZ8=.3641cb43-c0f4-44c1-bbce-af168d02ead2@github.com>
References: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
 <1HLgUoF7ByaXQkgUB3UYK35VzxayzTXZl562fDBWKZ8=.3641cb43-c0f4-44c1-bbce-af168d02ead2@github.com>
Message-ID: <-pE70sSWPv6wUCDfLwEp1f8ZSbV1N-Gn3lOlcINCxww=.9fe8a8e4-b69b-45cc-a891-7565a6ff8572@github.com>

On Wed, 7 Aug 2024 17:04:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I think we only need to confirm using the one-liner I had above that >=5.14 really works

I confirmed Shenandoah THP+Pretouch works well on my desktop with 5.15, either by default or with `-XX:-UseMadvPopulateWrite`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20254#issuecomment-2274119099

From shade at openjdk.org  Wed Aug  7 18:50:47 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 7 Aug 2024 18:50:47 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
Message-ID: <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>

> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
> 
> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
> 
> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
> 
> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:

 - Style touchups
 - Fixing ShenandoahReferenceProcessor
 - Verifier fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20492/files
  - new: https://git.openjdk.org/jdk/pull/20492/files/dbab6d43..69c66853

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20492&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20492&range=00-01

  Stats: 35 lines in 2 files changed: 22 ins; 7 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20492/head:pull/20492

PR: https://git.openjdk.org/jdk/pull/20492

From dholmes at openjdk.org  Thu Aug  8 04:49:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 8 Aug 2024 04:49:35 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <kgJ3TT6Yf1-24koTSLcpFt9IhKK-BegaxzSiEsngtZQ=.b34e747e-8e2a-4df6-a899-70931cab8053@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

If you called it `MemTypeFlag` - which to me still suggests mutually-exclusive values - then you would not need to rename all the variables with "flag" in their name later.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20497#pullrequestreview-2226852251

From wkemper at openjdk.org  Thu Aug  8 14:23:08 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 8 Aug 2024 14:23:08 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <FN42Z-N-VX7yJxv4_uuau2vP7iqWDyk7fzrwsht1ZXs=.4e0048af-8dff-493c-be96-623488789311@github.com>

Merges tag jdk-21.0.5+2

-------------

Commit messages:
 - 8333622: ubsan: relocInfo_x86.cpp:101:56: runtime error: pointer index expression with base (-1) overflowed
 - 8321509: False positive in get_trampoline fast path causes crash
 - 8331731: ubsan: relocInfo.cpp:155:30: runtime error: applying non-zero offset to null pointer
 - 8335493: check_gc_overhead_limit should reset SoftRefPolicy::_should_clear_all_soft_refs
 - 8331854: ubsan: copy.hpp:218:10: runtime error: addition of unsigned offset to 0x7fc2b4024518 overflowed to 0x7fc2b4024510
 - 8336301: test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO file upon test completion
 - 8324808: Manual printer tests have no Pass/Fail buttons, instructions close set 3
 - 8317112: Add screenshot for Frame/DefaultSizeTest.java
 - 8335967: "text-decoration: none" does not work with "A" HTML tags
 - 8324580: SIGFPE on THP initialization on kernels < 4.10
 - ... and 280 more: https://git.openjdk.org/shenandoah-jdk21u/compare/a0b3c6cd...dac39de0

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=71&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/71/files
  Stats: 49854 lines in 843 files changed: 29467 ins; 15795 del; 4592 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/71.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/71/head:pull/71

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/71

From shade at openjdk.org  Thu Aug  8 16:23:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 8 Aug 2024 16:23:39 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v4]
In-Reply-To: <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>
Message-ID: <dWk2Kji3GBMziw9j6IUIZIDTd0QprF_fk6f7M9TPAkY=.34345e52-3d32-4db2-9ba4-3202ef1e179a@github.com>

On Wed, 7 Aug 2024 13:19:12 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [37.087s][info][gc,stats]   CMR: VM Strong Roots              413 us, workers (us):  64,  57,  52,  47,  38,  31,  30,  25,  20,  21,  17,  10, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats]   CMR: CLDG Roots                   449 us, workers (us):   4, ---, ---, 406, ---,  15, ---,   4,   4, ---, ---,  17, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats] Concurrent Marking                 5002 us
>> [37.087s][info][gc,stats]   SATB Flush Rendezvous            1748 us
>> [37.087s][info][gc,stats] Pause Final Mark (G)              57272 us
>> [37.087s][info][gc,stats] Pause Final Mark (N)              56985 us
>> [37.087s][info][gc,stats]   Finish Mark                       387 us
>> [37.087s][info][gc,stats]   Update Region States              109 us
>> [37.087s][info][gc,stats]   Choose Collection Set           56395 us
>> [37.087s][info][gc,stats]   Rebuild Free Set                   40 us
>> 
>> 
>> on app termination
>> 
>> 
>> [40.640s][info][gc,stats] Concurrent Reset               =    0.914 s (a =    65255 us) (n =    14) (lvls, us =    54883,    55859,    63867,    65234,    97096)
>> [40.640s][info][gc,stats] Pause Init Mark (G)            =    1.755 s (a =   125380 us) (n =    14) (lvls, us =   119141,   123047,   125000,   125000,   128042)
>> [40.640s][info][gc,stats] Pause Init Mark (N)            =    1.697 s (a =   121241 us...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback on code style

Marked as reviewed by shade (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 67:

> 65:   ShenandoahPhaseTimings* const         _timings;
> 66:   const ShenandoahPhaseTimings::Phase   _phase;
> 67:   const bool _should_aggregate;

One really tiny thing: `_should_aggregate` should be indented like other field names.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20318#pullrequestreview-2228346593
PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1709865975

From gziemski at openjdk.org  Thu Aug  8 17:50:31 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 8 Aug 2024 17:50:31 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <kgJ3TT6Yf1-24koTSLcpFt9IhKK-BegaxzSiEsngtZQ=.b34e747e-8e2a-4df6-a899-70931cab8053@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <kgJ3TT6Yf1-24koTSLcpFt9IhKK-BegaxzSiEsngtZQ=.b34e747e-8e2a-4df6-a899-70931cab8053@github.com>
Message-ID: <TaOjDUWEnmp1OlrR9RZTuxH2nUS1hXmo3BXgchNNDYw=.ebc35737-1b3e-465c-97dc-f629816fa678@github.com>

On Thu, 8 Aug 2024 04:47:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If you called it `MemTypeFlag` - which to me still suggests mutually-exclusive values - then you would not need to rename all the variables with "flag" in their name later.

Hmm, not a bad idea. Are there any other opinions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2276354395

From thomas.stuefe at gmail.com  Thu Aug  8 20:33:55 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 8 Aug 2024 13:33:55 -0700
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <TaOjDUWEnmp1OlrR9RZTuxH2nUS1hXmo3BXgchNNDYw=.ebc35737-1b3e-465c-97dc-f629816fa678@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <kgJ3TT6Yf1-24koTSLcpFt9IhKK-BegaxzSiEsngtZQ=.b34e747e-8e2a-4df6-a899-70931cab8053@github.com>
 <TaOjDUWEnmp1OlrR9RZTuxH2nUS1hXmo3BXgchNNDYw=.ebc35737-1b3e-465c-97dc-f629816fa678@github.com>
Message-ID: <CAA-vtUzAb=vVZ2f-k_1L3JpwFh349RjcjqTBhbNB+94_y3wgOQ@mail.gmail.com>

I like it short, succinct and greppable.

NMTCategory? NMTCat?

That said, I can live with the current name and dread the cv backporting
and support implications of this change.

On Thu 8. Aug 2024 at 10:50, Gerard Ziemski <gziemski at openjdk.org> wrote:

> On Thu, 8 Aug 2024 04:47:18 GMT, David Holmes <dholmes at openjdk.org> wrote:
>
> > If you called it `MemTypeFlag` - which to me still suggests
> mutually-exclusive values - then you would not need to rename all the
> variables with "flag" in their name later.
>
> Hmm, not a bad idea. Are there any other opinions?
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2276354395
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20240808/066ec13c/attachment.htm>

From thomas.stuefe at gmail.com  Thu Aug  8 20:53:29 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 8 Aug 2024 13:53:29 -0700
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <CAA-vtUzAb=vVZ2f-k_1L3JpwFh349RjcjqTBhbNB+94_y3wgOQ@mail.gmail.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <kgJ3TT6Yf1-24koTSLcpFt9IhKK-BegaxzSiEsngtZQ=.b34e747e-8e2a-4df6-a899-70931cab8053@github.com>
 <TaOjDUWEnmp1OlrR9RZTuxH2nUS1hXmo3BXgchNNDYw=.ebc35737-1b3e-465c-97dc-f629816fa678@github.com>
 <CAA-vtUzAb=vVZ2f-k_1L3JpwFh349RjcjqTBhbNB+94_y3wgOQ@mail.gmail.com>
Message-ID: <CAA-vtUzCAKKxe6KergKnUQKASEt2Q_xk1mrM6UoM_nQHZZJDPQ@mail.gmail.com>

Just to state: if the majority wants a rename , that is of course fine. The
existing name is admittedly a bit of an eyesore.

On Thu 8. Aug 2024 at 13:33, Thomas St?fe <thomas.stuefe at gmail.com> wrote:

> I like it short, succinct and greppable.
>
> NMTCategory? NMTCat?
>
> That said, I can live with the current name and dread the cv backporting
> and support implications of this change.
>
> On Thu 8. Aug 2024 at 10:50, Gerard Ziemski <gziemski at openjdk.org> wrote:
>
>> On Thu, 8 Aug 2024 04:47:18 GMT, David Holmes <dholmes at openjdk.org>
>> wrote:
>>
>> > If you called it `MemTypeFlag` - which to me still suggests
>> mutually-exclusive values - then you would not need to rename all the
>> variables with "flag" in their name later.
>>
>> Hmm, not a bad idea. Are there any other opinions?
>>
>> -------------
>>
>> PR Comment:
>> https://git.openjdk.org/jdk/pull/20497#issuecomment-2276354395
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20240808/af9fcbb8/attachment.htm>

From wkemper at openjdk.org  Fri Aug  9 14:15:58 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 9 Aug 2024 14:15:58 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <18KKPNbwPRjX4bNMyW9Odo_EvwVdE0BMO5Q36SEtQoI=.4be9569e-cdd3-4ecf-b877-d44998e2214a@github.com>

Merges tag jdk-24+10

-------------

Commit messages:
 - 8337971: Problem list several jvmci tests on linux-riscv64 until JDK-8331704 is fixed
 - 8337826: Improve logging in OCSPTimeout and SimpleOCSPResponder to help diagnose JDK-8309754
 - 8337410: The makefiles should set problemlist and adjust timeout basing on the given VM flags
 - 8335172: Add manual steps to run security/auth/callback/TextCallbackHandler/Password.java test
 - 8336846: assert(state->get_thread() == jt) failed: handshake unsafe conditions
 - 8337603: Change in behavior with -Djava.locale.useOldISOCodes=true
 - 8310675: Fix -Wconversion warnings in ZGC code
 - 8337975: [BACKOUT] Native memory leak when not recording any events
 - 8335925: Serial: Move allocation API from Generation to subclasses
 - 8337968: Problem list compiler/vectorapi/VectorRebracket128Test.java
 - ... and 88 more: https://git.openjdk.org/shenandoah/compare/bd36b6ae...16df9c33

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah/pull/467/files
  Stats: 12093 lines in 480 files changed: 6377 ins; 3701 del; 2015 mod
  Patch: https://git.openjdk.org/shenandoah/pull/467.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/467/head:pull/467

PR: https://git.openjdk.org/shenandoah/pull/467

From gziemski at openjdk.org  Fri Aug  9 21:27:40 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 9 Aug 2024 21:27:40 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <gi_whHcafBBbIy8jB243wnoWXv5Sy3JH6UR3rYJ_OCY=.6d63c426-622f-42a8-9865-cd0b156a71e9@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

We could do:

`#define MEMFLAGS MemType`

to help out with backports, and leave it up to the runtime/compiler/gc teams when to pull the trigger to switch over when they are ready, if that helps? Any backport would have to deal with this change to a degree though unfortunately.

I would want this change in runtime/nmt at the minimum, though personally I would prefer if we adopted it everywhere as in my proposed fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2278776049

From gziemski at openjdk.org  Fri Aug  9 21:33:43 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 9 Aug 2024 21:33:43 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <I0FYgiVEx4IhwaEJyrl0wzK_82PrysTXMK_VMuWA_0U=.7ed026ae-cbdb-4d7c-9e47-eb8f2a1b0353@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

The current proposed fix renames from MEMFLAGS to MemType, other proposed names are:

- MemTypeFlag
- NMTCategory
- NMTCat

I also like:

- NMTMemType

Any other suggestions?

I don't think I will be following up with argument renaming after this, though, whatever the final name we agree on...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2278781358

From shade at openjdk.org  Mon Aug 12 13:53:07 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 12 Aug 2024 13:53:07 GMT
Subject: RFR: 8338202: Shenandoah: Improve handshake closure labels
Message-ID: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>

Currently, Shenandoah has a few handshakes that have not very clear names, "ShenandoahRendezvous". Would be good to make them more explicit.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/20549/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20549&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338202
  Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20549.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20549/head:pull/20549

PR: https://git.openjdk.org/jdk/pull/20549

From rkennke at openjdk.org  Mon Aug 12 16:23:31 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 12 Aug 2024 16:23:31 GMT
Subject: RFR: 8338202: Shenandoah: Improve handshake closure labels
In-Reply-To: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
References: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
Message-ID: <i1eSLI-LXgZOfdQCiQqcfXwzHV_EUxG_dBhLY_4sprk=.f2c0022f-3276-4cdb-9e7b-7ce148bbcfa2@github.com>

On Mon, 12 Aug 2024 13:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, Shenandoah has a few handshakes that have not very clear names, "ShenandoahRendezvous". Would be good to make them more explicit.
> 
> Before:
> 
> 
> Event: 2.593 Executing VM operation: Shenandoah Init Marking
> Event: 2.594 Executing VM operation: Shenandoah Init Marking done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 2.600 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.605 Executing VM operation: CleanClassLoaderDataMetaspaces
> Event: 2.606 Executing VM operation: CleanClassLoaderDataMetaspaces done
> Event: 2.606 Executing VM operation: Shenandoah Init Update References
> Event: 2.606 Executing VM operation: Shenandoah Init Update References done
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots)
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots) done
> Event: 2.611 Executing VM operation: Shenandoah Final Update References
> Event: 2.611 Executing VM operation: Shenandoah Final Update References done 
> 
> 
> After:
> 
> 
> Event: 1.043 Executing VM operation: Shenandoah Init Marking        
> Event: 1.044 Executing VM operation: Shenandoah Init Marking done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 1.051 Executing VM operation: HandshakeAllThreads (Shenandoah Concurrent Weak...

Looks good to me, thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20549#pullrequestreview-2233517305

From kdnilsen at openjdk.org  Mon Aug 12 17:28:56 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 Aug 2024 17:28:56 GMT
Subject: Withdrawn: 8321401: GenShen: Each mutator must see FullGC before
 throwing OOM
In-Reply-To: <MGraFQCxaBcWwSZp0rNs7iIg49HNgcJR82jV3toN100=.9ea64d20-9a71-41b9-88c8-9d84499ed9de@github.com>
References: <MGraFQCxaBcWwSZp0rNs7iIg49HNgcJR82jV3toN100=.9ea64d20-9a71-41b9-88c8-9d84499ed9de@github.com>
Message-ID: <Z9ugJKkaCouw2mRiFq7SgFUM_CFil1aECmcWajAOYPQ=.c22c50a3-2ae8-4313-b44d-9a7722925b42@github.com>

On Tue, 5 Dec 2023 14:40:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Require each thread to observe unproductive Full GC before it throws OOM exception.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/shenandoah/pull/365

From kdnilsen at openjdk.org  Mon Aug 12 19:34:09 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 Aug 2024 19:34:09 GMT
Subject: RFR: 8327000: GenShen: Integrate updated Shenandoah implementation
 of FreeSet into GenShen [v3]
In-Reply-To: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
References: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
Message-ID: <FmlXAn1sxfCfV9RpmF0dihRkb-th1TgtrtIHIW677Kc=.129235eb-b775-4370-b79a-d4f8b9132549@github.com>

> This pull request contains a backport of commit 9d2712dd from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 26 Jun 2024 and was reviewed by William Kemper and Y. Srinivas Ramakrishna.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  TestAllocIntArrays sometimes fails with aggressive heuristics
  
  This bug has been fixed in TIP.  The fix was not backported to JDK21.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files/5b6a8543..7038d0a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/62.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/62/head:pull/62

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/62

From kdnilsen at openjdk.org  Mon Aug 12 19:44:27 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 Aug 2024 19:44:27 GMT
Subject: RFR: 8327000: GenShen: Integrate updated Shenandoah implementation
 of FreeSet into GenShen [v4]
In-Reply-To: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
References: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
Message-ID: <UGt555_lP_JcnAzHNqST3ve7tEdm24fW9qgvVi8USPc=.226e2113-1ce6-49a7-a7aa-d459b6e1cffa@github.com>

> This pull request contains a backport of commit 9d2712dd from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 26 Jun 2024 and was reviewed by William Kemper and Y. Srinivas Ramakrishna.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Resolve merge conflicts

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files/7038d0a5..ce8058f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=03
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=02-03

  Stats: 55 lines in 2 files changed: 17 ins; 30 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/62.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/62/head:pull/62

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/62

From gziemski at openjdk.org  Mon Aug 12 19:48:32 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 12 Aug 2024 19:48:32 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <kgJ3TT6Yf1-24koTSLcpFt9IhKK-BegaxzSiEsngtZQ=.b34e747e-8e2a-4df6-a899-70931cab8053@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <kgJ3TT6Yf1-24koTSLcpFt9IhKK-BegaxzSiEsngtZQ=.b34e747e-8e2a-4df6-a899-70931cab8053@github.com>
Message-ID: <tFmkzA-VohobGbwC0XXl11MkK-PUd2WjXP802lqXuPI=.1c07ee0d-dbf1-4264-9f28-d2bba8bcbda8@github.com>

On Thu, 8 Aug 2024 04:47:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> If you called it `MemTypeFlag` - which to me still suggests mutually-exclusive values - then you would not need to rename all the variables with "flag" in their name later.

@dholmes-ora @tstuefe @jdksjolen 

Where are we here? I have renamed MEMFLAGS to MemType.

Is this fine, or do you wish to see a different way to handle this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2284784541

From kdnilsen at openjdk.org  Mon Aug 12 20:02:11 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 Aug 2024 20:02:11 GMT
Subject: RFR: 8327000: GenShen: Integrate updated Shenandoah implementation
 of FreeSet into GenShen [v5]
In-Reply-To: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
References: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
Message-ID: <M4pENgtpam1qTIqgzn1WYdoOANnDw5_F2HGbjqtLog0=.9e6bfa0a-9030-4314-ad72-8b95cebe09fb@github.com>

> This pull request contains a backport of commit 9d2712dd from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 26 Jun 2024 and was reviewed by William Kemper and Y. Srinivas Ramakrishna.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Revert incorrect resolution of merge conflict
  
  One of the changes recently committed in attempt to resolve merge
  conflict was wrong.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files/ce8058f1..9ecc1914

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=04
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/62.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/62/head:pull/62

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/62

From ysr at openjdk.org  Mon Aug 12 20:11:32 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 12 Aug 2024 20:11:32 GMT
Subject: RFR: 8338202: Shenandoah: Improve handshake closure labels
In-Reply-To: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
References: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
Message-ID: <ef9iYUh0y9Kww1MIsUcgiHLv-FWolvzO3-c4ss8fWi0=.c118ec23-86e6-48f9-bcbe-c28a97c290db@github.com>

On Mon, 12 Aug 2024 13:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, Shenandoah has a few handshakes that have not very clear names, "ShenandoahRendezvous". Would be good to make them more explicit.
> 
> Before:
> 
> 
> Event: 2.593 Executing VM operation: Shenandoah Init Marking
> Event: 2.594 Executing VM operation: Shenandoah Init Marking done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 2.600 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.605 Executing VM operation: CleanClassLoaderDataMetaspaces
> Event: 2.606 Executing VM operation: CleanClassLoaderDataMetaspaces done
> Event: 2.606 Executing VM operation: Shenandoah Init Update References
> Event: 2.606 Executing VM operation: Shenandoah Init Update References done
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots)
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots) done
> Event: 2.611 Executing VM operation: Shenandoah Final Update References
> Event: 2.611 Executing VM operation: Shenandoah Final Update References done 
> 
> 
> After:
> 
> 
> Event: 1.043 Executing VM operation: Shenandoah Init Marking        
> Event: 1.044 Executing VM operation: Shenandoah Init Marking done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 1.051 Executing VM operation: HandshakeAllThreads (Shenandoah Concurrent Weak...

Marked as reviewed by ysr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20549#pullrequestreview-2233923775

From wkemper at openjdk.org  Mon Aug 12 20:28:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 12 Aug 2024 20:28:32 GMT
Subject: RFR: 8338202: Shenandoah: Improve handshake closure labels
In-Reply-To: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
References: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
Message-ID: <B3HH2ypOVmca2xM50lG3V64KyxjNmvU-JbsWEqNl7qw=.1ab89c56-d233-4433-a139-e93424962eee@github.com>

On Mon, 12 Aug 2024 13:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, Shenandoah has a few handshakes that have not very clear names, "ShenandoahRendezvous". Would be good to make them more explicit.
> 
> Before:
> 
> 
> Event: 2.593 Executing VM operation: Shenandoah Init Marking
> Event: 2.594 Executing VM operation: Shenandoah Init Marking done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 2.600 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.605 Executing VM operation: CleanClassLoaderDataMetaspaces
> Event: 2.606 Executing VM operation: CleanClassLoaderDataMetaspaces done
> Event: 2.606 Executing VM operation: Shenandoah Init Update References
> Event: 2.606 Executing VM operation: Shenandoah Init Update References done
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots)
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots) done
> Event: 2.611 Executing VM operation: Shenandoah Final Update References
> Event: 2.611 Executing VM operation: Shenandoah Final Update References done 
> 
> 
> After:
> 
> 
> Event: 1.043 Executing VM operation: Shenandoah Init Marking        
> Event: 1.044 Executing VM operation: Shenandoah Init Marking done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 1.051 Executing VM operation: HandshakeAllThreads (Shenandoah Concurrent Weak...

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20549#pullrequestreview-2233950899

From kdnilsen at openjdk.org  Mon Aug 12 20:31:59 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 Aug 2024 20:31:59 GMT
Subject: RFR: 8327000: GenShen: Integrate updated Shenandoah implementation
 of FreeSet into GenShen [v6]
In-Reply-To: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
References: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
Message-ID: <bjP4BLK7gdrn118HiLE2wPISyLOR-R5JU9sZFNa1_zU=.4b3265b5-471e-4554-8918-ee11ece793d3@github.com>

> This pull request contains a backport of commit 9d2712dd from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 26 Jun 2024 and was reviewed by William Kemper and Y. Srinivas Ramakrishna.

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge remote-tracking branch 'gitfarm/backport-kdnilsen-9d2712dd-master-gh' into backport-kdnilsen-9d2712dd-master
 - Merge remote-tracking branch 'origin/master' into backport-kdnilsen-9d2712dd-master-gh
 - Revert incorrect resolution of merge conflict
   
   One of the changes recently committed in attempt to resolve merge
   conflict was wrong.
 - Resolve merge conflicts
 - TestAllocIntArrays sometimes fails with aggressive heuristics
   
   This bug has been fixed in TIP.  The fix was not backported to JDK21.
 - Merge remote-tracking branch 'origin/master' into backport-kdnilsen-9d2712dd-master
 - Backport 9d2712ddf39160a618c9c839c46d2510063f45df

-------------

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=05
  Stats: 2389 lines in 21 files changed: 1500 ins; 255 del; 634 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/62.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/62/head:pull/62

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/62

From kdnilsen at openjdk.org  Mon Aug 12 21:44:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 Aug 2024 21:44:35 GMT
Subject: RFR: 8327000: GenShen: Integrate updated Shenandoah implementation
 of FreeSet into GenShen [v7]
In-Reply-To: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
References: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
Message-ID: <FFRuXqBcUZArexxWXH-6gpbFySqTahJ7htGxuSQcO6g=.e9a0c76e-382e-4b47-826b-18a2252fa670@github.com>

> This pull request contains a backport of commit 9d2712dd from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 26 Jun 2024 and was reviewed by William Kemper and Y. Srinivas Ramakrishna.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Another fix to merge conflict resolution

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/62/files/c7a5f935..8df0ef68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=06
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=62&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/62.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/62/head:pull/62

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/62

From kdnilsen at openjdk.org  Mon Aug 12 23:47:56 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 12 Aug 2024 23:47:56 GMT
Subject: RFR: 8325673: GenShen: Share Reserves between Old and Young
 Collector [v12]
In-Reply-To: <WBf_ck4u6wLSZaiQwRzt4yCI0K5CKBBuhlVD6f0KkVk=.d748a279-de3f-492b-b13d-faacd1dad8b5@github.com>
References: <WBf_ck4u6wLSZaiQwRzt4yCI0K5CKBBuhlVD6f0KkVk=.d748a279-de3f-492b-b13d-faacd1dad8b5@github.com>
Message-ID: <esBdZEYcFvVxWFThX65GNzKsQqjUYgbGZ3prbvywjfQ=.377f29ac-b89e-4244-b9b1-67a96bbd63df@github.com>

> Allow young-gen Collector reserve to share memory with old-gen Collector reserve in order to support prompt processing of mixed evacuations, as constrained by ShenandoahOldEvacRatioPercent.

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits:

 - Merge remote-tracking branch 'origin/master' into share-collector-reserves
 - Merge branch 'openjdk:master' into master
 - Cleanups requested by code review
 - Simplify code to rebuild free set after abbreviated and old GC
 - Remove incorrect and unnecessary comments
 - Simplify invocations of freeset rebuild when possible
   
   Most invocations do not need to resize generations between
   prepare_to_rebuild() and finish_rebuild(), so no need to make these two
   independent invocations.
 - Better comments as requested by code review
 - Improve comment
 - Remove unreferenced variables
 - Simplify arguments by using instance variables in ShenandoahOldHeuristics
 - ... and 72 more: https://git.openjdk.org/shenandoah/compare/44f5995b...0e555e81

-------------

Changes: https://git.openjdk.org/shenandoah/pull/395/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=395&range=11
  Stats: 1254 lines in 24 files changed: 658 ins; 350 del; 246 mod
  Patch: https://git.openjdk.org/shenandoah/pull/395.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/395/head:pull/395

PR: https://git.openjdk.org/shenandoah/pull/395

From dholmes at openjdk.org  Tue Aug 13 01:19:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 13 Aug 2024 01:19:47 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <tPGbK9nyimz-6xHNzqrQ9v8UQd32snCltVkqpvDZBNk=.963c9c3b-5fc2-4289-8e0e-86159270c5b3@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

MemType still makes all the "flag" variable names look weird IMO.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2285163251

From shade at openjdk.org  Tue Aug 13 08:14:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Aug 2024 08:14:53 GMT
Subject: RFR: 8338202: Shenandoah: Improve handshake closure labels
In-Reply-To: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
References: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
Message-ID: <f7XEOQDvMI4cg6oH-IddUMV0aXLUDEL9i4a5Dndl6os=.08d336c8-178d-4a13-ba99-6d240fac1726@github.com>

On Mon, 12 Aug 2024 13:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, Shenandoah has a few handshakes that have not very clear names, "ShenandoahRendezvous". Would be good to make them more explicit.
> 
> Before:
> 
> 
> Event: 2.593 Executing VM operation: Shenandoah Init Marking
> Event: 2.594 Executing VM operation: Shenandoah Init Marking done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 2.600 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.605 Executing VM operation: CleanClassLoaderDataMetaspaces
> Event: 2.606 Executing VM operation: CleanClassLoaderDataMetaspaces done
> Event: 2.606 Executing VM operation: Shenandoah Init Update References
> Event: 2.606 Executing VM operation: Shenandoah Init Update References done
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots)
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots) done
> Event: 2.611 Executing VM operation: Shenandoah Final Update References
> Event: 2.611 Executing VM operation: Shenandoah Final Update References done 
> 
> 
> After:
> 
> 
> Event: 1.043 Executing VM operation: Shenandoah Init Marking        
> Event: 1.044 Executing VM operation: Shenandoah Init Marking done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 1.051 Executing VM operation: HandshakeAllThreads (Shenandoah Concurrent Weak...

Thanks all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20549#issuecomment-2285630273

From shade at openjdk.org  Tue Aug 13 08:14:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Aug 2024 08:14:54 GMT
Subject: Integrated: 8338202: Shenandoah: Improve handshake closure labels
In-Reply-To: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
References: <jlE-Rns-rCo-tQs8ASR4vueSEA35nzOlh6YL-zxbkA8=.f49fbec0-6cf2-4c94-8043-9ee237af3f10@github.com>
Message-ID: <nt1BJwf61GJqgH9RiAA5UO6ZRy2rPUATBonx1UDrYMQ=.5d8a0460-7a2b-403b-9b0d-1b1c15c6f8a8@github.com>

On Mon, 12 Aug 2024 13:47:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, Shenandoah has a few handshakes that have not very clear names, "ShenandoahRendezvous". Would be good to make them more explicit.
> 
> Before:
> 
> 
> Event: 2.593 Executing VM operation: Shenandoah Init Marking
> Event: 2.594 Executing VM operation: Shenandoah Init Marking done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake)
> Event: 2.599 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB Handshake) done
> Event: 2.599 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 2.600 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.600 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous)
> Event: 2.604 Executing VM operation: HandshakeAllThreads (ShenandoahRendezvous) done
> Event: 2.605 Executing VM operation: CleanClassLoaderDataMetaspaces
> Event: 2.606 Executing VM operation: CleanClassLoaderDataMetaspaces done
> Event: 2.606 Executing VM operation: Shenandoah Init Update References
> Event: 2.606 Executing VM operation: Shenandoah Init Update References done
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots)
> Event: 2.611 Executing VM operation: HandshakeAllThreads (Shenandoah Update Thread Roots) done
> Event: 2.611 Executing VM operation: Shenandoah Final Update References
> Event: 2.611 Executing VM operation: Shenandoah Final Update References done 
> 
> 
> After:
> 
> 
> Event: 1.043 Executing VM operation: Shenandoah Init Marking        
> Event: 1.044 Executing VM operation: Shenandoah Init Marking done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB)
> Event: 1.050 Executing VM operation: HandshakeAllThreads (Shenandoah Flush SATB) done
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation
> Event: 1.050 Executing VM operation: Shenandoah Final Mark and Start Evacuation done
> Event: 1.051 Executing VM operation: HandshakeAllThreads (Shenandoah Concurrent Weak...

This pull request has now been integrated.

Changeset: ba69ed7c
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba69ed7c58fcf99ed18dfd8840125ddcac9460bb
Stats:     7 lines in 5 files changed: 0 ins; 0 del; 7 mod

8338202: Shenandoah: Improve handshake closure labels

Reviewed-by: rkennke, ysr, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/20549

From wkemper at openjdk.org  Tue Aug 13 16:20:51 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 16:20:51 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v4]
In-Reply-To: <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>
Message-ID: <vMwAFx5_QtjWuzxFxauOxRI7WPpZZp-b7ngaC6WKgno=.b2292188-2f48-495f-9f83-e9dac58c4335@github.com>

On Wed, 7 Aug 2024 13:19:12 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [37.087s][info][gc,stats]   CMR: VM Strong Roots              413 us, workers (us):  64,  57,  52,  47,  38,  31,  30,  25,  20,  21,  17,  10, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats]   CMR: CLDG Roots                   449 us, workers (us):   4, ---, ---, 406, ---,  15, ---,   4,   4, ---, ---,  17, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [37.087s][info][gc,stats] Concurrent Marking                 5002 us
>> [37.087s][info][gc,stats]   SATB Flush Rendezvous            1748 us
>> [37.087s][info][gc,stats] Pause Final Mark (G)              57272 us
>> [37.087s][info][gc,stats] Pause Final Mark (N)              56985 us
>> [37.087s][info][gc,stats]   Finish Mark                       387 us
>> [37.087s][info][gc,stats]   Update Region States              109 us
>> [37.087s][info][gc,stats]   Choose Collection Set           56395 us
>> [37.087s][info][gc,stats]   Rebuild Free Set                   40 us
>> 
>> 
>> on app termination
>> 
>> 
>> [40.640s][info][gc,stats] Concurrent Reset               =    0.914 s (a =    65255 us) (n =    14) (lvls, us =    54883,    55859,    63867,    65234,    97096)
>> [40.640s][info][gc,stats] Pause Init Mark (G)            =    1.755 s (a =   125380 us) (n =    14) (lvls, us =   119141,   123047,   125000,   125000,   128042)
>> [40.640s][info][gc,stats] Pause Init Mark (N)            =    1.697 s (a =   121241 us...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address feedback on code style

Suggest changing phase name in logs for consistency with https://github.com/openjdk/jdk/pull/20549.

src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp line 60:

> 58:   SHENANDOAH_PAR_PHASE_DO(conc_mark_roots,          "  CMR: ", f)                      \
> 59:   f(conc_mark,                                      "Concurrent Marking")              \
> 60:   f(conc_mark_satb_flush_rendezvous,                "  SATB Flush Rendezvous")         \

Could this be "Flush SATB" or "Flush SATB Handshakes" for consistency with https://github.com/openjdk/jdk/pull/20549?

-------------

Changes requested by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20318#pullrequestreview-2236015311
PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1715576931

From shade at openjdk.org  Tue Aug 13 16:24:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Aug 2024 16:24:03 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v4]
In-Reply-To: <vMwAFx5_QtjWuzxFxauOxRI7WPpZZp-b7ngaC6WKgno=.b2292188-2f48-495f-9f83-e9dac58c4335@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>
 <vMwAFx5_QtjWuzxFxauOxRI7WPpZZp-b7ngaC6WKgno=.b2292188-2f48-495f-9f83-e9dac58c4335@github.com>
Message-ID: <TQgzfyi1HtAxr0Aw4rFyegcb4lk4r-9TxcNIr1z8Jkc=.2c719732-3367-473f-9642-dc14e6616f59@github.com>

On Tue, 13 Aug 2024 16:17:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address feedback on code style
>
> src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp line 60:
> 
>> 58:   SHENANDOAH_PAR_PHASE_DO(conc_mark_roots,          "  CMR: ", f)                      \
>> 59:   f(conc_mark,                                      "Concurrent Marking")              \
>> 60:   f(conc_mark_satb_flush_rendezvous,                "  SATB Flush Rendezvous")         \
> 
> Could this be "Flush SATB" or "Flush SATB Handshakes" for consistency with https://github.com/openjdk/jdk/pull/20549?

`Flush SATB` would be good, I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1715581820

From wkemper at openjdk.org  Tue Aug 13 16:24:58 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 16:24:58 GMT
Subject: RFR: 8335865: Shenandoah: Improve THP pretouch after JDK-8315923
In-Reply-To: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
References: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
Message-ID: <rhpjMcTGi-wMSUxRyH2VcrY-du3Z_OTs34to5JkIJnI=.e5bff540-ebd9-4da8-8a38-61ea75996211@github.com>

On Fri, 19 Jul 2024 14:28:24 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

> **Notes**
> os::pretouch is now using madvice now when available and has a fall back to using vm page size [JDK-8315923](https://bugs.openjdk.org/browse/JDK-8315923)
> Hence removing code that sets _pretouch_heap_page_size & _pretouch_bitmap_page_size  in Shenandoah.
> 
> **Testing**
> 
> * Ran test in Linux 5.10 and Linux 6.x and confirmed that there is no regression. I could not replicate the issue or performance improvement though. [add results]
> * Ran [TestTransparentHugePageUsage](https://github.com/openjdk/jdk/commit/a65a89522d2f24b1767e1c74f6689a22ea32ca6a) for Shenandoah and verified that test passed
> * Ran tier 1, tier 2 , tier1_gc_shenandoah, tier2_gc_shenandoah, tier3_gc_shenandoah and hotspot_gc_shenandoah.

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20254#pullrequestreview-2236025646

From gziemski at openjdk.org  Tue Aug 13 16:32:49 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 13 Aug 2024 16:32:49 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <tPGbK9nyimz-6xHNzqrQ9v8UQd32snCltVkqpvDZBNk=.963c9c3b-5fc2-4289-8e0e-86159270c5b3@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tPGbK9nyimz-6xHNzqrQ9v8UQd32snCltVkqpvDZBNk=.963c9c3b-5fc2-4289-8e0e-86159270c5b3@github.com>
Message-ID: <QDU9tdm2DBo-CPmRGjk47yfwxlIQx4afKdCBsPqAzcg=.7c869798-0ef1-4fa0-a1c8-747eecd09fe0@github.com>

On Tue, 13 Aug 2024 01:16:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> MemType still makes all the "flag" variable names look weird IMO.

@dholmes-ora @tstuefe @jdksjolen

Is everyone OK with MemTypeFlag?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2286658061

From nprasad at openjdk.org  Tue Aug 13 16:37:14 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 13 Aug 2024 16:37:14 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v5]
In-Reply-To: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
Message-ID: <tkGiHnHpsZmwAr9L-epe7YGSB0sJJnm15LUla1bRz74=.47581e0e-e2dc-485f-9eb8-73dd7c09c3cb@github.com>

> **Revision 2 Notes** 
> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
> 
> **Revision 1 Notes**
> This PR adds the following
> 1.  info logging on number of SATB flush attempts
> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
> 
> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
> 
> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
> 
> 
> **Testing**
> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
> 2. **-Xlog:gc+stats=info**
> 
> 
> [4.911s][info][gc,stats]   CMR: VM Strong Roots              539 us, workers (us): 102,  89,  89,  79,  46,  40,  40,  25,  24,   1,   2,   2, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [4.911s][info][gc,stats]   CMR: CLDG Roots                   461 us, workers (us): 429,   5,  12,  11,   4, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [4.911s][info][gc,stats] Concurrent Marking                 4392 us
> [4.911s][info][gc,stats]   Flush SATB                       1035 us
> [4.911s][info][gc,stats] Pause Final Mark (G)               2615 us
> [4.912s][info][gc,stats] Pause Final Mark (N)               2339 us
> [4.912s][info][gc,stats]   Finish Mark                       780 us
> [4.912s][info][gc,stats]   Update Region States              109 us
> [4.912s][info][gc,stats]   Choose Collection Set            1336 us
> [4.912s][info][gc,stats]   Rebuild Free Set                   23 us
> 
> 
> on app termination
> 
> 
> 4.924s][info][gc,stats] Concurrent Reset               =    0.042 s (a =     1846 us) (n =    23) (lvls, us =     1113,     1660,     1895,     2031,     2674)
> [4.924s][info][gc,stats] Pause Init Mark (G)            =    0.073 s (a =     3163 us) (n =    23) (lvls, us =     2812,     2949,     3047,     3281,     3790)
> [4.924s][info][gc,stats] Pause Init Mark (N)            =    0.065 s (a =     2810 us) (n =    23) (lvls, us =     2578,     2676,     2793,     2793,     3260)
> [4.924s][info]...

Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:

  Rename phase to Flush SATB

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20318/files
  - new: https://git.openjdk.org/jdk/pull/20318/files/9649c2ca..1609ed50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20318/head:pull/20318

PR: https://git.openjdk.org/jdk/pull/20318

From nprasad at openjdk.org  Tue Aug 13 16:37:15 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 13 Aug 2024 16:37:15 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v4]
In-Reply-To: <TQgzfyi1HtAxr0Aw4rFyegcb4lk4r-9TxcNIr1z8Jkc=.2c719732-3367-473f-9642-dc14e6616f59@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <VJj4h5k63gAfr5Pra3asdmEK3muWMZgK-5fVgdJd9n4=.89944b3a-67fd-47b8-95d1-0bc2546a1175@github.com>
 <vMwAFx5_QtjWuzxFxauOxRI7WPpZZp-b7ngaC6WKgno=.b2292188-2f48-495f-9f83-e9dac58c4335@github.com>
 <TQgzfyi1HtAxr0Aw4rFyegcb4lk4r-9TxcNIr1z8Jkc=.2c719732-3367-473f-9642-dc14e6616f59@github.com>
Message-ID: <Dfgp2m9hOCBMEhDDiG6bLfJPciCEAoNjs2xdssBGpfA=.178655ee-4308-4e2e-be71-f8863064ece2@github.com>

On Tue, 13 Aug 2024 16:21:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp line 60:
>> 
>>> 58:   SHENANDOAH_PAR_PHASE_DO(conc_mark_roots,          "  CMR: ", f)                      \
>>> 59:   f(conc_mark,                                      "Concurrent Marking")              \
>>> 60:   f(conc_mark_satb_flush_rendezvous,                "  SATB Flush Rendezvous")         \
>> 
>> Could this be "Flush SATB" or "Flush SATB Handshakes" for consistency with https://github.com/openjdk/jdk/pull/20549?
>
> `Flush SATB` would be good, I think.

will rename to "Flush STAB"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20318#discussion_r1715601134

From wkemper at openjdk.org  Tue Aug 13 16:39:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 16:39:50 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v2]
In-Reply-To: <fUN_HwDHitJ2e0spqcQbCO2Bj_GJNCGsOeoyfpL9QV0=.1f869cd8-550c-4293-bd85-02f2927f6d10@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <fUN_HwDHitJ2e0spqcQbCO2Bj_GJNCGsOeoyfpL9QV0=.1f869cd8-550c-4293-bd85-02f2927f6d10@github.com>
Message-ID: <exdXCqe7_ZhCWUVUExJSc5maOurLTMI6zJZFSMwpmlo=.9ddc2fd1-933e-424a-90ef-af40f091fd88@github.com>

On Mon, 5 Aug 2024 17:13:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to separate class to unbreak Windows builds

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2540:

> 2538: 
> 2539:   // If the trailing region is not full, we need to adjust its top.
> 2540:   size_t tail = (size % ShenandoahHeapRegion::region_size_words());

Not sure we need this. The free set adjusts top for all humongous regions in the allocation (including the tail): https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L885. What's more, I believe `new_top` is only used during a full GC to sort out `top` once compaction is complete.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20468#pullrequestreview-2236051231
PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1715601238

From nprasad at openjdk.org  Tue Aug 13 16:47:49 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 13 Aug 2024 16:47:49 GMT
Subject: RFR: 8335865: Shenandoah: Improve THP pretouch after JDK-8315923
In-Reply-To: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
References: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
Message-ID: <GE-MeOyO2jBog_92Ci8fEL6MadyowHhbgQW62_Xqmu4=.6b217908-14a3-4700-bbd4-6fb030b69892@github.com>

On Fri, 19 Jul 2024 14:28:24 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

> **Notes**
> os::pretouch is now using madvice now when available and has a fall back to using vm page size [JDK-8315923](https://bugs.openjdk.org/browse/JDK-8315923)
> Hence removing code that sets _pretouch_heap_page_size & _pretouch_bitmap_page_size  in Shenandoah.
> 
> **Testing**
> 
> * Ran test in Linux 5.10 and Linux 6.x and confirmed that there is no regression. I could not replicate the issue or performance improvement though. [add results]
> * Ran [TestTransparentHugePageUsage](https://github.com/openjdk/jdk/commit/a65a89522d2f24b1767e1c74f6689a22ea32ca6a) for Shenandoah and verified that test passed
> * Ran tier 1, tier 2 , tier1_gc_shenandoah, tier2_gc_shenandoah, tier3_gc_shenandoah and hotspot_gc_shenandoah.

Thanks for review & approval.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20254#issuecomment-2286682085

From duke at openjdk.org  Tue Aug 13 16:47:49 2024
From: duke at openjdk.org (duke)
Date: Tue, 13 Aug 2024 16:47:49 GMT
Subject: RFR: 8335865: Shenandoah: Improve THP pretouch after JDK-8315923
In-Reply-To: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
References: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
Message-ID: <V24nbJYPvrvG724AS3eIIVl7zwaXB4R5Qdpota1lRNQ=.52e06556-95de-499e-baa1-aa6b3ce0f6d6@github.com>

On Fri, 19 Jul 2024 14:28:24 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

> **Notes**
> os::pretouch is now using madvice now when available and has a fall back to using vm page size [JDK-8315923](https://bugs.openjdk.org/browse/JDK-8315923)
> Hence removing code that sets _pretouch_heap_page_size & _pretouch_bitmap_page_size  in Shenandoah.
> 
> **Testing**
> 
> * Ran test in Linux 5.10 and Linux 6.x and confirmed that there is no regression. I could not replicate the issue or performance improvement though. [add results]
> * Ran [TestTransparentHugePageUsage](https://github.com/openjdk/jdk/commit/a65a89522d2f24b1767e1c74f6689a22ea32ca6a) for Shenandoah and verified that test passed
> * Ran tier 1, tier 2 , tier1_gc_shenandoah, tier2_gc_shenandoah, tier3_gc_shenandoah and hotspot_gc_shenandoah.

@neethu-prasad 
Your change (at version 736fff5738887dedf1d44a73ec50f6baa3df2fb0) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20254#issuecomment-2286684586

From nprasad at openjdk.org  Tue Aug 13 16:50:25 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 13 Aug 2024 16:50:25 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v6]
In-Reply-To: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
Message-ID: <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>

> **Revision 2 Notes** 
> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
> 
> **Revision 1 Notes**
> This PR adds the following
> 1.  info logging on number of SATB flush attempts
> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
> 
> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
> 
> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
> 
> 
> **Testing**
> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
> 2. **-Xlog:gc+stats=info**
> 
> 
> [4.911s][info][gc,stats]   CMR: VM Strong Roots              539 us, workers (us): 102,  89,  89,  79,  46,  40,  40,  25,  24,   1,   2,   2, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [4.911s][info][gc,stats]   CMR: CLDG Roots                   461 us, workers (us): 429,   5,  12,  11,   4, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [4.911s][info][gc,stats] Concurrent Marking                 4392 us
> [4.911s][info][gc,stats]   Flush SATB                       1035 us
> [4.911s][info][gc,stats] Pause Final Mark (G)               2615 us
> [4.912s][info][gc,stats] Pause Final Mark (N)               2339 us
> [4.912s][info][gc,stats]   Finish Mark                       780 us
> [4.912s][info][gc,stats]   Update Region States              109 us
> [4.912s][info][gc,stats]   Choose Collection Set            1336 us
> [4.912s][info][gc,stats]   Rebuild Free Set                   23 us
> 
> 
> on app termination
> 
> 
> 4.924s][info][gc,stats] Concurrent Reset               =    0.042 s (a =     1846 us) (n =    23) (lvls, us =     1113,     1660,     1895,     2031,     2674)
> [4.924s][info][gc,stats] Pause Init Mark (G)            =    0.073 s (a =     3163 us) (n =    23) (lvls, us =     2812,     2949,     3047,     3281,     3790)
> [4.924s][info][gc,stats] Pause Init Mark (N)            =    0.065 s (a =     2810 us) (n =    23) (lvls, us =     2578,     2676,     2793,     2793,     3260)
> [4.924s][info]...

Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:

  Fix indentation and naming

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20318/files
  - new: https://git.openjdk.org/jdk/pull/20318/files/1609ed50..da599599

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20318&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/20318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20318/head:pull/20318

PR: https://git.openjdk.org/jdk/pull/20318

From shade at openjdk.org  Tue Aug 13 16:50:25 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Aug 2024 16:50:25 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v6]
In-Reply-To: <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
Message-ID: <ZQGk4aWBhYvw7jGpP76U3j_2Ex1nkPoVlvd0gE3Frz4=.e6d93e8d-2f3e-481b-84ce-102a9b81595c@github.com>

On Tue, 13 Aug 2024 16:46:54 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [4.911s][info][gc,stats]   CMR: VM Strong Roots              539 us, workers (us): 102,  89,  89,  79,  46,  40,  40,  25,  24,   1,   2,   2, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats]   CMR: CLDG Roots                   461 us, workers (us): 429,   5,  12,  11,   4, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats] Concurrent Marking                 4392 us
>> [4.911s][info][gc,stats]   Flush SATB                       1035 us
>> [4.911s][info][gc,stats] Pause Final Mark (G)               2615 us
>> [4.912s][info][gc,stats] Pause Final Mark (N)               2339 us
>> [4.912s][info][gc,stats]   Finish Mark                       780 us
>> [4.912s][info][gc,stats]   Update Region States              109 us
>> [4.912s][info][gc,stats]   Choose Collection Set            1336 us
>> [4.912s][info][gc,stats]   Rebuild Free Set                   23 us
>> 
>> 
>> on app termination
>> 
>> 
>> 4.924s][info][gc,stats] Concurrent Reset               =    0.042 s (a =     1846 us) (n =    23) (lvls, us =     1113,     1660,     1895,     2031,     2674)
>> [4.924s][info][gc,stats] Pause Init Mark (G)            =    0.073 s (a =     3163 us) (n =    23) (lvls, us =     2812,     2949,     3047,     3281,     3790)
>> [4.924s][info][gc,stats] Pause Init Mark (N)            =    0.065 s (a =     2810 us) (n =    23) ...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation and naming

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20318#pullrequestreview-2236075482

From wkemper at openjdk.org  Tue Aug 13 16:55:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 16:55:50 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
Message-ID: <c26eSNAsG-cXL2ZDv_yAaIYXE35J48Dl64h7adWLMz8=.74901e74-8948-46a9-a3cb-798691a2a2e4@github.com>

On Wed, 7 Aug 2024 18:50:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
>> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
>> 
>> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
>> 
>> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
>> 
>> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Style touchups
>  - Fixing ShenandoahReferenceProcessor
>  - Verifier fix

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 64:

> 62:   void* _interior_loc;
> 63:   oop _loc;
> 64:   ReferenceIterationMode _ref_mode;

I don't see where this new field is read.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20492#pullrequestreview-2236090705
PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1715627146

From wkemper at openjdk.org  Tue Aug 13 16:59:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 16:59:48 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <c26eSNAsG-cXL2ZDv_yAaIYXE35J48Dl64h7adWLMz8=.74901e74-8948-46a9-a3cb-798691a2a2e4@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
 <c26eSNAsG-cXL2ZDv_yAaIYXE35J48Dl64h7adWLMz8=.74901e74-8948-46a9-a3cb-798691a2a2e4@github.com>
Message-ID: <WvShYHQizmLYJ37ECJvVUWPQUagTAE_ii_edFpirbbw=.ee5a47e3-d57c-438f-a12f-6a093c387f23@github.com>

On Tue, 13 Aug 2024 16:52:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Style touchups
>>  - Fixing ShenandoahReferenceProcessor
>>  - Verifier fix
>
> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 64:
> 
>> 62:   void* _interior_loc;
>> 63:   oop _loc;
>> 64:   ReferenceIterationMode _ref_mode;
> 
> I don't see where this new field is read.

Okay, I see now that `reference_iteration_mode` overrides a virtual method defined in `OopIterateClosure`. Perhaps mark it with `override` for readability?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1715632948

From wkemper at openjdk.org  Tue Aug 13 17:20:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 17:20:50 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v6]
In-Reply-To: <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
Message-ID: <yBM0HgXWz6BTtVcAjUoJadZiCHZC0FmubfMc_Ktc-nI=.b5b98b68-d478-45c3-aa20-728ad3cb5cf6@github.com>

On Tue, 13 Aug 2024 16:50:25 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [4.911s][info][gc,stats]   CMR: VM Strong Roots              539 us, workers (us): 102,  89,  89,  79,  46,  40,  40,  25,  24,   1,   2,   2, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats]   CMR: CLDG Roots                   461 us, workers (us): 429,   5,  12,  11,   4, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats] Concurrent Marking                 4392 us
>> [4.911s][info][gc,stats]   Flush SATB                       1035 us
>> [4.911s][info][gc,stats] Pause Final Mark (G)               2615 us
>> [4.912s][info][gc,stats] Pause Final Mark (N)               2339 us
>> [4.912s][info][gc,stats]   Finish Mark                       780 us
>> [4.912s][info][gc,stats]   Update Region States              109 us
>> [4.912s][info][gc,stats]   Choose Collection Set            1336 us
>> [4.912s][info][gc,stats]   Rebuild Free Set                   23 us
>> 
>> 
>> on app termination
>> 
>> 
>> 4.924s][info][gc,stats] Concurrent Reset               =    0.042 s (a =     1846 us) (n =    23) (lvls, us =     1113,     1660,     1895,     2031,     2674)
>> [4.924s][info][gc,stats] Pause Init Mark (G)            =    0.073 s (a =     3163 us) (n =    23) (lvls, us =     2812,     2949,     3047,     3281,     3790)
>> [4.924s][info][gc,stats] Pause Init Mark (N)            =    0.065 s (a =     2810 us) (n =    23) ...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation and naming

Thank you!

-------------

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20318#pullrequestreview-2236140224

From rkennke at openjdk.org  Tue Aug 13 17:25:50 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 13 Aug 2024 17:25:50 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v6]
In-Reply-To: <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
Message-ID: <A7tDwxwazCZnnaFC_jqr9UxLeVlBGEtLTgbsqIIbg5s=.990619f2-a018-41f6-8238-f329c9919d8f@github.com>

On Tue, 13 Aug 2024 16:50:25 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [4.911s][info][gc,stats]   CMR: VM Strong Roots              539 us, workers (us): 102,  89,  89,  79,  46,  40,  40,  25,  24,   1,   2,   2, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats]   CMR: CLDG Roots                   461 us, workers (us): 429,   5,  12,  11,   4, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats] Concurrent Marking                 4392 us
>> [4.911s][info][gc,stats]   Flush SATB                       1035 us
>> [4.911s][info][gc,stats] Pause Final Mark (G)               2615 us
>> [4.912s][info][gc,stats] Pause Final Mark (N)               2339 us
>> [4.912s][info][gc,stats]   Finish Mark                       780 us
>> [4.912s][info][gc,stats]   Update Region States              109 us
>> [4.912s][info][gc,stats]   Choose Collection Set            1336 us
>> [4.912s][info][gc,stats]   Rebuild Free Set                   23 us
>> 
>> 
>> on app termination
>> 
>> 
>> 4.924s][info][gc,stats] Concurrent Reset               =    0.042 s (a =     1846 us) (n =    23) (lvls, us =     1113,     1660,     1895,     2031,     2674)
>> [4.924s][info][gc,stats] Pause Init Mark (G)            =    0.073 s (a =     3163 us) (n =    23) (lvls, us =     2812,     2949,     3047,     3281,     3790)
>> [4.924s][info][gc,stats] Pause Init Mark (N)            =    0.065 s (a =     2810 us) (n =    23) ...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation and naming

Looks good, thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20318#pullrequestreview-2236150805

From nprasad at openjdk.org  Tue Aug 13 17:26:00 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 13 Aug 2024 17:26:00 GMT
Subject: Integrated: 8335865: Shenandoah: Improve THP pretouch after
 JDK-8315923
In-Reply-To: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
References: <z2Qtm1QGS5O-UfAz3OeUaUW6kpnH2YOTkLpqOq207JM=.bb38511d-9933-43f9-a5fe-677d36167311@github.com>
Message-ID: <Y9CR9Mj18sZE7y4RYOzYFqJxnnEqy7xF6L0uifAqrtM=.0017587f-3e69-47e3-95ba-56e0f36ebdb0@github.com>

On Fri, 19 Jul 2024 14:28:24 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

> **Notes**
> os::pretouch is now using madvice now when available and has a fall back to using vm page size [JDK-8315923](https://bugs.openjdk.org/browse/JDK-8315923)
> Hence removing code that sets _pretouch_heap_page_size & _pretouch_bitmap_page_size  in Shenandoah.
> 
> **Testing**
> 
> * Ran test in Linux 5.10 and Linux 6.x and confirmed that there is no regression. I could not replicate the issue or performance improvement though. [add results]
> * Ran [TestTransparentHugePageUsage](https://github.com/openjdk/jdk/commit/a65a89522d2f24b1767e1c74f6689a22ea32ca6a) for Shenandoah and verified that test passed
> * Ran tier 1, tier 2 , tier1_gc_shenandoah, tier2_gc_shenandoah, tier3_gc_shenandoah and hotspot_gc_shenandoah.

This pull request has now been integrated.

Changeset: 84c3065e
Author:    Neethu Prasad <nprasad at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84c3065e8004122f3455a8c28c8719b2c8111c17
Stats:     18 lines in 1 file changed: 0 ins; 17 del; 1 mod

8335865: Shenandoah: Improve THP pretouch after JDK-8315923

Reviewed-by: shade, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/20254

From rkennke at openjdk.org  Tue Aug 13 17:48:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 13 Aug 2024 17:48:54 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v2]
In-Reply-To: <fUN_HwDHitJ2e0spqcQbCO2Bj_GJNCGsOeoyfpL9QV0=.1f869cd8-550c-4293-bd85-02f2927f6d10@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <fUN_HwDHitJ2e0spqcQbCO2Bj_GJNCGsOeoyfpL9QV0=.1f869cd8-550c-4293-bd85-02f2927f6d10@github.com>
Message-ID: <em8ls9FQFKr3O5avvTTCSyLcQYadl3tM3U43ZaNLAJc=.7c6b0c0c-859c-48d6-9e42-3f20b89dfb44@github.com>

On Mon, 5 Aug 2024 17:13:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move constant to separate class to unbreak Windows builds

Nice work! Only a minor nit/question.

src/hotspot/share/cds/archiveHeapWriter.hpp line 126:

> 124:   // depends on -Xmx, but can never be smaller than 1 * M.
> 125:   // (TODO: Perhaps change to 256K to be compatible with Shenandoah)
> 126:   static constexpr int MIN_GC_REGION_ALIGNMENT = 1 * M;

Couldn't you just move up the constant to the public section?
Also, I'm not sure what's the point of it being constexpr (rather that just const), but that is pre-existing.

-------------

Changes requested by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20468#pullrequestreview-2236189386
PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1715688606

From rkennke at openjdk.org  Tue Aug 13 17:59:49 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 13 Aug 2024 17:59:49 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
Message-ID: <crGb5NyXVdy6L6y-bxy-9x_hizj6gpWf144Oq498aNA=.b6db87e8-404a-4a45-a818-e2a1076a6321@github.com>

On Wed, 7 Aug 2024 18:50:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
>> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
>> 
>> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
>> 
>> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
>> 
>> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Style touchups
>  - Fixing ShenandoahReferenceProcessor
>  - Verifier fix

Mostly looks good, I have a few suggestions.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 748:

> 746: }
> 747: 
> 748: bool ShenandoahHeap::is_in_bounds(const void* p) const {

Is this the same as is_in_reserved()? Do we even need that new method?

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 759:

> 757:     // objects during Full GC across the regions in not yet determinate state.
> 758:     return is_full_gc_move_in_progress() ||
> 759:            heap_region_containing(p)->is_active();

Should this also check against the region bounds?

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 96:

> 94: // Raw referent, it can be dead. You cannot dereference it, only use for nullptr
> 95: // and bitmap checks. The decoding uses a special-case inlined CompressedOops::decode
> 96: // method that bypasses normal oop-ness checks.

If you don't want to be treated like an actual oop, you could return a HeapWord* instead. That's still good enough for null- and bitmap-checking. Not sure if it causes a lot of casting around, if so then it's probably not worth it.

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20492#pullrequestreview-2236206495
PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1715699307
PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1715702322
PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1715705338

From shade at openjdk.org  Tue Aug 13 19:34:51 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Aug 2024 19:34:51 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v2]
In-Reply-To: <exdXCqe7_ZhCWUVUExJSc5maOurLTMI6zJZFSMwpmlo=.9ddc2fd1-933e-424a-90ef-af40f091fd88@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <fUN_HwDHitJ2e0spqcQbCO2Bj_GJNCGsOeoyfpL9QV0=.1f869cd8-550c-4293-bd85-02f2927f6d10@github.com>
 <exdXCqe7_ZhCWUVUExJSc5maOurLTMI6zJZFSMwpmlo=.9ddc2fd1-933e-424a-90ef-af40f091fd88@github.com>
Message-ID: <hrqvT0ZptWd4m18KWTp6h-YF7gBE9lZGH4fYwvcteqs=.f011581e-99c6-4360-8907-799fc891dd0f@github.com>

On Tue, 13 Aug 2024 16:34:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move constant to separate class to unbreak Windows builds
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2540:
> 
>> 2538: 
>> 2539:   // If the trailing region is not full, we need to adjust its top.
>> 2540:   size_t tail = (size % ShenandoahHeapRegion::region_size_words());
> 
> Not sure we need this. The free set adjusts top for all humongous regions in the allocation (including the tail): https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L885. What's more, I believe `new_top` is only used during a full GC to sort out `top` once compaction is complete.

Right, d'oh. Not sure what I was thinking there. I'll drop the block, since the whole thing apparently works without adjusting the top.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1715823681

From nprasad at openjdk.org  Tue Aug 13 19:49:51 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 13 Aug 2024 19:49:51 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v6]
In-Reply-To: <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
Message-ID: <YrMGic0lyZZB0SxIlRR9Oro52H1osq1rBUk-R8aaLZk=.4afbf80e-8333-40eb-be5b-fd762cb710a0@github.com>

On Tue, 13 Aug 2024 16:50:25 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [4.911s][info][gc,stats]   CMR: VM Strong Roots              539 us, workers (us): 102,  89,  89,  79,  46,  40,  40,  25,  24,   1,   2,   2, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats]   CMR: CLDG Roots                   461 us, workers (us): 429,   5,  12,  11,   4, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats] Concurrent Marking                 4392 us
>> [4.911s][info][gc,stats]   Flush SATB                       1035 us
>> [4.911s][info][gc,stats] Pause Final Mark (G)               2615 us
>> [4.912s][info][gc,stats] Pause Final Mark (N)               2339 us
>> [4.912s][info][gc,stats]   Finish Mark                       780 us
>> [4.912s][info][gc,stats]   Update Region States              109 us
>> [4.912s][info][gc,stats]   Choose Collection Set            1336 us
>> [4.912s][info][gc,stats]   Rebuild Free Set                   23 us
>> 
>> 
>> on app termination
>> 
>> 
>> 4.924s][info][gc,stats] Concurrent Reset               =    0.042 s (a =     1846 us) (n =    23) (lvls, us =     1113,     1660,     1895,     2031,     2674)
>> [4.924s][info][gc,stats] Pause Init Mark (G)            =    0.073 s (a =     3163 us) (n =    23) (lvls, us =     2812,     2949,     3047,     3281,     3790)
>> [4.924s][info][gc,stats] Pause Init Mark (N)            =    0.065 s (a =     2810 us) (n =    23) ...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation and naming

Thanks for review & approval.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20318#issuecomment-2287005181

From duke at openjdk.org  Tue Aug 13 19:49:51 2024
From: duke at openjdk.org (duke)
Date: Tue, 13 Aug 2024 19:49:51 GMT
Subject: RFR: 8336742: Shenandoah: Add more verbose logging/stats for mark
 termination attempts [v6]
In-Reply-To: <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
 <GZvWpKP1q2dPGCQjvztqIraO3x6YBQiLkGGsZcs29K4=.fdbe00ff-af15-4e58-b2f8-be6aee020142@github.com>
Message-ID: <fRCUFp5J4ZX-sx4oMaFHqk_nKBmMQRsbzdrONkgXPC4=.f89b22e8-414b-4ce8-a692-bd090ff420d5@github.com>

On Tue, 13 Aug 2024 16:50:25 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

>> **Revision 2 Notes** 
>> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
>> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
>> 
>> **Revision 1 Notes**
>> This PR adds the following
>> 1.  info logging on number of SATB flush attempts
>> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
>> 
>> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
>> 
>> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
>> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
>> 
>> 
>> **Testing**
>> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
>> 2. **-Xlog:gc+stats=info**
>> 
>> 
>> [4.911s][info][gc,stats]   CMR: VM Strong Roots              539 us, workers (us): 102,  89,  89,  79,  46,  40,  40,  25,  24,   1,   2,   2, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats]   CMR: CLDG Roots                   461 us, workers (us): 429,   5,  12,  11,   4, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
>> [4.911s][info][gc,stats] Concurrent Marking                 4392 us
>> [4.911s][info][gc,stats]   Flush SATB                       1035 us
>> [4.911s][info][gc,stats] Pause Final Mark (G)               2615 us
>> [4.912s][info][gc,stats] Pause Final Mark (N)               2339 us
>> [4.912s][info][gc,stats]   Finish Mark                       780 us
>> [4.912s][info][gc,stats]   Update Region States              109 us
>> [4.912s][info][gc,stats]   Choose Collection Set            1336 us
>> [4.912s][info][gc,stats]   Rebuild Free Set                   23 us
>> 
>> 
>> on app termination
>> 
>> 
>> 4.924s][info][gc,stats] Concurrent Reset               =    0.042 s (a =     1846 us) (n =    23) (lvls, us =     1113,     1660,     1895,     2031,     2674)
>> [4.924s][info][gc,stats] Pause Init Mark (G)            =    0.073 s (a =     3163 us) (n =    23) (lvls, us =     2812,     2949,     3047,     3281,     3790)
>> [4.924s][info][gc,stats] Pause Init Mark (N)            =    0.065 s (a =     2810 us) (n =    23) ...
>
> Neethu Prasad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation and naming

@neethu-prasad 
Your change (at version da599599e711a1b435b3ed6b7088f299a8008f7a) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20318#issuecomment-2287007930

From shade at openjdk.org  Tue Aug 13 19:51:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Aug 2024 19:51:10 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v3]
In-Reply-To: <em8ls9FQFKr3O5avvTTCSyLcQYadl3tM3U43ZaNLAJc=.7c6b0c0c-859c-48d6-9e42-3f20b89dfb44@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <fUN_HwDHitJ2e0spqcQbCO2Bj_GJNCGsOeoyfpL9QV0=.1f869cd8-550c-4293-bd85-02f2927f6d10@github.com>
 <em8ls9FQFKr3O5avvTTCSyLcQYadl3tM3U43ZaNLAJc=.7c6b0c0c-859c-48d6-9e42-3f20b89dfb44@github.com>
Message-ID: <-ESSW0ZYc_J37C2REktneBwf3ybOs_RUntRbKQZYy1U=.388e8471-2f5c-4949-866b-4b3511739c22@github.com>

On Tue, 13 Aug 2024 17:41:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Review comments
>>  - Merge branch 'master' into JDK-8293650-shenandoah-archives
>>  - Move constant to separate class to unbreak Windows builds
>>  - Touchups in test
>>  - Basic implementation, works well, passes tests
>
> src/hotspot/share/cds/archiveHeapWriter.hpp line 126:
> 
>> 124:   // depends on -Xmx, but can never be smaller than 1 * M.
>> 125:   // (TODO: Perhaps change to 256K to be compatible with Shenandoah)
>> 126:   static constexpr int MIN_GC_REGION_ALIGNMENT = 1 * M;
> 
> Couldn't you just move up the constant to the public section?
> Also, I'm not sure what's the point of it being constexpr (rather that just const), but that is pre-existing.

Yeah, I had problems with that. But I think I just misplaced the constant the last time around. Let me see what Windows GHA runs have to say about the code in new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1715839754

From shade at openjdk.org  Tue Aug 13 19:51:10 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 13 Aug 2024 19:51:10 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v3]
In-Reply-To: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
Message-ID: <UvSJEMVigFA79Hx0RHcE8xL_ORQmPgmNxtxorWbQfzc=.94b069cb-a9d3-4c0f-9956-90df435c9e9c@github.com>

> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
> 
> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
> 
> Additional testing:
>  - [x] New test
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Review comments
 - Merge branch 'master' into JDK-8293650-shenandoah-archives
 - Move constant to separate class to unbreak Windows builds
 - Touchups in test
 - Basic implementation, works well, passes tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20468/files
  - new: https://git.openjdk.org/jdk/pull/20468/files/3a8fa655..361a67db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=01-02

  Stats: 11518 lines in 407 files changed: 4509 ins; 5515 del; 1494 mod
  Patch: https://git.openjdk.org/jdk/pull/20468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20468/head:pull/20468

PR: https://git.openjdk.org/jdk/pull/20468

From nprasad at openjdk.org  Tue Aug 13 19:58:54 2024
From: nprasad at openjdk.org (Neethu Prasad)
Date: Tue, 13 Aug 2024 19:58:54 GMT
Subject: Integrated: 8336742: Shenandoah: Add more verbose logging/stats for
 mark termination attempts
In-Reply-To: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
References: <LTW7nywl6WNOp-kPkf3bvSLil5-fVyt1VD_iphxbk64=.2e2eb420-5f03-4dd0-b0d1-96df02981330@github.com>
Message-ID: <CDQhZnTCeJNZqA0-4zji9ADP418XEmJQmenWY3D0DKw=.98b99537-73ef-4574-badb-a10646f0ee40@github.com>

On Wed, 24 Jul 2024 19:15:55 GMT, Neethu Prasad <nprasad at openjdk.org> wrote:

> **Revision 2 Notes** 
> 1. Added time spent on handshaking all threads requesting them to flush their SATB buffers as part of GC stats.
> 2. As mentioned in PR feedback, will raise separate PR to adding logging in ShenandoahTimingsTracker.
> 
> **Revision 1 Notes**
> This PR adds the following
> 1.  info logging on number of SATB flush attempts
> 3. total time spend on handshaking all threads requesting them to flush their SATB buffers.
> 
> As suggested by William in [JDK-8336742 ](https://bugs.openjdk.org/browse/JDK-83367420), we can use handshake logging to get time spend and other stats for each handshake.
> 
> [4.515s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1035, Total completion time: 597004 ns
> [4.517s][info][handshake   ] Handshake "Shenandoah Flush SATB Handshake", Targeted threads: 1036, Executed by requesting thread: 1033, Total completion time: 207402 ns
> 
> 
> **Testing**
> 1. tier1, tier2 and hotspot_gc_shenandoah tests.
> 2. **-Xlog:gc+stats=info**
> 
> 
> [4.911s][info][gc,stats]   CMR: VM Strong Roots              539 us, workers (us): 102,  89,  89,  79,  46,  40,  40,  25,  24,   1,   2,   2, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [4.911s][info][gc,stats]   CMR: CLDG Roots                   461 us, workers (us): 429,   5,  12,  11,   4, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, ---, 
> [4.911s][info][gc,stats] Concurrent Marking                 4392 us
> [4.911s][info][gc,stats]   Flush SATB                       1035 us
> [4.911s][info][gc,stats] Pause Final Mark (G)               2615 us
> [4.912s][info][gc,stats] Pause Final Mark (N)               2339 us
> [4.912s][info][gc,stats]   Finish Mark                       780 us
> [4.912s][info][gc,stats]   Update Region States              109 us
> [4.912s][info][gc,stats]   Choose Collection Set            1336 us
> [4.912s][info][gc,stats]   Rebuild Free Set                   23 us
> 
> 
> on app termination
> 
> 
> 4.924s][info][gc,stats] Concurrent Reset               =    0.042 s (a =     1846 us) (n =    23) (lvls, us =     1113,     1660,     1895,     2031,     2674)
> [4.924s][info][gc,stats] Pause Init Mark (G)            =    0.073 s (a =     3163 us) (n =    23) (lvls, us =     2812,     2949,     3047,     3281,     3790)
> [4.924s][info][gc,stats] Pause Init Mark (N)            =    0.065 s (a =     2810 us) (n =    23) (lvls, us =     2578,     2676,     2793,     2793,     3260)
> [4.924s][info]...

This pull request has now been integrated.

Changeset: 90527a57
Author:    Neethu Prasad <nprasad at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90527a57848f452be3be089a703cbc2af2d1657a
Stats:     23 lines in 5 files changed: 10 ins; 1 del; 12 mod

8336742: Shenandoah: Add more verbose logging/stats for mark termination attempts

Reviewed-by: shade, wkemper, rkennke

-------------

PR: https://git.openjdk.org/jdk/pull/20318

From wkemper at openjdk.org  Tue Aug 13 21:12:22 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 21:12:22 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
In-Reply-To: <ifJ35MHPxe2WBy6fKhuodLicTei8Ac1u5rT1SdUfiM4=.e03b9db4-b348-4783-8902-e3d320f31b5a@github.com>
References: <ifJ35MHPxe2WBy6fKhuodLicTei8Ac1u5rT1SdUfiM4=.e03b9db4-b348-4783-8902-e3d320f31b5a@github.com>
Message-ID: <OwrGah-qhJmRgq8rb2t3l_lJMC47VCvQr6O0zitdUcw=.d9e26f2f-2cf9-4756-9b3a-21bb72802e1e@github.com>

On Thu, 1 Aug 2024 14:18:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+1

Superseded by https://github.com/openjdk/shenandoah-jdk21u/pull/71

-------------

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/70#issuecomment-2287142365

From wkemper at openjdk.org  Tue Aug 13 21:12:22 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 21:12:22 GMT
Subject: Withdrawn: Merge openjdk/jdk21u-dev:master
In-Reply-To: <ifJ35MHPxe2WBy6fKhuodLicTei8Ac1u5rT1SdUfiM4=.e03b9db4-b348-4783-8902-e3d320f31b5a@github.com>
References: <ifJ35MHPxe2WBy6fKhuodLicTei8Ac1u5rT1SdUfiM4=.e03b9db4-b348-4783-8902-e3d320f31b5a@github.com>
Message-ID: <8ly9NThsEGo2Qo87CW3l_V2RpFdU7a1uh8ZTKCdkNdo=.dbf61242-bc9e-49c7-867d-dc400117bf5c@github.com>

On Thu, 1 Aug 2024 14:18:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+1

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/70

From wkemper at openjdk.org  Tue Aug 13 21:24:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 21:24:34 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <GYSYkeTt6OJjwSTXboRweQzRYYKk6dv4buunhlverGk=.c2c0e959-829c-4f8e-9b9f-79e8179c09e5@github.com>
References: <GYSYkeTt6OJjwSTXboRweQzRYYKk6dv4buunhlverGk=.c2c0e959-829c-4f8e-9b9f-79e8179c09e5@github.com>
Message-ID: <y3agbHj5LPqqn2zLzbolJCOCYCXw1iPbiQS1-45LHC8=.c0b42d36-2558-492e-ab16-9594e9b9106f@github.com>

> Merges tag jdk-24+9

William Kemper 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/shenandoah/pull/465/files
  - new: https://git.openjdk.org/shenandoah/pull/465/files/e4c7850c..e4c7850c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=465&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=465&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/465.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/465/head:pull/465

PR: https://git.openjdk.org/shenandoah/pull/465

From wkemper at openjdk.org  Tue Aug 13 21:24:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 21:24:35 GMT
Subject: RFR: Merge openjdk/jdk:master
In-Reply-To: <GYSYkeTt6OJjwSTXboRweQzRYYKk6dv4buunhlverGk=.c2c0e959-829c-4f8e-9b9f-79e8179c09e5@github.com>
References: <GYSYkeTt6OJjwSTXboRweQzRYYKk6dv4buunhlverGk=.c2c0e959-829c-4f8e-9b9f-79e8179c09e5@github.com>
Message-ID: <cAc_8XAUPeeGRRo260t0_oZAeZu44PeWygxfsIgtpIs=.b333f485-939a-4b1c-b626-0e9ca68f3886@github.com>

On Fri, 2 Aug 2024 14:10:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+9

Superseded by https://github.com/openjdk/shenandoah/pull/467

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/465#issuecomment-2287158517

From wkemper at openjdk.org  Tue Aug 13 21:24:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 21:24:35 GMT
Subject: Withdrawn: Merge openjdk/jdk:master
In-Reply-To: <GYSYkeTt6OJjwSTXboRweQzRYYKk6dv4buunhlverGk=.c2c0e959-829c-4f8e-9b9f-79e8179c09e5@github.com>
References: <GYSYkeTt6OJjwSTXboRweQzRYYKk6dv4buunhlverGk=.c2c0e959-829c-4f8e-9b9f-79e8179c09e5@github.com>
Message-ID: <RxgUNufC1FYnTZn4Ythg4K3VxSyomOMEElYxcZRuOpM=.e5efcc10-5103-4d08-b29f-24cd9a788d14@github.com>

On Fri, 2 Aug 2024 14:10:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+9

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/shenandoah/pull/465

From wkemper at openjdk.org  Tue Aug 13 21:26:49 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 21:26:49 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <18KKPNbwPRjX4bNMyW9Odo_EvwVdE0BMO5Q36SEtQoI=.4be9569e-cdd3-4ecf-b877-d44998e2214a@github.com>
References: <18KKPNbwPRjX4bNMyW9Odo_EvwVdE0BMO5Q36SEtQoI=.4be9569e-cdd3-4ecf-b877-d44998e2214a@github.com>
Message-ID: <ZSSMEPV38hHgE0bV1Ke2ZfF8MJ2-kh5XNGZdzS4Kp8g=.71df4e39-52e8-4215-a17d-4b54fe841bfe@github.com>

> Merges tag jdk-24+10

William Kemper 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/shenandoah/pull/467/files
  - new: https://git.openjdk.org/shenandoah/pull/467/files/16df9c33..16df9c33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=467&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=467&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/467.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/467/head:pull/467

PR: https://git.openjdk.org/shenandoah/pull/467

From wkemper at openjdk.org  Tue Aug 13 21:26:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 21:26:50 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <18KKPNbwPRjX4bNMyW9Odo_EvwVdE0BMO5Q36SEtQoI=.4be9569e-cdd3-4ecf-b877-d44998e2214a@github.com>
References: <18KKPNbwPRjX4bNMyW9Odo_EvwVdE0BMO5Q36SEtQoI=.4be9569e-cdd3-4ecf-b877-d44998e2214a@github.com>
Message-ID: <dj6ZVA2_buuYp-rmweesolQBQ-tynYkpDgFQWmtA0sg=.1f6493fa-0495-4fb9-be41-d213826b76a7@github.com>

On Fri, 9 Aug 2024 14:11:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+10

This pull request has now been integrated.

Changeset: 56317950
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/56317950e8965bedba3b23cd1228f479528d3ffd
Stats:     12093 lines in 480 files changed: 6377 ins; 3701 del; 2015 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah/pull/467

From wkemper at openjdk.org  Tue Aug 13 23:53:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 13 Aug 2024 23:53:36 GMT
Subject: RFR: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
Message-ID: <oHC6AkdDpV1pqz-xEp4WppYVj8Y0nW3qGN4HQZOj3pQ=.a1b57eab-2b88-490d-9db7-8668a358737a@github.com>

This PR covers a number of small changes to address comments on https://github.com/openjdk/jdk/pull/20395

-------------

Commit messages:
 - Remove unreachable code, revert unintended changes, fix includes

Changes: https://git.openjdk.org/shenandoah/pull/468/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=468&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338341
  Stats: 34 lines in 8 files changed: 1 ins; 26 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah/pull/468.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/468/head:pull/468

PR: https://git.openjdk.org/shenandoah/pull/468

From kdnilsen at openjdk.org  Tue Aug 13 23:59:01 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 13 Aug 2024 23:59:01 GMT
Subject: RFR: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
In-Reply-To: <oHC6AkdDpV1pqz-xEp4WppYVj8Y0nW3qGN4HQZOj3pQ=.a1b57eab-2b88-490d-9db7-8668a358737a@github.com>
References: <oHC6AkdDpV1pqz-xEp4WppYVj8Y0nW3qGN4HQZOj3pQ=.a1b57eab-2b88-490d-9db7-8668a358737a@github.com>
Message-ID: <mJJSYDTm59VKdPhMFL1yBZF8uzqQaBl-TlXU42V93aI=.8abd46c6-0eaf-41f4-8439-2cf2709fcde6@github.com>

On Tue, 13 Aug 2024 23:49:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This PR covers a number of small changes to address comments on https://github.com/openjdk/jdk/pull/20395

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/468#pullrequestreview-2236870098

From wkemper at openjdk.org  Wed Aug 14 00:11:16 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Aug 2024 00:11:16 GMT
Subject: Integrated: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
In-Reply-To: <oHC6AkdDpV1pqz-xEp4WppYVj8Y0nW3qGN4HQZOj3pQ=.a1b57eab-2b88-490d-9db7-8668a358737a@github.com>
References: <oHC6AkdDpV1pqz-xEp4WppYVj8Y0nW3qGN4HQZOj3pQ=.a1b57eab-2b88-490d-9db7-8668a358737a@github.com>
Message-ID: <wQtamnK-Bt-CPdR9gPbzI-zPqd-6sUsxUYzyNj0PlQY=.16ab4108-ac97-4c5c-949a-822b320119a0@github.com>

On Tue, 13 Aug 2024 23:49:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This PR covers a number of small changes to address comments on https://github.com/openjdk/jdk/pull/20395

This pull request has now been integrated.

Changeset: add6eb68
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/add6eb6852a0dcfad4502bbe64c9d2b429aa2819
Stats:     34 lines in 8 files changed: 1 ins; 26 del; 7 mod

8338341: GenShen: Cleanup headers, unreachable code and unintentional changes

Reviewed-by: kdnilsen

-------------

PR: https://git.openjdk.org/shenandoah/pull/468

From ysr at openjdk.org  Wed Aug 14 05:57:15 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 14 Aug 2024 05:57:15 GMT
Subject: RFR: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
In-Reply-To: <oHC6AkdDpV1pqz-xEp4WppYVj8Y0nW3qGN4HQZOj3pQ=.a1b57eab-2b88-490d-9db7-8668a358737a@github.com>
References: <oHC6AkdDpV1pqz-xEp4WppYVj8Y0nW3qGN4HQZOj3pQ=.a1b57eab-2b88-490d-9db7-8668a358737a@github.com>
Message-ID: <Yovo6wgZlrV4TvMgvvVwvPYzFQpbiSog_qb4eMvHT94=.90052014-4530-4f16-a16f-579baf9ca321@github.com>

On Tue, 13 Aug 2024 23:49:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This PR covers a number of small changes to address comments on https://github.com/openjdk/jdk/pull/20395

src/hotspot/share/gc/shared/gcConfiguration.cpp line 75:

> 73: 
> 74:   if (UseShenandoahGC) {
> 75:     return Shenandoah;

@earthling-amzn : Here and at lines 47-52, don't we want to return, much like Gen ZGC does, the (new) values `ShenandoahMinor` and `ShenandoahMajor` -- or ShYoung and ShOld, or ShNew and ShOld, as one prefers -- for the young and old collectors, respectively, in the generational case, and just Shenandoah for both cases in the non-generational case?

Where are the `GCConfiguration::*_collector()` APIs called from?

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/468#discussion_r1716345931

From stefank at openjdk.org  Wed Aug 14 06:56:49 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 14 Aug 2024 06:56:49 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <QDU9tdm2DBo-CPmRGjk47yfwxlIQx4afKdCBsPqAzcg=.7c869798-0ef1-4fa0-a1c8-747eecd09fe0@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tPGbK9nyimz-6xHNzqrQ9v8UQd32snCltVkqpvDZBNk=.963c9c3b-5fc2-4289-8e0e-86159270c5b3@github.com>
 <QDU9tdm2DBo-CPmRGjk47yfwxlIQx4afKdCBsPqAzcg=.7c869798-0ef1-4fa0-a1c8-747eecd09fe0@github.com>
Message-ID: <BCxxtx0vs0W8dnLasLMHlhBcLa41R-7qT6zkhxgDrK8=.a01964b0-d433-4615-9c06-21b281c6829a@github.com>

On Tue, 13 Aug 2024 16:30:01 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Is everyone OK with MemTypeFlag?

It's quite unfortunate to have a three-word type for something this prolific in our code base. Why not go with `MemType` and change variable names from `flag` to `mt`?


  static char* map_memory_to_file(size_t size, int fd, MEMFLAGS flag = mtNone);

would then become:

  static char* map_memory_to_file(size_t size, int fd, MemType mt = mtNone);

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2287987726

From shade at openjdk.org  Wed Aug 14 10:01:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 10:01:09 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v4]
In-Reply-To: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
Message-ID: <b_dI317-0_UlMw29Ujzw8yaQxYCbhw2Z7XhwZ28uyc8=.058bfdca-9f71-412b-9273-0d0e9b7f83f2@github.com>

> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
> 
> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
> 
> Additional testing:
>  - [x] New test
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Work around 32-bit build failure

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20468/files
  - new: https://git.openjdk.org/jdk/pull/20468/files/361a67db..7486a1e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=02-03

  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20468/head:pull/20468

PR: https://git.openjdk.org/jdk/pull/20468

From shade at openjdk.org  Wed Aug 14 10:01:09 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 10:01:09 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v4]
In-Reply-To: <-ESSW0ZYc_J37C2REktneBwf3ybOs_RUntRbKQZYy1U=.388e8471-2f5c-4949-866b-4b3511739c22@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <fUN_HwDHitJ2e0spqcQbCO2Bj_GJNCGsOeoyfpL9QV0=.1f869cd8-550c-4293-bd85-02f2927f6d10@github.com>
 <em8ls9FQFKr3O5avvTTCSyLcQYadl3tM3U43ZaNLAJc=.7c6b0c0c-859c-48d6-9e42-3f20b89dfb44@github.com>
 <-ESSW0ZYc_J37C2REktneBwf3ybOs_RUntRbKQZYy1U=.388e8471-2f5c-4949-866b-4b3511739c22@github.com>
Message-ID: <Ikda5ukA7eLjeR8wn21ENoYZ98WcxRcsOmTGbfU3AuI=.e4b4bd41-bfac-4b9b-88c3-df49abb7f03a@github.com>

On Tue, 13 Aug 2024 19:47:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/cds/archiveHeapWriter.hpp line 126:
>> 
>>> 124:   // depends on -Xmx, but can never be smaller than 1 * M.
>>> 125:   // (TODO: Perhaps change to 256K to be compatible with Shenandoah)
>>> 126:   static constexpr int MIN_GC_REGION_ALIGNMENT = 1 * M;
>> 
>> Couldn't you just move up the constant to the public section?
>> Also, I'm not sure what's the point of it being constexpr (rather that just const), but that is pre-existing.
>
> Yeah, I had problems with that. But I think I just misplaced the constant the last time around. Let me see what Windows GHA runs have to say about the code in new commit.

Ah, now I remember the real reason I did this: I needed the constant out of the `#if INCLUDE_CDS_JAVA_HEAP` block. `INCLUDE_CDS_JAVA_HEAP` is only defined for `#if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64)`. So it breaks 32-bit builds. This will become moot after we remove Shenandoah check for region alignment, so I just worked it around in Shenandoah code now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1716648043

From gziemski at openjdk.org  Wed Aug 14 15:42:51 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 14 Aug 2024 15:42:51 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <BCxxtx0vs0W8dnLasLMHlhBcLa41R-7qT6zkhxgDrK8=.a01964b0-d433-4615-9c06-21b281c6829a@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tPGbK9nyimz-6xHNzqrQ9v8UQd32snCltVkqpvDZBNk=.963c9c3b-5fc2-4289-8e0e-86159270c5b3@github.com>
 <QDU9tdm2DBo-CPmRGjk47yfwxlIQx4afKdCBsPqAzcg=.7c869798-0ef1-4fa0-a1c8-747eecd09fe0@github.com>
 <BCxxtx0vs0W8dnLasLMHlhBcLa41R-7qT6zkhxgDrK8=.a01964b0-d433-4615-9c06-21b281c6829a@github.com>
Message-ID: <q_2Ltc2FufpqLavfrdB7HFsmgRlWCFzD7jVCkkjmbGk=.979e7260-5bf2-46fa-ae28-f5dd5a852cfb@github.com>

On Wed, 14 Aug 2024 06:54:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > Is everyone OK with MemTypeFlag?
> 
> It's quite unfortunate to have a three-word type for something this prolific in our code base. Why not go with `MemType` and change variable names from `flag` to `mt`?
> 
> ```
>   static char* map_memory_to_file(size_t size, int fd, MEMFLAGS flag = mtNone);
> ```
> 
> would then become:
> 
> ```
>   static char* map_memory_to_file(size_t size, int fd, MemType mt = mtNone);
> ```

My initial choice was exactly that, but then I backed-off from renaming the arguments, because how big and intrusive the change it seemed.

David seems to prefer `MemTypeFlag`, so that we don't have to rename all the arguments and I see a point in that, but it wouldn't be my first choice.

Thomas seems to prefer `NMTCat` that I just don't like much, despite that it has NMT prefix in it, for some reason.

If we could find a compromise that we all can live with, despite it not being exactly what every single person wants, then that would be great. We could this in separate steps:

Initial effort (this fix): we rename `MEMFLAGS` to `MemType`

Follow up effort(s): we either rename all arguments in one big push (intrusive) or we do it a file, or related files (like NMT) together at a time in a followup(s) or whenever we are in the file with some related fix. Eventually we would get there, which is better than what we have right now IMHO.

Is this a reasonable compromise to everyone?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2289134648

From thomas.stuefe at gmail.com  Wed Aug 14 16:14:36 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 14 Aug 2024 18:14:36 +0200
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <q_2Ltc2FufpqLavfrdB7HFsmgRlWCFzD7jVCkkjmbGk=.979e7260-5bf2-46fa-ae28-f5dd5a852cfb@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <tPGbK9nyimz-6xHNzqrQ9v8UQd32snCltVkqpvDZBNk=.963c9c3b-5fc2-4289-8e0e-86159270c5b3@github.com>
 <QDU9tdm2DBo-CPmRGjk47yfwxlIQx4afKdCBsPqAzcg=.7c869798-0ef1-4fa0-a1c8-747eecd09fe0@github.com>
 <BCxxtx0vs0W8dnLasLMHlhBcLa41R-7qT6zkhxgDrK8=.a01964b0-d433-4615-9c06-21b281c6829a@github.com>
 <q_2Ltc2FufpqLavfrdB7HFsmgRlWCFzD7jVCkkjmbGk=.979e7260-5bf2-46fa-ae28-f5dd5a852cfb@github.com>
Message-ID: <CAA-vtUw5ZXDMUC+Uwnuy8U4RA374_DB1CQiK6EU=cKMpG3Q6Sg@mail.gmail.com>

I am out sick after JVMLS, typical post conference flu. There is no need to
rush this, right?

I really dislike MemType for its very genericness. MEMFLAGS is a handle
into the NMT subsystem. It has no meaning beyond NMT. Yet, it is spread all
over the code base. Therefore I really would like an NMT prefix, whatever
the name then is. Clear and easy to grep. A very generic name like MemType
or similar will clash with many similar sounding specifiers from other
places. That may not sound so much of an issue if you are only working
within a single hotspot subsystem; but if you work in all corners of the
JDK, you come to like clear succinct names, and an important part of
clearness is scope, and the scope here is NMT.

Just my 5 cent

On Wed 14. Aug 2024 at 17:43, Gerard Ziemski <gziemski at openjdk.org> wrote:

> On Wed, 14 Aug 2024 06:54:22 GMT, Stefan Karlsson <stefank at openjdk.org>
> wrote:
>
> > > Is everyone OK with MemTypeFlag?
> >
> > It's quite unfortunate to have a three-word type for something this
> prolific in our code base. Why not go with `MemType` and change variable
> names from `flag` to `mt`?
> >
> > ```
> >   static char* map_memory_to_file(size_t size, int fd, MEMFLAGS flag =
> mtNone);
> > ```
> >
> > would then become:
> >
> > ```
> >   static char* map_memory_to_file(size_t size, int fd, MemType mt =
> mtNone);
> > ```
>
> My initial choice was exactly that, but then I backed-off from renaming
> the arguments, because how big and intrusive the change it seemed.
>
> David seems to prefer `MemTypeFlag`, so that we don't have to rename all
> the arguments and I see a point in that, but it wouldn't be my first choice.
>
> Thomas seems to prefer `NMTCat` that I just don't like much, despite that
> it has NMT prefix in it, for some reason.
>
> If we could find a compromise that we all can live with, despite it not
> being exactly what every single person wants, then that would be great. We
> could this in separate steps:
>
> Initial effort (this fix): we rename `MEMFLAGS` to `MemType`
>
> Follow up effort(s): we either rename all arguments in one big push
> (intrusive) or we do it a file, or related files (like NMT) together at a
> time in a followup(s) or whenever we are in the file with some related fix.
> Eventually we would get there, which is better than what we have right now
> IMHO.
>
> Is this a reasonable compromise to everyone?
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2289134648
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20240814/a9352880/attachment-0001.htm>

From wkemper at openjdk.org  Wed Aug 14 16:25:11 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Aug 2024 16:25:11 GMT
Subject: RFR: 8338341: GenShen: Cleanup headers,
 unreachable code and unintentional changes
In-Reply-To: <Yovo6wgZlrV4TvMgvvVwvPYzFQpbiSog_qb4eMvHT94=.90052014-4530-4f16-a16f-579baf9ca321@github.com>
References: <oHC6AkdDpV1pqz-xEp4WppYVj8Y0nW3qGN4HQZOj3pQ=.a1b57eab-2b88-490d-9db7-8668a358737a@github.com>
 <Yovo6wgZlrV4TvMgvvVwvPYzFQpbiSog_qb4eMvHT94=.90052014-4530-4f16-a16f-579baf9ca321@github.com>
Message-ID: <wUGb1vVmxhud6elpIFCFjlmalSZgP0tbi-J9Ul2BOfI=.171189a2-9ba6-45e6-9d30-3da0d117f576@github.com>

On Wed, 14 Aug 2024 05:54:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> This PR covers a number of small changes to address comments on https://github.com/openjdk/jdk/pull/20395
>
> src/hotspot/share/gc/shared/gcConfiguration.cpp line 75:
> 
>> 73: 
>> 74:   if (UseShenandoahGC) {
>> 75:     return Shenandoah;
> 
> @earthling-amzn : Here and at lines 47-52, don't we want to return, much like Gen ZGC does, the (new) values `ShenandoahMinor` and `ShenandoahMajor` -- or ShYoung and ShOld, or ShNew and ShOld, as one prefers -- for the young and old collectors, respectively, in the generational case, and just Shenandoah for both cases in the non-generational case?
> 
> Where are the `GCConfiguration::*_collector()` APIs called from?

We could do that on a different PR.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/468#discussion_r1717227337

From shade at openjdk.org  Wed Aug 14 16:30:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 16:30:54 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <WvShYHQizmLYJ37ECJvVUWPQUagTAE_ii_edFpirbbw=.ee5a47e3-d57c-438f-a12f-6a093c387f23@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
 <c26eSNAsG-cXL2ZDv_yAaIYXE35J48Dl64h7adWLMz8=.74901e74-8948-46a9-a3cb-798691a2a2e4@github.com>
 <WvShYHQizmLYJ37ECJvVUWPQUagTAE_ii_edFpirbbw=.ee5a47e3-d57c-438f-a12f-6a093c387f23@github.com>
Message-ID: <fqepxyhjbPd7OLtUDz7-Dw-PFsFGtp8-rRu6WoGhhi8=.4c2122a9-31dc-4ae9-86e9-7fb978e8089c@github.com>

On Tue, 13 Aug 2024 16:57:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 64:
>> 
>>> 62:   void* _interior_loc;
>>> 63:   oop _loc;
>>> 64:   ReferenceIterationMode _ref_mode;
>> 
>> I don't see where this new field is read.
>
> Okay, I see now that `reference_iteration_mode` overrides a virtual method defined in `OopIterateClosure`. Perhaps mark it with `override` for readability?

Right. Since `override` is all-or-nothing, I had to add it to other methods as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717234461

From shade at openjdk.org  Wed Aug 14 16:37:51 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 16:37:51 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <crGb5NyXVdy6L6y-bxy-9x_hizj6gpWf144Oq498aNA=.b6db87e8-404a-4a45-a818-e2a1076a6321@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
 <crGb5NyXVdy6L6y-bxy-9x_hizj6gpWf144Oq498aNA=.b6db87e8-404a-4a45-a818-e2a1076a6321@github.com>
Message-ID: <O6-Exsys3u_B5jyxHahyK7fv8TpWsXRcHq7kxP56iyg=.64d29719-90a5-463a-adb1-af309ce80493@github.com>

On Tue, 13 Aug 2024 17:50:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Style touchups
>>  - Fixing ShenandoahReferenceProcessor
>>  - Verifier fix
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 748:
> 
>> 746: }
>> 747: 
>> 748: bool ShenandoahHeap::is_in_bounds(const void* p) const {
> 
> Is this the same as is_in_reserved()? Do we even need that new method?

Right, we can use `is_in_reserved` instead. In fact, our current method that computes this from the region sizes is not necessary, as the heap regions cover the heap exactly. So we can just as for `is_in_reserved` everywhere, without any loss. Gonna massage the code a bit around this.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 759:
> 
>> 757:     // objects during Full GC across the regions in not yet determinate state.
>> 758:     return is_full_gc_move_in_progress() ||
>> 759:            heap_region_containing(p)->is_active();
> 
> Should this also check against the region bounds?

Not sure I understand. The if-condition checks that we are pointing into heap. This means `heap_region_containing` always returns the region.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717241078
PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717242093

From rkennke at openjdk.org  Wed Aug 14 16:42:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 14 Aug 2024 16:42:52 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <O6-Exsys3u_B5jyxHahyK7fv8TpWsXRcHq7kxP56iyg=.64d29719-90a5-463a-adb1-af309ce80493@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
 <crGb5NyXVdy6L6y-bxy-9x_hizj6gpWf144Oq498aNA=.b6db87e8-404a-4a45-a818-e2a1076a6321@github.com>
 <O6-Exsys3u_B5jyxHahyK7fv8TpWsXRcHq7kxP56iyg=.64d29719-90a5-463a-adb1-af309ce80493@github.com>
Message-ID: <cEJ2lzWgDPNXIhKoc_MGH-BPzy2QdPFfr1bBLxxmiSQ=.9b0d70a6-8913-4255-b092-ce2bafc554c5@github.com>

On Wed, 14 Aug 2024 16:34:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 759:
>> 
>>> 757:     // objects during Full GC across the regions in not yet determinate state.
>>> 758:     return is_full_gc_move_in_progress() ||
>>> 759:            heap_region_containing(p)->is_active();
>> 
>> Should this also check against the region bounds?
>
> Not sure I understand. The if-condition checks that we are pointing into heap. This means `heap_region_containing` always returns the region.

heap_region_containing() returns the region for which bottom <= p < end, my question is if we should check if bottom <= p < top, in other words if p is within the region's currently allocated part (as opposed to the unallocated tail, if any).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717248921

From wkemper at openjdk.org  Wed Aug 14 16:45:49 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Aug 2024 16:45:49 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
Message-ID: <zN5Tl6Bm9LOTXi9fxSgtTpubkuuEwvMNPm-5huCpngQ=.77ff564f-71f8-450e-bb12-b94fdf781242@github.com>

On Wed, 7 Aug 2024 18:50:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
>> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
>> 
>> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
>> 
>> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
>> 
>> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>
> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Style touchups
>  - Fixing ShenandoahReferenceProcessor
>  - Verifier fix

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20492#pullrequestreview-2238701013

From wkemper at openjdk.org  Wed Aug 14 16:48:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Aug 2024 16:48:50 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v4]
In-Reply-To: <b_dI317-0_UlMw29Ujzw8yaQxYCbhw2Z7XhwZ28uyc8=.058bfdca-9f71-412b-9273-0d0e9b7f83f2@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <b_dI317-0_UlMw29Ujzw8yaQxYCbhw2Z7XhwZ28uyc8=.058bfdca-9f71-412b-9273-0d0e9b7f83f2@github.com>
Message-ID: <qjhLYZO1CCoUzmfcgI3-xQXb1rwZUqY9pvQM6sqs7js=.4f4c0277-7210-4532-9f4c-4a8c95e23039@github.com>

On Wed, 14 Aug 2024 10:01:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Work around 32-bit build failure

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20468#pullrequestreview-2238706842

From rkennke at openjdk.org  Wed Aug 14 16:56:51 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 14 Aug 2024 16:56:51 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v4]
In-Reply-To: <b_dI317-0_UlMw29Ujzw8yaQxYCbhw2Z7XhwZ28uyc8=.058bfdca-9f71-412b-9273-0d0e9b7f83f2@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <b_dI317-0_UlMw29Ujzw8yaQxYCbhw2Z7XhwZ28uyc8=.058bfdca-9f71-412b-9273-0d0e9b7f83f2@github.com>
Message-ID: <zoyNII65Kw_r1RsB4qiWSM1GsNJh742FEs87mQwEiOE=.75079a56-7f91-42d9-90cf-cab1e9b66a75@github.com>

On Wed, 14 Aug 2024 10:01:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Work around 32-bit build failure

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2509:

> 2507:   // Pull the constant here, since it is only available when INCLUDE_CDS_JAVA_HEAP is defined.
> 2508:   const size_t min_gc_region_align = 1 * M;
> 2509: #if INCLUDE_CDS_JAVA_HEAP

It makes me wonder if the whole body should perhaps go inside the INCLUDE_CDS_JAVA_HEAP block. It is only ever called from ArchiveHeapLoader, and that doesn's even exist without INCLUDE_CDS_JAVA_HEAP. I leave that up to you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1717265883

From shade at openjdk.org  Wed Aug 14 17:20:51 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 17:20:51 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <crGb5NyXVdy6L6y-bxy-9x_hizj6gpWf144Oq498aNA=.b6db87e8-404a-4a45-a818-e2a1076a6321@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
 <crGb5NyXVdy6L6y-bxy-9x_hizj6gpWf144Oq498aNA=.b6db87e8-404a-4a45-a818-e2a1076a6321@github.com>
Message-ID: <0U2BXwyW7GJ0egzsAtm0gk9fHjaWMRC4KaYPRfZQk3s=.3719560b-9904-43bb-8303-f02dc2a0ceb3@github.com>

On Tue, 13 Aug 2024 17:56:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Style touchups
>>  - Fixing ShenandoahReferenceProcessor
>>  - Verifier fix
>
> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 96:
> 
>> 94: // Raw referent, it can be dead. You cannot dereference it, only use for nullptr
>> 95: // and bitmap checks. The decoding uses a special-case inlined CompressedOops::decode
>> 96: // method that bypasses normal oop-ness checks.
> 
> If you don't want to be treated like an actual oop, you could return a HeapWord* instead. That's still good enough for null- and bitmap-checking. Not sure if it causes a lot of casting around, if so then it's probably not worth it.

Aha, true, let's do `HeapWord*` instead. This clearly shows this is raw memory. I thought it would cause lots of casting around, but I think the marking context actually accepts `HeapWord*` for its real methods, and we only need to massage its API a little bit. In fact, I think it _saves_ a bit on casts now, since we don't have to cast twice: once in `allocated_after_mark_start`, and then for bitmap itself. I have a version for this in the works.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717297480

From wkemper at openjdk.org  Wed Aug 14 17:24:05 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Aug 2024 17:24:05 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <FN42Z-N-VX7yJxv4_uuau2vP7iqWDyk7fzrwsht1ZXs=.4e0048af-8dff-493c-be96-623488789311@github.com>
References: <FN42Z-N-VX7yJxv4_uuau2vP7iqWDyk7fzrwsht1ZXs=.4e0048af-8dff-493c-be96-623488789311@github.com>
Message-ID: <aAg7nAiRtQV8mFgpOJo4XjaFHsyU9riIARQ5MHqbIRM=.648eb326-541b-4755-933d-1816a220c84b@github.com>

> Merges tag jdk-21.0.5+2

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 291 commits:

 - Merge remote-tracking branch 'shenandoah-jdk21u/master' into merge-jdk-21.0.5+2
 - 8333622: ubsan: relocInfo_x86.cpp:101:56: runtime error: pointer index expression with base (-1) overflowed
   
   Backport-of: 33fd6ae98638d2a4b33d18cc4acee4f0daaa9b35
 - 8321509: False positive in get_trampoline fast path causes crash
   
   Backport-of: 73e3e0edeb20c6f701b213423476f92fb05dd262
 - 8331731: ubsan: relocInfo.cpp:155:30: runtime error: applying non-zero offset to null pointer
   
   Reviewed-by: rschmelter
   Backport-of: 664c993c41753843293388a6ff1481a94a5b4c22
 - 8335493: check_gc_overhead_limit should reset SoftRefPolicy::_should_clear_all_soft_refs
   
   Backport-of: cff9e246cc2fbd3914f40bb71daa85dcf7731396
 - 8331854: ubsan: copy.hpp:218:10: runtime error: addition of unsigned offset to 0x7fc2b4024518 overflowed to 0x7fc2b4024510
   
   Backport-of: 2c1b311f81319cee1af574526a91424c2577b78c
 - 8336301: test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO file upon test completion
   
   Backport-of: ae9f318fc35eeab497e546ebab9faed6ec774ec5
 - 8324808: Manual printer tests have no Pass/Fail buttons, instructions close set 3
   
   Backport-of: af7c6af0cc1eb6c42199c05933c7feb032bd6353
 - 8317112: Add screenshot for Frame/DefaultSizeTest.java
   
   Backport-of: a36eaf03afd148581a9d9754f85a652cac84d655
 - 8335967: "text-decoration: none" does not work with "A" HTML tags
   
   Backport-of: 374fca0fcbc049f937fa49bb4825edcbbf961f2b
 - ... and 281 more: https://git.openjdk.org/shenandoah-jdk21u/compare/2cc704b1...38d4e4ba

-------------

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/71/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=71&range=01
  Stats: 49816 lines in 841 files changed: 29427 ins; 15805 del; 4584 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/71.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/71/head:pull/71

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/71

From shade at openjdk.org  Wed Aug 14 17:30:05 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 17:30:05 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
Message-ID: <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>

> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
> 
> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
> 
> Additional testing:
>  - [x] New test
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Wrap the whole thing in CDS define

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20468/files
  - new: https://git.openjdk.org/jdk/pull/20468/files/7486a1e7..d8984aa4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=03-04

  Stats: 13 lines in 1 file changed: 5 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20468/head:pull/20468

PR: https://git.openjdk.org/jdk/pull/20468

From shade at openjdk.org  Wed Aug 14 17:30:06 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 17:30:06 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v4]
In-Reply-To: <zoyNII65Kw_r1RsB4qiWSM1GsNJh742FEs87mQwEiOE=.75079a56-7f91-42d9-90cf-cab1e9b66a75@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <b_dI317-0_UlMw29Ujzw8yaQxYCbhw2Z7XhwZ28uyc8=.058bfdca-9f71-412b-9273-0d0e9b7f83f2@github.com>
 <zoyNII65Kw_r1RsB4qiWSM1GsNJh742FEs87mQwEiOE=.75079a56-7f91-42d9-90cf-cab1e9b66a75@github.com>
Message-ID: <w6T190r8PxVYvw6UEIgxJPLNSH071i5UJD-Wt5i_erI=.30edd559-4978-4d63-a40e-903b8a339c1b@github.com>

On Wed, 14 Aug 2024 16:53:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Work around 32-bit build failure
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2509:
> 
>> 2507:   // Pull the constant here, since it is only available when INCLUDE_CDS_JAVA_HEAP is defined.
>> 2508:   const size_t min_gc_region_align = 1 * M;
>> 2509: #if INCLUDE_CDS_JAVA_HEAP
> 
> It makes me wonder if the whole body should perhaps go inside the INCLUDE_CDS_JAVA_HEAP block. It is only ever called from ArchiveHeapLoader, and that doesn's even exist without INCLUDE_CDS_JAVA_HEAP. I leave that up to you.

That should actually be cleaner. Let's see what 32-bit builds say.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1717308901

From shade at openjdk.org  Wed Aug 14 17:54:51 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 17:54:51 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v4]
In-Reply-To: <w6T190r8PxVYvw6UEIgxJPLNSH071i5UJD-Wt5i_erI=.30edd559-4978-4d63-a40e-903b8a339c1b@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <b_dI317-0_UlMw29Ujzw8yaQxYCbhw2Z7XhwZ28uyc8=.058bfdca-9f71-412b-9273-0d0e9b7f83f2@github.com>
 <zoyNII65Kw_r1RsB4qiWSM1GsNJh742FEs87mQwEiOE=.75079a56-7f91-42d9-90cf-cab1e9b66a75@github.com>
 <w6T190r8PxVYvw6UEIgxJPLNSH071i5UJD-Wt5i_erI=.30edd559-4978-4d63-a40e-903b8a339c1b@github.com>
Message-ID: <GgIPtWRBGGeMhwTz33teXuKDtaYlXpesNlmGWauKHcI=.abb785ef-e05a-4394-a2b7-9e27874af20e@github.com>

On Wed, 14 Aug 2024 17:26:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2509:
>> 
>>> 2507:   // Pull the constant here, since it is only available when INCLUDE_CDS_JAVA_HEAP is defined.
>>> 2508:   const size_t min_gc_region_align = 1 * M;
>>> 2509: #if INCLUDE_CDS_JAVA_HEAP
>> 
>> It makes me wonder if the whole body should perhaps go inside the INCLUDE_CDS_JAVA_HEAP block. It is only ever called from ArchiveHeapLoader, and that doesn's even exist without INCLUDE_CDS_JAVA_HEAP. I leave that up to you.
>
> That should actually be cleaner. Let's see what 32-bit builds say.

Yup, looks like that worked.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1717343327

From shade at openjdk.org  Wed Aug 14 17:58:11 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 17:58:11 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v3]
In-Reply-To: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
Message-ID: <yA01cDNwRDO2_B_HOtuaUXvyEF4twRLUTQo6qjQ2a08=.76e5e418-ee5c-4101-8ed2-1233f6efd93a@github.com>

> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
> 
> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
> 
> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
> 
> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`

Aleksey Shipilev 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:

 - Merge branch 'master' into JDK-8337981-shenandoah-is-in
 - Even stronger is_in check
 - Use is_in_reserved
 - Drop raw_referent to HeapWord*
 - Add some overrides
 - Merge branch 'master' into JDK-8337981-shenandoah-is-in
 - Style touchups
 - Fixing ShenandoahReferenceProcessor
 - Verifier fix
 - Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20492/files
  - new: https://git.openjdk.org/jdk/pull/20492/files/69c66853..0a0859a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20492&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20492&range=01-02

  Stats: 12566 lines in 452 files changed: 5421 ins; 5523 del; 1622 mod
  Patch: https://git.openjdk.org/jdk/pull/20492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20492/head:pull/20492

PR: https://git.openjdk.org/jdk/pull/20492

From shade at openjdk.org  Wed Aug 14 17:58:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 17:58:12 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <cEJ2lzWgDPNXIhKoc_MGH-BPzy2QdPFfr1bBLxxmiSQ=.9b0d70a6-8913-4255-b092-ce2bafc554c5@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
 <crGb5NyXVdy6L6y-bxy-9x_hizj6gpWf144Oq498aNA=.b6db87e8-404a-4a45-a818-e2a1076a6321@github.com>
 <O6-Exsys3u_B5jyxHahyK7fv8TpWsXRcHq7kxP56iyg=.64d29719-90a5-463a-adb1-af309ce80493@github.com>
 <cEJ2lzWgDPNXIhKoc_MGH-BPzy2QdPFfr1bBLxxmiSQ=.9b0d70a6-8913-4255-b092-ce2bafc554c5@github.com>
Message-ID: <coFvBTPmZoxKQ_zWEtSJHaJnt9FfgTKBtsCmePLdLws=.9ccdc8d0-9eaf-4b8a-9f85-619105779131@github.com>

On Wed, 14 Aug 2024 16:40:13 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Not sure I understand. The if-condition checks that we are pointing into heap. This means `heap_region_containing` always returns the region.
>
> heap_region_containing() returns the region for which bottom <= p < end, my question is if we should check if bottom <= p < top, in other words if p is within the region's currently allocated part (as opposed to the unallocated tail, if any).

Right, we should check that as well. Done in new commit, but I have to re-run the tests now, because something might trigger on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717345515

From shade at openjdk.org  Wed Aug 14 18:00:51 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 18:00:51 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
Message-ID: <rBF94HZb57To0vmrcHzYGLjU0dhv6AdYQXd3tqeywpM=.b7a0f019-06d8-49fc-acb9-1f54715cf59b@github.com>

On Wed, 14 Aug 2024 17:30:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap the whole thing in CDS define

@iklam, are you OK to move the `MIN_GC_REGION_ALIGNMENT` like this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20468#issuecomment-2289483974

From rkennke at openjdk.org  Wed Aug 14 18:30:51 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 14 Aug 2024 18:30:51 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
Message-ID: <6HJGTyyvtGoBeqp1FzUVpzY1JloYNHxao66m9DzQaj4=.098327d9-b2c8-45d5-b28a-fc152220f4cb@github.com>

On Wed, 14 Aug 2024 17:30:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap the whole thing in CDS define

Looks good to me now. Thank you!

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20468#pullrequestreview-2238915598

From wkemper at openjdk.org  Wed Aug 14 18:35:20 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Aug 2024 18:35:20 GMT
Subject: RFR: 8338336: GenShen: Cleanup stale TODOs
Message-ID: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>

First batch of stale TODO cleanup. Code changes here are to complete `TODOs` to hoist affiliation check out of closures in full gc and to use `heap locked or safepoint` assert everywhere (which does not require executing thread to be the VMThread).

-------------

Commit messages:
 - Implement TODO to use an API for excluding free regions
 - Remove or rephrase confusing TODO items
 - Remove out-dated TODOs
 - Remove invalid TODO and vestige of IU mode
 - No, we must use a mask to test for a set bit
 - Soften assertion that heap is locked or we're on a safepoint
 - Heap usage accounting should be working now

Changes: https://git.openjdk.org/shenandoah/pull/469/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338336
  Stats: 114 lines in 12 files changed: 3 ins; 83 del; 28 mod
  Patch: https://git.openjdk.org/shenandoah/pull/469.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/469/head:pull/469

PR: https://git.openjdk.org/shenandoah/pull/469

From rkennke at openjdk.org  Wed Aug 14 18:42:54 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 14 Aug 2024 18:42:54 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v3]
In-Reply-To: <yA01cDNwRDO2_B_HOtuaUXvyEF4twRLUTQo6qjQ2a08=.76e5e418-ee5c-4101-8ed2-1233f6efd93a@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <yA01cDNwRDO2_B_HOtuaUXvyEF4twRLUTQo6qjQ2a08=.76e5e418-ee5c-4101-8ed2-1233f6efd93a@github.com>
Message-ID: <UDia7nMiGvOX91_jgZopMr8l6bV6V7101DRhld_PplM=.1f263782-8de8-4119-9025-b3daa2ffd672@github.com>

On Wed, 14 Aug 2024 17:58:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
>> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
>> 
>> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
>> 
>> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
>> 
>> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>
> Aleksey Shipilev 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:
> 
>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>  - Even stronger is_in check
>  - Use is_in_reserved
>  - Drop raw_referent to HeapWord*
>  - Add some overrides
>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>  - Style touchups
>  - Fixing ShenandoahReferenceProcessor
>  - Verifier fix
>  - Fix

Looks good now. You might want to improve the asserts similar to is_in() (up to you).

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 214:

> 212: 
> 213:   ShenandoahHeapRegion* obj_reg = heap->heap_region_containing(obj);
> 214:   if (!heap->is_full_gc_move_in_progress() && !obj_reg->is_active()) {

This is essentially ShenandoahHeap::is_in(), right? Might also want to check for obj < region->top() here? Or use is_in() to begin with?

src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 249:

> 247:     // Step 3. Check that forwardee points to correct region, unless we are in Full GC.
> 248:     if (!heap->is_full_gc_move_in_progress()) {
> 249:       if (!fwd_reg->is_active()) {

Same here?

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 740:

> 738:     // Now check if we point to a live section in active region.
> 739:     ShenandoahHeapRegion* r = heap_region_containing(p);
> 740:     return (r->is_active() && p < r->top());

I'm kinda surprised that there is no ShHeapRegion::is_in() (or variants), but ok. *shrugs*

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20492#pullrequestreview-2238921696
PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717387502
PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717388712
PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1717391321

From kdnilsen at openjdk.org  Wed Aug 14 19:42:09 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 14 Aug 2024 19:42:09 GMT
Subject: RFR: 8338336: GenShen: Cleanup stale TODOs
In-Reply-To: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>
References: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>
Message-ID: <j9rJ34kgy5VhpV9lJMy_sJFvI_uc3jRmvBAe4f6kG1I=.459d6cb0-d770-4548-a3c4-38ebb74656a6@github.com>

On Wed, 14 Aug 2024 18:30:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> First batch of stale TODO cleanup. Code changes here are to complete `TODOs` to hoist affiliation check out of closures in full gc and to use `heap locked or safepoint` assert everywhere (which does not require executing thread to be the VMThread).

Thanks for this cleanup, and for review by @rkennke.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/469#pullrequestreview-2239043411

From wkemper at openjdk.org  Wed Aug 14 20:24:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Aug 2024 20:24:27 GMT
Subject: RFR: 8338420: GenShen: Forward declare card table for Shenandoah
 barrier set
Message-ID: <7BjeLM71edav1zJsEDkTijeX5gZPdtlRBOuEe_ym7C0=.f6bd6db7-f191-4c00-ac89-401160ceb220@github.com>

Forward declare card table, remove completed TODO comment

-------------

Commit messages:
 - Forward declare card table, remove completed TODO comment

Changes: https://git.openjdk.org/shenandoah/pull/470/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=470&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338420
  Stats: 12 lines in 6 files changed: 8 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/470.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/470/head:pull/470

PR: https://git.openjdk.org/shenandoah/pull/470

From ysr at openjdk.org  Wed Aug 14 20:43:09 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 14 Aug 2024 20:43:09 GMT
Subject: RFR: 8338420: GenShen: Forward declare card table for Shenandoah
 barrier set
In-Reply-To: <7BjeLM71edav1zJsEDkTijeX5gZPdtlRBOuEe_ym7C0=.f6bd6db7-f191-4c00-ac89-401160ceb220@github.com>
References: <7BjeLM71edav1zJsEDkTijeX5gZPdtlRBOuEe_ym7C0=.f6bd6db7-f191-4c00-ac89-401160ceb220@github.com>
Message-ID: <-SB17nMIpT_ZqSAAJ-xGAPEDrvFqdVjLkMzY7RzIsyc=.965fc6e4-2c64-4021-be2d-a1e38fca723e@github.com>

On Wed, 14 Aug 2024 20:19:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Forward declare card table, remove completed TODO comment

Marked as reviewed by ysr (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/470#pullrequestreview-2239149640

From duke at openjdk.org  Wed Aug 14 22:18:57 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Wed, 14 Aug 2024 22:18:57 GMT
Subject: RFR: 8336914: Shenandoah: Missing verification steps after JDK-8255765
Message-ID: <L6RJCImMUBDGU4lv7qUFuA5-y9j60dOP3H_bT9TmlQE=.5d583ad9-651c-4973-bd2a-cf8729a6c201@github.com>

Adding before-update-refs verification step which was removed in previous revision [JDK-8255765](https://bugs.openjdk.org/browse/JDK-8255765) as directed by [JDK-8336914](https://bugs.openjdk.org/browse/JDK-8336914)

-------------

Commit messages:
 - Setting update ref to in-progress after verification
 - Adding verify_before_updaterefs() to concurrent op_init_updaterefs()

Changes: https://git.openjdk.org/jdk/pull/20364/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20364&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336914
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20364.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20364/head:pull/20364

PR: https://git.openjdk.org/jdk/pull/20364

From duke at openjdk.org  Wed Aug 14 22:19:01 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Wed, 14 Aug 2024 22:19:01 GMT
Subject: RFR: 8336915: Shenandoah: Remove unused
 ShenandoahVerifier::verify_after_evacuation
Message-ID: <jpYpCndhTcak41VDanAMYugyM3Rbup38P_rtAlzxlkY=.579b1ef4-4990-4732-a6ed-37fb9a552411@github.com>

Removing the `verify_after_evacuation()` function, since last use was removed in [JDK-8240868](https://bugs.openjdk.org/browse/JDK-8240868) as directed by [JDK-8336915](https://bugs.openjdk.org/browse/JDK-8336915)

-------------

Commit messages:
 - Removing verify_after_evacuation()

Changes: https://git.openjdk.org/jdk/pull/20365/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20365&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336915
  Stats: 13 lines in 2 files changed: 0 ins; 13 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20365.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20365/head:pull/20365

PR: https://git.openjdk.org/jdk/pull/20365

From shade at openjdk.org  Wed Aug 14 22:18:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 22:18:57 GMT
Subject: RFR: 8336914: Shenandoah: Missing verification steps after
 JDK-8255765
In-Reply-To: <L6RJCImMUBDGU4lv7qUFuA5-y9j60dOP3H_bT9TmlQE=.5d583ad9-651c-4973-bd2a-cf8729a6c201@github.com>
References: <L6RJCImMUBDGU4lv7qUFuA5-y9j60dOP3H_bT9TmlQE=.5d583ad9-651c-4973-bd2a-cf8729a6c201@github.com>
Message-ID: <9eeovjoPtca79OrDX2gGPPI-1nR_rT6lGCK0wzrLCmY=.edfd77b7-15ea-4dc9-b7df-dc03b8909cfe@github.com>

On Fri, 26 Jul 2024 21:20:27 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

> Adding before-update-refs verification step which was removed in previous revision [JDK-8255765](https://bugs.openjdk.org/browse/JDK-8255765) as directed by [JDK-8336914](https://bugs.openjdk.org/browse/JDK-8336914)

Looks right.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20364#pullrequestreview-2210596385

From shade at openjdk.org  Wed Aug 14 22:19:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 14 Aug 2024 22:19:01 GMT
Subject: RFR: 8336915: Shenandoah: Remove unused
 ShenandoahVerifier::verify_after_evacuation
In-Reply-To: <jpYpCndhTcak41VDanAMYugyM3Rbup38P_rtAlzxlkY=.579b1ef4-4990-4732-a6ed-37fb9a552411@github.com>
References: <jpYpCndhTcak41VDanAMYugyM3Rbup38P_rtAlzxlkY=.579b1ef4-4990-4732-a6ed-37fb9a552411@github.com>
Message-ID: <U6yk4-2mowhteZlmY8Tkd5P9nJ7tGuRmccIA0wbkB5s=.14e510f6-670e-40f7-baf7-2094351c9295@github.com>

On Fri, 26 Jul 2024 21:26:01 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

> Removing the `verify_after_evacuation()` function, since last use was removed in [JDK-8240868](https://bugs.openjdk.org/browse/JDK-8240868) as directed by [JDK-8336915](https://bugs.openjdk.org/browse/JDK-8336915)

This looks fine and trivial.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20365#pullrequestreview-2210573281

From wkemper at openjdk.org  Wed Aug 14 22:35:11 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 14 Aug 2024 22:35:11 GMT
Subject: Integrated: 8338420: GenShen: Forward declare card table for
 Shenandoah barrier set
In-Reply-To: <7BjeLM71edav1zJsEDkTijeX5gZPdtlRBOuEe_ym7C0=.f6bd6db7-f191-4c00-ac89-401160ceb220@github.com>
References: <7BjeLM71edav1zJsEDkTijeX5gZPdtlRBOuEe_ym7C0=.f6bd6db7-f191-4c00-ac89-401160ceb220@github.com>
Message-ID: <dFv_OI163wyD2IMYhQc5KuE7OLhhdGG8cnKD4WbQipk=.8a75ce98-5280-4a23-8fde-4c88bae83c28@github.com>

On Wed, 14 Aug 2024 20:19:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Forward declare card table, remove completed TODO comment

This pull request has now been integrated.

Changeset: 5c94dd64
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/5c94dd648423351837fd6ebfb4e3fec2f6d79f68
Stats:     12 lines in 6 files changed: 8 ins; 4 del; 0 mod

8338420: GenShen: Forward declare card table for Shenandoah barrier set

Reviewed-by: ysr

-------------

PR: https://git.openjdk.org/shenandoah/pull/470

From ysr at openjdk.org  Thu Aug 15 00:23:02 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 15 Aug 2024 00:23:02 GMT
Subject: RFR: 8338336: GenShen: Cleanup stale TODOs
In-Reply-To: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>
References: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>
Message-ID: <uO3EuZ0JGnv8yDQOU-9W0pZaoBAxNvBtCu8pyub2IUc=.4fa0d444-ba84-438b-845f-7eff1b677b28@github.com>

On Wed, 14 Aug 2024 18:30:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> First batch of stale TODO cleanup. Code changes here are to complete `TODOs` to hoist affiliation check out of closures in full gc and to use `heap locked or safepoint` assert everywhere (which does not require executing thread to be the VMThread).

Marked as reviewed by ysr (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/469#pullrequestreview-2239362634

From iklam at openjdk.org  Thu Aug 15 00:50:50 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 Aug 2024 00:50:50 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
Message-ID: <SewYvDc0xrxo61v6G8c6oOjMCn25COlAYX4K4mCuPoY=.43ffb655-aded-40b5-ad37-e84cae8dad9b@github.com>

On Wed, 14 Aug 2024 17:30:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap the whole thing in CDS define

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20468#pullrequestreview-2239392410

From iklam at openjdk.org  Thu Aug 15 00:50:50 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 15 Aug 2024 00:50:50 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <rBF94HZb57To0vmrcHzYGLjU0dhv6AdYQXd3tqeywpM=.b7a0f019-06d8-49fc-acb9-1f54715cf59b@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
 <rBF94HZb57To0vmrcHzYGLjU0dhv6AdYQXd3tqeywpM=.b7a0f019-06d8-49fc-acb9-1f54715cf59b@github.com>
Message-ID: <IDLZg6wZKHVUkpunQwoLANk401C5rZx_tTdt1lOp-vU=.b25adfad-2b3a-4f11-b3e0-984d188459c3@github.com>

On Wed, 14 Aug 2024 17:58:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> @iklam, are you OK to move the `MIN_GC_REGION_ALIGNMENT` like this?

The changes in the CDS code look fine to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20468#issuecomment-2290169886

From dholmes at openjdk.org  Thu Aug 15 01:37:50 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Aug 2024 01:37:50 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <aSpuAgobZeTLeb6vZy2u21kXbbHgIUV10YTgyqn3XMo=.1679b329-1cc0-4cb5-840d-d46c624e8498@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

> I really dislike MemType for its very genericness. MEMFLAGS is a handle into the NMT subsystem. It has no meaning beyond NMT. Yet, it is spread all over the code base. Therefore I really would like an NMT prefix, whatever the name then is.

I agree with @tstuefe here. `MemFlag` and `MemType` sound far too general when this is NMT specific.

My preference to keep the "flags" part of the type was to avoid needing to rename many parameters. The usage of `MEMFLAGS flags` is quite extensive. I would not want to see a partial approach here where we end up with a non-flag type name but a flag variable name.

`NMTTypeFlag` would I hope satisfy Thomas's requirement and avoid the need to do variable renames.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2290293698

From ysr at openjdk.org  Thu Aug 15 02:14:55 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 15 Aug 2024 02:14:55 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
Message-ID: <xKtlKXdAg4RMDVD_eq6VvLfE_eSi6DWT612HQJ8omlo=.cf59eaae-0cb0-4c1e-b75d-40c3bf443f9f@github.com>

On Wed, 14 Aug 2024 17:30:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap the whole thing in CDS define

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2503:

> 2501:   // We need to make sure it looks like regular allocation to the rest of GC.
> 2502: 
> 2503:   // CDS code would guarantee no objects straggle multiple regions, as long as

straggle -> straddle

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1717776848

From ysr at openjdk.org  Thu Aug 15 02:14:55 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 15 Aug 2024 02:14:55 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <xKtlKXdAg4RMDVD_eq6VvLfE_eSi6DWT612HQJ8omlo=.cf59eaae-0cb0-4c1e-b75d-40c3bf443f9f@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
 <xKtlKXdAg4RMDVD_eq6VvLfE_eSi6DWT612HQJ8omlo=.cf59eaae-0cb0-4c1e-b75d-40c3bf443f9f@github.com>
Message-ID: <-VMDmWFhJnNdTmb5O9bb2l64i47hodl2ngHAjjlheMI=.5e6d83aa-c053-4456-914b-10b4903d685b@github.com>

On Thu, 15 Aug 2024 01:48:59 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Wrap the whole thing in CDS define
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2503:
> 
>> 2501:   // We need to make sure it looks like regular allocation to the rest of GC.
>> 2502: 
>> 2503:   // CDS code would guarantee no objects straggle multiple regions, as long as
> 
> straggle -> straddle

Noob question: can one prove that CDS archived objects will never exceed the size of a region? Or does the archive writer refuse to create a dump in that case? I will assume the latter for the purposes of the following remark:

When you walk over the objects allocated in the verifier loop further below at lines 2539-2543, I wonder if you should check that you always have a legitimate object starting and ending each alignment boundary, just to be super-paranoid.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1717791226

From stefank at openjdk.org  Thu Aug 15 06:11:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Aug 2024 06:11:13 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <aSpuAgobZeTLeb6vZy2u21kXbbHgIUV10YTgyqn3XMo=.1679b329-1cc0-4cb5-840d-d46c624e8498@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <aSpuAgobZeTLeb6vZy2u21kXbbHgIUV10YTgyqn3XMo=.1679b329-1cc0-4cb5-840d-d46c624e8498@github.com>
Message-ID: <pX0Uw3i-woU_vZbSjZqDeEVVIM9QLvbni_pozvVtf2M=.22ee8d97-9ade-4139-bed4-07cd85908707@github.com>

On Thu, 15 Aug 2024 01:35:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I agree with @tstuefe here. MemFlag and MemType sound far too general when this is NMT specific.

Yes, it is not very specific, but it also not hard to learn and then know what this type is all about.

> My preference to keep the "flags" part of the type was to avoid needing to rename many parameters. The usage of MEMFLAGS flags is quite extensive. I would not want to see a partial approach here where we end up with a non-flag type name but a flag variable name.

I think we should rename all the 'flags' variables in the same change.

> NMTTypeFlag would I hope satisfy Thomas's requirement and avoid the need to do variable renames.

* To me, that's really not an appealing name for a type that is going to be used by all parts of the HotSpot code base. I much more prefer a shorter name that is easy on the eyes, then a longer and more specific name that is an eyesore.

* And even as a longer name, it doesn't tell what it is going to be used for. What is a Native Memory Tracker Type Flag?

* I don't want us to select a bad name so that we don't have to change the variable names.

* Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.

With all that said, I hope it is clear that we various reviewers have different opinions around this and that we don't integrate this before we have some kind of consensus about the way forward with this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2290734669

From dholmes at openjdk.org  Thu Aug 15 06:33:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 15 Aug 2024 06:33:53 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <pX0Uw3i-woU_vZbSjZqDeEVVIM9QLvbni_pozvVtf2M=.22ee8d97-9ade-4139-bed4-07cd85908707@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <aSpuAgobZeTLeb6vZy2u21kXbbHgIUV10YTgyqn3XMo=.1679b329-1cc0-4cb5-840d-d46c624e8498@github.com>
 <pX0Uw3i-woU_vZbSjZqDeEVVIM9QLvbni_pozvVtf2M=.22ee8d97-9ade-4139-bed4-07cd85908707@github.com>
Message-ID: <ZVP0_QOiwVHjfQgUdgyAf1DaDVQM16rsG1GIDkd1ajg=.ebf04832-282f-45d0-96d2-f73ff8c5d505@github.com>

On Thu, 15 Aug 2024 06:07:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> What is a Native Memory Tracker Type Flag?

It is a flag telling us the type of native memory being tracked.

> Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.

And what does that stand for: memory type? memory tracker? Arguably they should have been nmtGC etc.

> I think we should rename all the 'flags' variables in the same change.

Okay. That's a big change but I'd prefer it to any half-way measures.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2290754399

From kbarrett at openjdk.org  Thu Aug 15 07:20:58 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Aug 2024 07:20:58 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <pX0Uw3i-woU_vZbSjZqDeEVVIM9QLvbni_pozvVtf2M=.22ee8d97-9ade-4139-bed4-07cd85908707@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <aSpuAgobZeTLeb6vZy2u21kXbbHgIUV10YTgyqn3XMo=.1679b329-1cc0-4cb5-840d-d46c624e8498@github.com>
 <pX0Uw3i-woU_vZbSjZqDeEVVIM9QLvbni_pozvVtf2M=.22ee8d97-9ade-4139-bed4-07cd85908707@github.com>
Message-ID: <IN1FNdpJT9z0Rau7A9tOUS3jnadsv29yfIw3rhu1GJo=.7b0f0f72-ec15-407b-b1d3-87d6e914d9ff@github.com>

On Thu, 15 Aug 2024 06:07:49 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > I agree with @tstuefe here. MemFlag and MemType sound far too general when this is NMT specific.
> 
> Yes, it is not very specific, but it also not hard to learn and then know what this type is all about.
> 
> > My preference to keep the "flags" part of the type was to avoid needing to rename many parameters. The usage of MEMFLAGS flags is quite extensive. I would not want to see a partial approach here where we end up with a non-flag type name but a flag variable name.
> 
> I think we should rename all the 'flags' variables in the same change.
> 
> > NMTTypeFlag would I hope satisfy Thomas's requirement and avoid the need to do variable renames.
> 
>     * To me, that's really not an appealing name for a type that is going to be used by all parts of the HotSpot code base. I much more prefer a shorter name that is easy on the eyes, then a longer and more specific name that is an eyesore.
> 
>     * And even as a longer name, it doesn't tell what it is going to be used for. What is a Native Memory Tracker Type Flag?
> 
>     * I don't want us to select a bad name so that we don't have to change the variable names.
> 
>     * Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.
> 
> 
> With all that said, I hope it is clear that we various reviewers have different opinions around this and that we don't integrate this before we have some kind of consensus about the way forward with this.

I strongly agree with everything @stefank said above.  I also think some of the suggestions that have been offered
are not improvements from the status quo, or not enough to be worth the code churn.

The only thing I have against MemType is that "type" is pretty overloaded.  I spent some time with a thesaurus, but
the only alternative I came up with that I liked was MemGroup, but it fails the "mt" prefix consideration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2290801845

From stefank at openjdk.org  Thu Aug 15 07:48:48 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 15 Aug 2024 07:48:48 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <ZVP0_QOiwVHjfQgUdgyAf1DaDVQM16rsG1GIDkd1ajg=.ebf04832-282f-45d0-96d2-f73ff8c5d505@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <aSpuAgobZeTLeb6vZy2u21kXbbHgIUV10YTgyqn3XMo=.1679b329-1cc0-4cb5-840d-d46c624e8498@github.com>
 <pX0Uw3i-woU_vZbSjZqDeEVVIM9QLvbni_pozvVtf2M=.22ee8d97-9ade-4139-bed4-07cd85908707@github.com>
 <ZVP0_QOiwVHjfQgUdgyAf1DaDVQM16rsG1GIDkd1ajg=.ebf04832-282f-45d0-96d2-f73ff8c5d505@github.com>
Message-ID: <UcBV2yp4_ub7w6slErx8iEbVGtJlYNP0vGQedFJxIkE=.6940f028-e9df-41e7-9744-80e8fd397379@github.com>

On Thu, 15 Aug 2024 06:31:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.
> 
> And what does that stand for: memory type? memory tracker? Arguably they should have been nmtGC etc.

The memflags.hpp file says that it's a memory type:

+#define MEMORY_TYPES_DO(f)                                                           \
+  /* Memory type by sub systems. It occupies lower byte. */                          \
+  f(mtJavaHeap,       "Java Heap")   /* Java heap                                 */ \

My guess is that at some point there was an incomplete rename from "memory type".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2290832943

From kbarrett at openjdk.org  Thu Aug 15 08:01:50 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Aug 2024 08:01:50 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <UcBV2yp4_ub7w6slErx8iEbVGtJlYNP0vGQedFJxIkE=.6940f028-e9df-41e7-9744-80e8fd397379@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <aSpuAgobZeTLeb6vZy2u21kXbbHgIUV10YTgyqn3XMo=.1679b329-1cc0-4cb5-840d-d46c624e8498@github.com>
 <pX0Uw3i-woU_vZbSjZqDeEVVIM9QLvbni_pozvVtf2M=.22ee8d97-9ade-4139-bed4-07cd85908707@github.com>
 <ZVP0_QOiwVHjfQgUdgyAf1DaDVQM16rsG1GIDkd1ajg=.ebf04832-282f-45d0-96d2-f73ff8c5d505@github.com>
 <UcBV2yp4_ub7w6slErx8iEbVGtJlYNP0vGQedFJxIkE=.6940f028-e9df-41e7-9744-80e8fd397379@github.com>
Message-ID: <q_5_yCtAdYrOUDNXM6WcwJ0Nr3GiRzHH3pcxiFMMWe8=.82b1465c-1ab1-4d36-b953-c049ce8a362d@github.com>

On Thu, 15 Aug 2024 07:46:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > > Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.
> > 
> > 
> > And what does that stand for: memory type? memory tracker? Arguably they should have been nmtGC etc.
> 
> The memflags.hpp file says that it's a memory type:
> 
> ```
> +#define MEMORY_TYPES_DO(f)                                                           \
> +  /* Memory type by sub systems. It occupies lower byte. */                          \
> +  f(mtJavaHeap,       "Java Heap")   /* Java heap                                 */ \
> ```
> 
> My guess is that at some point there was an incomplete rename from "memory type".

Note that we used to have `typedef MemType MEMFLAGS;`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2290846873

From kbarrett at openjdk.org  Thu Aug 15 08:01:51 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 15 Aug 2024 08:01:51 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <-NKUnExfzAqwhaGAtlJQD81b6wtoEnOhaXF4R779--s=.6d31a953-da4f-4875-8950-6971148ff639@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

The suggestion of "nmtGC" from @daholmes initially looked somewhat appealing
to me. But that then suggests "NMTType" or (better?) "NMTGroup" or something
like that. But I don't much like the look of or typing those acronyms. (Note
that NMTGroup is HotSpot style, not NmtGroup.)

So I'm still preferring "MemType".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2290847405

From shade at openjdk.org  Thu Aug 15 10:00:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 10:00:23 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v6]
In-Reply-To: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
Message-ID: <6Y1uh2FMg3cWFZOl09XPnTBf3KyR81cMdwkwlReWA3A=.49b9fe0a-433d-4ae3-afba-5363e077a7db@github.com>

> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
> 
> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
> 
> Additional testing:
>  - [x] New test
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  More review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20468/files
  - new: https://git.openjdk.org/jdk/pull/20468/files/d8984aa4..1d2d45da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=04-05

  Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20468/head:pull/20468

PR: https://git.openjdk.org/jdk/pull/20468

From shade at openjdk.org  Thu Aug 15 10:00:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 10:00:23 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <-VMDmWFhJnNdTmb5O9bb2l64i47hodl2ngHAjjlheMI=.5e6d83aa-c053-4456-914b-10b4903d685b@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
 <xKtlKXdAg4RMDVD_eq6VvLfE_eSi6DWT612HQJ8omlo=.cf59eaae-0cb0-4c1e-b75d-40c3bf443f9f@github.com>
 <-VMDmWFhJnNdTmb5O9bb2l64i47hodl2ngHAjjlheMI=.5e6d83aa-c053-4456-914b-10b4903d685b@github.com>
Message-ID: <Nnf6kPtzF9bmXZRM05TfhoYT05da62x_VX6FdqwXW5Y=.d28df81e-9dee-424d-93e2-51fa0bf7c5c3@github.com>

On Thu, 15 Aug 2024 02:11:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2503:
>> 
>>> 2501:   // We need to make sure it looks like regular allocation to the rest of GC.
>>> 2502: 
>>> 2503:   // CDS code would guarantee no objects straggle multiple regions, as long as
>> 
>> straggle -> straddle
>
> Noob question: can one prove that CDS archived objects will never exceed the size of a region? Or does the archive writer refuse to create a dump in that case? I will assume the latter for the purposes of the following remark:
> 
> When you walk over the objects allocated in the verifier loop further below at lines 2539-2543, I wonder if you should check that you always have a legitimate object starting and ending each alignment boundary, just to be super-paranoid.

Typo fixed. 

Verifier checks objects are within the regions:
https://github.com/openjdk/jdk/blob/da7311bbe37c2b9632b117d52a77c659047820b7/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp#L143-L144

I think we reasoned that check is too expensive for the regular `shenandoah_assert_correct`. But there is a less used `shenandoah_assert_in_correct_region` that we can co-opt for this check. For testing, I disabled `MIN_ALIGNMENT` bailout, and caught the expected failure:


#
#  Internal Error (/Users/shipilev/Work/shipilev-jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:2541), pid=99715, tid=9987
#  Error: Shenandoah assert_in_correct_region failed; Object end should be within the active area of the region

Referenced from:
  no interior location recorded (probably a plain heap scan, or detached oop)

Object:
  0x00000007c003ffe8 - safe print, no details
  region: |    0|R  |BTE    7c0000000,    7c0040000,    7c0040000|TAMS    7c0000000|UWM    7c0000000|U   256K|T     0B|G     0B|S   256K|L     0B|CP   0

Raw heap memory:
0x00000007c003ffc8:   6f6e2074 61682074 61206576 7365206e   t not have an es
0x00000007c003ffd8:   616d6974 20646574 61727564 6e6f6974   timated duration
0x00000007c003ffe8:   00000001 00000000 001b64c8 0000001b   .........d......
0x00000007c003fff8:   74696e49 206c6169                     Initial


Looking more at this, I think there might be an interaction with humongous threshold if it is smaller than region size. If CDS allocates the object that is larger than our humongous threshold, this new code would effectively allow a "humongous" object to reside in regular region. CDS would not know about this, because it thinks the largest possible object is `MIN_GC_REGION_ALIGNMENT`. I think we would just remove the tunable to avoid any corner cases: https://bugs.openjdk.org/browse/JDK-8338444.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1718210279

From shade at openjdk.org  Thu Aug 15 11:13:58 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 11:13:58 GMT
Subject: RFR: 8338444: Shenandoah: Remove ShenandoahHumongousThreshold tunable
Message-ID: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>

See the bug for rationale.

Additional testing:
  - [ ] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
  - [ ] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/20593/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338444
  Stats: 246 lines in 10 files changed: 4 ins; 234 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20593/head:pull/20593

PR: https://git.openjdk.org/jdk/pull/20593

From wkemper at openjdk.org  Thu Aug 15 14:21:56 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Aug 2024 14:21:56 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <JKIBlgmk9ZKxHhgdoyLc_q76-75St9M_DHvXBeANFls=.28973696-ab2f-4e7b-bc0c-9ea6ccb5611f@github.com>

Merges tag jdk-21.0.5+3

-------------

Commit messages:
 - 8336343: Add more known sysroot library locations for ALSA
 - 8336928: GHA: Bundle artifacts removal broken
 - 8336342: Fix known X11 library locations in sysroot
 - 8337283: configure.log is truncated when build dir is on different filesystem
 - 8327501: Common ForkJoinPool prevents class unloading in some cases
 - 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
 - 8328642: Convert applet test MouseDraggedOutCauseScrollingTest.html to main
 - 8334618: ubsan: support setting additional ubsan check options
 - 8333639: ubsan: cppVtables.cpp:81:55: runtime error: index 14 out of bounds for type 'long int [1]'
 - 8322971: KEM.getInstance() should check if a 3rd-party security provider is signed
 - ... and 291 more: https://git.openjdk.org/shenandoah-jdk21u/compare/a0b3c6cd...75c82f63

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=72&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/72/files
  Stats: 50348 lines in 857 files changed: 29637 ins; 16051 del; 4660 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/72.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/72/head:pull/72

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/72

From rkennke at openjdk.org  Thu Aug 15 15:28:57 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Aug 2024 15:28:57 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v6]
In-Reply-To: <6Y1uh2FMg3cWFZOl09XPnTBf3KyR81cMdwkwlReWA3A=.49b9fe0a-433d-4ae3-afba-5363e077a7db@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <6Y1uh2FMg3cWFZOl09XPnTBf3KyR81cMdwkwlReWA3A=.49b9fe0a-433d-4ae3-afba-5363e077a7db@github.com>
Message-ID: <UCSXMwyJjKbsyPU9x6lfDinuXPmX9nKvAxxFhgPK77Y=.1bc3c7a8-b4de-4f91-8179-762559e716da@github.com>

On Thu, 15 Aug 2024 10:00:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More review comments

Looks good to me!

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20468#pullrequestreview-2240648276

From rkennke at openjdk.org  Thu Aug 15 15:32:50 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Aug 2024 15:32:50 GMT
Subject: RFR: 8338444: Shenandoah: Remove ShenandoahHumongousThreshold
 tunable
In-Reply-To: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
References: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
Message-ID: <ysOxI-od36JIQMvU2cWEsdd6CGsBABCdblyu99hlsm0=.6898ccdf-aaa3-4a0a-97e8-b4a18e69ebce@github.com>

On Thu, 15 Aug 2024 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for rationale.
> 
> Additional testing:
>   - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>   - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Yeah I agree, that makes sense. I don't think anybody would want humongous objects, if they can be avoided, there is no advantage in that, afaict. Patch looks good.

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20593#pullrequestreview-2240656481

From wkemper at openjdk.org  Thu Aug 15 16:01:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Aug 2024 16:01:48 GMT
Subject: RFR: 8338444: Shenandoah: Remove ShenandoahHumongousThreshold
 tunable
In-Reply-To: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
References: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
Message-ID: <qdfHHGF1LE3vhLUnEOBbknS5vJQpf0a_dqeoX-jTL2w=.a3824c8e-998b-4e74-86cd-7647664a64ec@github.com>

On Thu, 15 Aug 2024 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for rationale.
> 
> Additional testing:
>   - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>   - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20593#pullrequestreview-2240724488

From ysr at openjdk.org  Thu Aug 15 16:13:50 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 15 Aug 2024 16:13:50 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v5]
In-Reply-To: <Nnf6kPtzF9bmXZRM05TfhoYT05da62x_VX6FdqwXW5Y=.d28df81e-9dee-424d-93e2-51fa0bf7c5c3@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <Cq25tXG2cUJRykCY3qPXVp44WmJl02ITYCaY-uT7cPk=.201b58d5-ccb5-4f56-b123-32a885dfbc52@github.com>
 <xKtlKXdAg4RMDVD_eq6VvLfE_eSi6DWT612HQJ8omlo=.cf59eaae-0cb0-4c1e-b75d-40c3bf443f9f@github.com>
 <-VMDmWFhJnNdTmb5O9bb2l64i47hodl2ngHAjjlheMI=.5e6d83aa-c053-4456-914b-10b4903d685b@github.com>
 <Nnf6kPtzF9bmXZRM05TfhoYT05da62x_VX6FdqwXW5Y=.d28df81e-9dee-424d-93e2-51fa0bf7c5c3@github.com>
Message-ID: <uIX5th-8R9XzzQ_fN5TKnSrPQ6JcPAZjss5E5ErCk4M=.191cee00-3542-4e04-accb-8ecf15d2897d@github.com>

On Thu, 15 Aug 2024 09:56:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noob question: can one prove that CDS archived objects will never exceed the size of a region? Or does the archive writer refuse to create a dump in that case? I will assume the latter for the purposes of the following remark:
>> 
>> When you walk over the objects allocated in the verifier loop further below at lines 2539-2543, I wonder if you should check that you always have a legitimate object starting and ending each alignment boundary, just to be super-paranoid.
>
> Typo fixed. 
> 
> Verifier checks objects are within the regions:
> https://github.com/openjdk/jdk/blob/da7311bbe37c2b9632b117d52a77c659047820b7/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp#L143-L144
> 
> I think we reasoned that check is too expensive for the regular `shenandoah_assert_correct`. But there is a less used `shenandoah_assert_in_correct_region` that we can co-opt for this check. For testing, I disabled `MIN_ALIGNMENT` bailout, and caught the expected failure:
> 
> 
> #
> #  Internal Error (/Users/shipilev/Work/shipilev-jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:2541), pid=99715, tid=9987
> #  Error: Shenandoah assert_in_correct_region failed; Object end should be within the active area of the region
> 
> Referenced from:
>   no interior location recorded (probably a plain heap scan, or detached oop)
> 
> Object:
>   0x00000007c003ffe8 - safe print, no details
>   region: |    0|R  |BTE    7c0000000,    7c0040000,    7c0040000|TAMS    7c0000000|UWM    7c0000000|U   256K|T     0B|G     0B|S   256K|L     0B|CP   0
> 
> Raw heap memory:
> 0x00000007c003ffc8:   6f6e2074 61682074 61206576 7365206e   t not have an es
> 0x00000007c003ffd8:   616d6974 20646574 61727564 6e6f6974   timated duration
> 0x00000007c003ffe8:   00000001 00000000 001b64c8 0000001b   .........d......
> 0x00000007c003fff8:   74696e49 206c6169                     Initial
> 
> 
> Looking more at this, I think there might be an interaction with humongous threshold if it is smaller than region size. If CDS allocates the object that is larger than our humongous threshold, this new code would effectively allow a "humongous" object to reside in regular region. CDS would not know about this, because it thinks the largest possible object is `MIN_GC_REGION_ALIGNMENT`. I think we would just remove the tunable to avoid any corner cases: https://bugs.openjdk.org/browse/JDK-8338444.

Sounds good, thanks for checking this and tightening these issues!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20468#discussion_r1718632237

From ysr at openjdk.org  Thu Aug 15 16:18:49 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 15 Aug 2024 16:18:49 GMT
Subject: RFR: 8338444: Shenandoah: Remove ShenandoahHumongousThreshold
 tunable
In-Reply-To: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
References: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
Message-ID: <tZs-min8N1oXojVrZWLpe5c_tcsOv-m9ruuAa0hkcmk=.5bf29484-5e45-4a62-9e4d-c6577a720535@github.com>

On Thu, 15 Aug 2024 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for rationale.
> 
> Additional testing:
>   - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>   - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Marked as reviewed by ysr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20593#pullrequestreview-2240762386

From shade at openjdk.org  Thu Aug 15 16:48:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 16:48:52 GMT
Subject: RFR: 8338444: Shenandoah: Remove ShenandoahHumongousThreshold
 tunable
In-Reply-To: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
References: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
Message-ID: <Cdwzxk69KWAAARG5g_aI2Dq3wY8wh5b5IMlhr8l2xYY=.d8be49c3-14f2-4cae-aed3-df64f706a30e@github.com>

On Thu, 15 Aug 2024 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for rationale.
> 
> Additional testing:
>   - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>   - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Thank you all!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20593#issuecomment-2291697545

From shade at openjdk.org  Thu Aug 15 16:48:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 16:48:53 GMT
Subject: Integrated: 8338444: Shenandoah: Remove ShenandoahHumongousThreshold
 tunable
In-Reply-To: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
References: <UFe_JnHmLpIfd5QjImPA5l6pKdGyoaQjfEKe1-QxVCw=.74056d38-0dc0-4ef7-a368-4040910e9bd0@github.com>
Message-ID: <CiJ1gbiFjkOTLrTfLSQHhX8RDUdDQmAzv-GckiNrVtE=.641b5df7-e35a-4335-bb3d-a2ea8796d969@github.com>

On Thu, 15 Aug 2024 11:10:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for rationale.
> 
> Additional testing:
>   - [x] Linux AArch64 server fastdebug, `hotspot_gc_shenandoah`
>   - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

This pull request has now been integrated.

Changeset: ef54af39
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef54af39883e76c80a3e012ed91b90973da51bb4
Stats:     246 lines in 10 files changed: 4 ins; 234 del; 8 mod

8338444: Shenandoah: Remove ShenandoahHumongousThreshold tunable

Reviewed-by: rkennke, wkemper, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/20593

From duke at openjdk.org  Thu Aug 15 16:49:58 2024
From: duke at openjdk.org (duke)
Date: Thu, 15 Aug 2024 16:49:58 GMT
Subject: RFR: 8336914: Shenandoah: Missing verification steps after
 JDK-8255765
In-Reply-To: <L6RJCImMUBDGU4lv7qUFuA5-y9j60dOP3H_bT9TmlQE=.5d583ad9-651c-4973-bd2a-cf8729a6c201@github.com>
References: <L6RJCImMUBDGU4lv7qUFuA5-y9j60dOP3H_bT9TmlQE=.5d583ad9-651c-4973-bd2a-cf8729a6c201@github.com>
Message-ID: <d5r0xEXr5Ui_U5oea3xbrF6AKujEotay7fmpbYp8sHI=.a98b94e8-3269-4c19-b0d9-ab2176e32b07@github.com>

On Fri, 26 Jul 2024 21:20:27 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

> Adding before-update-refs verification step which was removed in previous revision [JDK-8255765](https://bugs.openjdk.org/browse/JDK-8255765) as directed by [JDK-8336914](https://bugs.openjdk.org/browse/JDK-8336914)

@satyenme 
Your change (at version 56ddb4a5c670bf7eeb4fa4f2436412ddb57a371c) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20364#issuecomment-2291699568

From duke at openjdk.org  Thu Aug 15 16:49:58 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Thu, 15 Aug 2024 16:49:58 GMT
Subject: Integrated: 8336914: Shenandoah: Missing verification steps after
 JDK-8255765
In-Reply-To: <L6RJCImMUBDGU4lv7qUFuA5-y9j60dOP3H_bT9TmlQE=.5d583ad9-651c-4973-bd2a-cf8729a6c201@github.com>
References: <L6RJCImMUBDGU4lv7qUFuA5-y9j60dOP3H_bT9TmlQE=.5d583ad9-651c-4973-bd2a-cf8729a6c201@github.com>
Message-ID: <TtGxVWsuo_SkgofMFvWt4PHX3wy31F4ZmITi2hinY8E=.4eb9c051-0283-4003-acda-f96c9951b7fa@github.com>

On Fri, 26 Jul 2024 21:20:27 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

> Adding before-update-refs verification step which was removed in previous revision [JDK-8255765](https://bugs.openjdk.org/browse/JDK-8255765) as directed by [JDK-8336914](https://bugs.openjdk.org/browse/JDK-8336914)

This pull request has now been integrated.

Changeset: e51e40c2
Author:    Satyen Subramaniam <satyenme at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e51e40c2b9f51d012c01407e0b8dadaab464753e
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8336914: Shenandoah: Missing verification steps after JDK-8255765

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/jdk/pull/20364

From duke at openjdk.org  Thu Aug 15 16:50:55 2024
From: duke at openjdk.org (duke)
Date: Thu, 15 Aug 2024 16:50:55 GMT
Subject: RFR: 8336915: Shenandoah: Remove unused
 ShenandoahVerifier::verify_after_evacuation
In-Reply-To: <jpYpCndhTcak41VDanAMYugyM3Rbup38P_rtAlzxlkY=.579b1ef4-4990-4732-a6ed-37fb9a552411@github.com>
References: <jpYpCndhTcak41VDanAMYugyM3Rbup38P_rtAlzxlkY=.579b1ef4-4990-4732-a6ed-37fb9a552411@github.com>
Message-ID: <5sqCY3fLA6fRX-P-k3PzQctEuAHZDpQawVkO418ZXo4=.ed67066d-9ac1-4ad2-8daa-7111f26d6dbd@github.com>

On Fri, 26 Jul 2024 21:26:01 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

> Removing the `verify_after_evacuation()` function, since last use was removed in [JDK-8240868](https://bugs.openjdk.org/browse/JDK-8240868) as directed by [JDK-8336915](https://bugs.openjdk.org/browse/JDK-8336915)

@satyenme 
Your change (at version b28884204d277460da82f309481724f9b87d2c28) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20365#issuecomment-2291701903

From duke at openjdk.org  Thu Aug 15 16:50:55 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Thu, 15 Aug 2024 16:50:55 GMT
Subject: Integrated: 8336915: Shenandoah: Remove unused
 ShenandoahVerifier::verify_after_evacuation
In-Reply-To: <jpYpCndhTcak41VDanAMYugyM3Rbup38P_rtAlzxlkY=.579b1ef4-4990-4732-a6ed-37fb9a552411@github.com>
References: <jpYpCndhTcak41VDanAMYugyM3Rbup38P_rtAlzxlkY=.579b1ef4-4990-4732-a6ed-37fb9a552411@github.com>
Message-ID: <6b7P_bRKAyfp4a34tdXlaRMAaXD4Cdn6fK9BlEkXHHM=.9d00c3a5-258a-4390-b6ec-4ab285c20f40@github.com>

On Fri, 26 Jul 2024 21:26:01 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

> Removing the `verify_after_evacuation()` function, since last use was removed in [JDK-8240868](https://bugs.openjdk.org/browse/JDK-8240868) as directed by [JDK-8336915](https://bugs.openjdk.org/browse/JDK-8336915)

This pull request has now been integrated.

Changeset: f308b2d5
Author:    Satyen Subramaniam <satyenme at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f308b2d59672b39ddca502baff50ab20ab781047
Stats:     13 lines in 2 files changed: 0 ins; 13 del; 0 mod

8336915: Shenandoah: Remove unused ShenandoahVerifier::verify_after_evacuation

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/jdk/pull/20365

From shade at openjdk.org  Thu Aug 15 17:27:23 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 17:27:23 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v7]
In-Reply-To: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
Message-ID: <oEqlzpd3aqMO5hXlJHwFIhaI58UNpnvUqnUpHMVM5Gc=.ff9459c5-6153-4f42-b6db-a099a979507b@github.com>

> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
> 
> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
> 
> Additional testing:
>  - [x] New test
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into JDK-8293650-shenandoah-archives
 - More review comments
 - Wrap the whole thing in CDS define
 - Work around 32-bit build failure
 - Review comments
 - Merge branch 'master' into JDK-8293650-shenandoah-archives
 - Move constant to separate class to unbreak Windows builds
 - Touchups in test
 - Basic implementation, works well, passes tests

-------------

Changes: https://git.openjdk.org/jdk/pull/20468/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20468&range=06
  Stats: 201 lines in 7 files changed: 189 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20468.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20468/head:pull/20468

PR: https://git.openjdk.org/jdk/pull/20468

From wkemper at openjdk.org  Thu Aug 15 18:05:23 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Aug 2024 18:05:23 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <FN42Z-N-VX7yJxv4_uuau2vP7iqWDyk7fzrwsht1ZXs=.4e0048af-8dff-493c-be96-623488789311@github.com>
References: <FN42Z-N-VX7yJxv4_uuau2vP7iqWDyk7fzrwsht1ZXs=.4e0048af-8dff-493c-be96-623488789311@github.com>
Message-ID: <VBO2izRZkPCWAfGQqpSGS6pLbdqVKqE7KKT4sZWgYuA=.cf0c115b-b03c-44ed-8710-73914a4af318@github.com>

On Thu, 8 Aug 2024 14:17:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+2

This pull request has now been integrated.

Changeset: 59b85cf9
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/59b85cf9c65bdf94aef51d951c236c5c50bfe45f
Stats:     49816 lines in 841 files changed: 29427 ins; 15805 del; 4584 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/71

From wkemper at openjdk.org  Thu Aug 15 18:11:43 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Aug 2024 18:11:43 GMT
Subject: Integrated: 8338336: GenShen: Cleanup stale TODOs
In-Reply-To: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>
References: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>
Message-ID: <Oxme07_9xgQ789lagdQOe7L34It04rY9SYl76rZY4Gk=.158e6ac0-2f2e-465f-8968-bf3dead05e6f@github.com>

On Wed, 14 Aug 2024 18:30:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> First batch of stale TODO cleanup. Code changes here are to complete `TODOs` to hoist affiliation check out of closures in full gc and to use `heap locked or safepoint` assert everywhere (which does not require executing thread to be the VMThread).

This pull request has now been integrated.

Changeset: d310008b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/d310008b7874ae6dd4354fb23b8e01fab254038c
Stats:     114 lines in 12 files changed: 3 ins; 83 del; 28 mod

8338336: GenShen: Cleanup stale TODOs

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/shenandoah/pull/469

From wkemper at openjdk.org  Thu Aug 15 18:11:43 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Aug 2024 18:11:43 GMT
Subject: RFR: 8338336: GenShen: Cleanup stale TODOs [v2]
In-Reply-To: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>
References: <-b978ICITEUYny9Ru0r8MOcrFurp_kuG7XJyPD7QJec=.d3f455b0-8eae-419c-9370-311b8d7cb9c5@github.com>
Message-ID: <dDF1yHbdqrwMmJIIePgyLni2wOtECdyLV5xe6RCkZqA=.d07e4f8e-b4e5-47c0-b76d-ace2815fe349@github.com>

> First batch of stale TODO cleanup. Code changes here are to complete `TODOs` to hoist affiliation check out of closures in full gc and to use `heap locked or safepoint` assert everywhere (which does not require executing thread to be the VMThread).

William Kemper 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 eight additional commits since the last revision:

 - Merge remote-tracking branch 'shenandoah/master' into fix-stale-todos
 - Implement TODO to use an API for excluding free regions
 - Remove or rephrase confusing TODO items
 - Remove out-dated TODOs
 - Remove invalid TODO and vestige of IU mode
 - No, we must use a mask to test for a set bit
 - Soften assertion that heap is locked or we're on a safepoint
 - Heap usage accounting should be working now

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/469/files
  - new: https://git.openjdk.org/shenandoah/pull/469/files/3b368834..40fca6e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=469&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=469&range=00-01

  Stats: 46 lines in 14 files changed: 9 ins; 30 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah/pull/469.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/469/head:pull/469

PR: https://git.openjdk.org/shenandoah/pull/469

From wkemper at openjdk.org  Thu Aug 15 18:28:49 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Aug 2024 18:28:49 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <JKIBlgmk9ZKxHhgdoyLc_q76-75St9M_DHvXBeANFls=.28973696-ab2f-4e7b-bc0c-9ea6ccb5611f@github.com>
References: <JKIBlgmk9ZKxHhgdoyLc_q76-75St9M_DHvXBeANFls=.28973696-ab2f-4e7b-bc0c-9ea6ccb5611f@github.com>
Message-ID: <1yP2v6cCVOkqp6N6MSZElslViHdlgkzGws0nMF5Zu1U=.63a204d2-9ecc-44cf-986e-a4d2ac40eaf5@github.com>

> Merges tag jdk-21.0.5+3

William Kemper 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/shenandoah-jdk21u/pull/72/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/72/files/75c82f63..75c82f63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=72&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=72&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/72.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/72/head:pull/72

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/72

From shade at openjdk.org  Thu Aug 15 20:15:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 20:15:54 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v7]
In-Reply-To: <oEqlzpd3aqMO5hXlJHwFIhaI58UNpnvUqnUpHMVM5Gc=.ff9459c5-6153-4f42-b6db-a099a979507b@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <oEqlzpd3aqMO5hXlJHwFIhaI58UNpnvUqnUpHMVM5Gc=.ff9459c5-6153-4f42-b6db-a099a979507b@github.com>
Message-ID: <0kjwFmSmNp3f6qR5fCXSRXl6hnAG1zfvTTVrux6tF_g=.e497cb6b-f16a-430d-bb4b-704184176c97@github.com>

On Thu, 15 Aug 2024 17:27:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into JDK-8293650-shenandoah-archives
>  - More review comments
>  - Wrap the whole thing in CDS define
>  - Work around 32-bit build failure
>  - Review comments
>  - Merge branch 'master' into JDK-8293650-shenandoah-archives
>  - Move constant to separate class to unbreak Windows builds
>  - Touchups in test
>  - Basic implementation, works well, passes tests

Had to remerge with current state of master, which unfortunately invalidated reviews. Need another ack, please :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20468#issuecomment-2292141755

From rkennke at openjdk.org  Thu Aug 15 20:26:53 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 15 Aug 2024 20:26:53 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v7]
In-Reply-To: <oEqlzpd3aqMO5hXlJHwFIhaI58UNpnvUqnUpHMVM5Gc=.ff9459c5-6153-4f42-b6db-a099a979507b@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <oEqlzpd3aqMO5hXlJHwFIhaI58UNpnvUqnUpHMVM5Gc=.ff9459c5-6153-4f42-b6db-a099a979507b@github.com>
Message-ID: <XzPxX52GknMiDD1aRWF7ketuP_ASU1Fh2wvqbmXA1N0=.931c4609-a348-4ffa-be87-1fbd34b5c0dd@github.com>

On Thu, 15 Aug 2024 17:27:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into JDK-8293650-shenandoah-archives
>  - More review comments
>  - Wrap the whole thing in CDS define
>  - Work around 32-bit build failure
>  - Review comments
>  - Merge branch 'master' into JDK-8293650-shenandoah-archives
>  - Move constant to separate class to unbreak Windows builds
>  - Touchups in test
>  - Basic implementation, works well, passes tests

Marked as reviewed by rkennke (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20468#pullrequestreview-2241264683

From shade at openjdk.org  Thu Aug 15 20:54:58 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 20:54:58 GMT
Subject: RFR: 8293650: Shenandoah: Support archived heap objects [v7]
In-Reply-To: <oEqlzpd3aqMO5hXlJHwFIhaI58UNpnvUqnUpHMVM5Gc=.ff9459c5-6153-4f42-b6db-a099a979507b@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
 <oEqlzpd3aqMO5hXlJHwFIhaI58UNpnvUqnUpHMVM5Gc=.ff9459c5-6153-4f42-b6db-a099a979507b@github.com>
Message-ID: <xa6Y-9nKp5hryso41hFJ9RnAOWi813ZuBTSGPqzhA4w=.5b2ac359-0730-4adc-bfc9-80325ac35118@github.com>

On Thu, 15 Aug 2024 17:27:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
>> 
>> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
>> 
>> Additional testing:
>>  - [x] New test
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into JDK-8293650-shenandoah-archives
>  - More review comments
>  - Wrap the whole thing in CDS define
>  - Work around 32-bit build failure
>  - Review comments
>  - Merge branch 'master' into JDK-8293650-shenandoah-archives
>  - Move constant to separate class to unbreak Windows builds
>  - Touchups in test
>  - Basic implementation, works well, passes tests

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20468#issuecomment-2292214646

From shade at openjdk.org  Thu Aug 15 20:54:59 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 15 Aug 2024 20:54:59 GMT
Subject: Integrated: 8293650: Shenandoah: Support archived heap objects
In-Reply-To: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
References: <ff48wF2HHUxGeuQasfPrdXdO7IhVOKwuJStF05vuGCs=.173ee3c1-8ed4-45f8-a9d2-3e8ecd2566b7@github.com>
Message-ID: <EzbGGw_Xqr9dTIjM__XxO3v4lU7s3xSPlrTSAzaToio=.bff3a855-d64a-4467-94c5-83f04cef25ff@github.com>

On Mon, 5 Aug 2024 16:32:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This implements CDS Java heap loading for Shenandoah. There are peculiarities with how CDS loads objects: it basically asks for a contiguous block of memory, fills it out, potentially relocating the objects. This gets interesting when a single Shenandoah region cannot contain the entirety of the load. See the implementation for gory details.
> 
> Current implementation would work well only with Shenandoah heap regions >= 1M, in other words, with the heaps >=2G. It would be better if we trim down the min alignment, thus unblocking smaller heaps. It is not necessary to do so in this PR,  so I track that work separately: [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828).
> 
> Additional testing:
>  - [x] New test
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>  - [x] Same as above, but `MIN_GC_REGION_ALIGNMENT` manually dropped to 256K (mimics [JDK-8337828](https://bugs.openjdk.org/browse/JDK-8337828))

This pull request has now been integrated.

Changeset: d86e99c3
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d86e99c3ca94ee8705e44fe2830edd3ceb0a7f64
Stats:     201 lines in 7 files changed: 189 ins; 6 del; 6 mod

8293650: Shenandoah: Support archived heap objects

Reviewed-by: rkennke, wkemper, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/20468

From wkemper at openjdk.org  Thu Aug 15 20:56:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Aug 2024 20:56:17 GMT
Subject: RFR: 8327000: GenShen: Integrate updated Shenandoah implementation
 of FreeSet into GenShen [v7]
In-Reply-To: <FFRuXqBcUZArexxWXH-6gpbFySqTahJ7htGxuSQcO6g=.e9a0c76e-382e-4b47-826b-18a2252fa670@github.com>
References: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
 <FFRuXqBcUZArexxWXH-6gpbFySqTahJ7htGxuSQcO6g=.e9a0c76e-382e-4b47-826b-18a2252fa670@github.com>
Message-ID: <hjS1_fVS34JsV2Izst0MCtVD6a8XFYvAKOR_IcR7WAw=.d6c5893e-1d94-43f5-86f0-5adf8ef41ea9@github.com>

On Mon, 12 Aug 2024 21:44:35 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This pull request contains a backport of commit 9d2712dd from the openjdk/shenandoah repository.
>> 
>> The commit being backported was authored by Kelvin Nilsen on 26 Jun 2024 and was reviewed by William Kemper and Y. Srinivas Ramakrishna.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Another fix to merge conflict resolution

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/62#pullrequestreview-2241308249

From kdnilsen at openjdk.org  Thu Aug 15 20:59:13 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 15 Aug 2024 20:59:13 GMT
Subject: Integrated: 8327000: GenShen: Integrate updated Shenandoah
 implementation of FreeSet into GenShen
In-Reply-To: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
References: <GZrg8aGOHJs3UgWJX72Lr4asgn5Mpyw-Iz77MJ89beo=.f1ec7d2f-484b-4a80-873e-1192600c4538@github.com>
Message-ID: <lCllAWHv4oLYQLNQX3PLNJSqE0dWj40oJodSSkaunvo=.9b3a344f-54f8-473e-b14b-3bc41ef018cf@github.com>

On Thu, 27 Jun 2024 20:38:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This pull request contains a backport of commit 9d2712dd from the openjdk/shenandoah repository.
> 
> The commit being backported was authored by Kelvin Nilsen on 26 Jun 2024 and was reviewed by William Kemper and Y. Srinivas Ramakrishna.

This pull request has now been integrated.

Changeset: a7664485
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/a766448527e91740319590976e03fa93332ddc95
Stats:     2388 lines in 20 files changed: 1500 ins; 255 del; 633 mod

8327000: GenShen: Integrate updated Shenandoah implementation of FreeSet into GenShen

Reviewed-by: ysr, wkemper
Backport-of: 9d2712ddf39160a618c9c839c46d2510063f45df

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/62

From wkemper at openjdk.org  Thu Aug 15 21:51:13 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 15 Aug 2024 21:51:13 GMT
Subject: RFR: 8338473: GenShen: Cleanup access levels, whitespace,
 typos and unused code
Message-ID: <2svtiwIHlqVLuQ07NV8Ysll-f5PeF8b9mWEXdZ-ztX0=.c54c801c-e121-4794-bf32-e0cfbb66f87d@github.com>

This change cleans up access levels, uses keyword `override` instead of `virtual`. Fixes whitespace and typos. Removes unused code an unnecessary assert.

-------------

Commit messages:
 - Remove unnecessary assert
 - Remove unused code
 - Fix typos and whitespace
 - Clean up access levels, use override instead of virtual

Changes: https://git.openjdk.org/shenandoah/pull/471/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=471&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338473
  Stats: 58 lines in 9 files changed: 3 ins; 45 del; 10 mod
  Patch: https://git.openjdk.org/shenandoah/pull/471.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/471/head:pull/471

PR: https://git.openjdk.org/shenandoah/pull/471

From kdnilsen at openjdk.org  Thu Aug 15 22:56:09 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 15 Aug 2024 22:56:09 GMT
Subject: RFR: 8338473: GenShen: Cleanup access levels, whitespace,
 typos and unused code
In-Reply-To: <2svtiwIHlqVLuQ07NV8Ysll-f5PeF8b9mWEXdZ-ztX0=.c54c801c-e121-4794-bf32-e0cfbb66f87d@github.com>
References: <2svtiwIHlqVLuQ07NV8Ysll-f5PeF8b9mWEXdZ-ztX0=.c54c801c-e121-4794-bf32-e0cfbb66f87d@github.com>
Message-ID: <AgKwbSkhRy17nH0BHsrlflsZRzQBzCQARiskV-KqI7I=.e994386c-692a-48b3-982a-82af4ca9f77b@github.com>

On Thu, 15 Aug 2024 21:10:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change cleans up access levels, uses keyword `override` instead of `virtual`. Fixes whitespace and typos. Removes unused code an unnecessary assert.

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/471#pullrequestreview-2241475453

From ysr at openjdk.org  Thu Aug 15 23:24:07 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 15 Aug 2024 23:24:07 GMT
Subject: RFR: 8338473: GenShen: Cleanup access levels, whitespace,
 typos and unused code
In-Reply-To: <2svtiwIHlqVLuQ07NV8Ysll-f5PeF8b9mWEXdZ-ztX0=.c54c801c-e121-4794-bf32-e0cfbb66f87d@github.com>
References: <2svtiwIHlqVLuQ07NV8Ysll-f5PeF8b9mWEXdZ-ztX0=.c54c801c-e121-4794-bf32-e0cfbb66f87d@github.com>
Message-ID: <Ai31eIQ1nNv-53EQqsy1LIpUfYjLpsf4Ehw35nEzVRg=.dff946d7-24e4-4307-9ac0-eda5022b3d53@github.com>

On Thu, 15 Aug 2024 21:10:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change cleans up access levels, uses keyword `override` instead of `virtual`. Fixes whitespace and typos. Removes unused code an unnecessary assert.

Marked as reviewed by ysr (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/471#pullrequestreview-2241497958

From kdnilsen at openjdk.org  Thu Aug 15 23:25:24 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 15 Aug 2024 23:25:24 GMT
Subject: RFR: 8335930: GenShen: Reserve regions within each generation's
 freeset until available is sufficient
Message-ID: <PphwCTa7Lf2y-xqHMhdWH91jzpjE88Gq8TUjRnAxc3A=.8ffc2979-ee69-4bfa-b6df-c5c3eec61d55@github.com>

Hi all,
This pull request contains a backport of commit 472e4c74 from the openjdk/shenandoah repository.
The commit being backported was authored by Kelvin Nilsen on 11 Jul 2024 and was reviewed by William Kemper.
Thanks!

-------------

Commit messages:
 - Backport 472e4c74bde1c0ceb76755165e709cefa4fef584

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/73/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=73&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335930
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/73.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/73/head:pull/73

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/73

From kdnilsen at openjdk.org  Fri Aug 16 13:20:31 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 16 Aug 2024 13:20:31 GMT
Subject: Integrated: 8335930: GenShen: Reserve regions within each generation's
 freeset until available is sufficient
In-Reply-To: <PphwCTa7Lf2y-xqHMhdWH91jzpjE88Gq8TUjRnAxc3A=.8ffc2979-ee69-4bfa-b6df-c5c3eec61d55@github.com>
References: <PphwCTa7Lf2y-xqHMhdWH91jzpjE88Gq8TUjRnAxc3A=.8ffc2979-ee69-4bfa-b6df-c5c3eec61d55@github.com>
Message-ID: <JU4zIIoXTG5MCaNG-ulk_gmwVp20glEgwOGNzmcWXiw=.da1001c6-d87b-496d-ab1c-58301db23be1@github.com>

On Thu, 15 Aug 2024 23:20:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit 472e4c74 from the openjdk/shenandoah repository.
> The commit being backported was authored by Kelvin Nilsen on 11 Jul 2024 and was reviewed by William Kemper.
> Thanks!

This pull request has now been integrated.

Changeset: 622d8d43
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/622d8d4313b8ffa413fedf6ebff5cf625310c7a3
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8335930: GenShen: Reserve regions within each generation's freeset until available is sufficient

Backport-of: 472e4c74bde1c0ceb76755165e709cefa4fef584

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/73

From wkemper at openjdk.org  Fri Aug 16 14:15:51 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Aug 2024 14:15:51 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <bZJpsoEBGKa6HW6qlPDdK7d8yFLxQjiIs21hcft1T3I=.b75c4baa-4c04-4084-9b2f-a8e893ec6e2c@github.com>

Merges tag jdk-24+11

-------------

Commit messages:
 - 8338304: clang on Linux - check for lld presence after JDK-8333189
 - 8337102: JITTester: Fix breaks in static initialization blocks
 - 8338344: Test TestPrivilegedMode.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Platform
 - 8338333: Add jls links to javax.lang.model.element.Modifier
 - 8332488: Add JVMTI DataDumpRequest to the debug agent
 - 8337237: Use FFM instead of Unsafe for Java 2D RenderBuffer class
 - 8338110: Exclude Fingerprinter::do_type from ubsan checks
 - 8338393: Parallel: Remove unused ParallelCompactData::clear_range
 - 8338402: GHA: some of bundles may not get removed
 - 8332842: Optimize empty CopyOnWriteArrayList allocations
 - ... and 74 more: https://git.openjdk.org/shenandoah/compare/16df9c33...4c344335

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah&pr=473&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah/pull/473/files
  Stats: 8761 lines in 323 files changed: 3565 ins; 4039 del; 1157 mod
  Patch: https://git.openjdk.org/shenandoah/pull/473.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/473/head:pull/473

PR: https://git.openjdk.org/shenandoah/pull/473

From wkemper at openjdk.org  Fri Aug 16 14:37:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Aug 2024 14:37:03 GMT
Subject: Integrated: 8338473: GenShen: Cleanup access levels, whitespace,
 typos and unused code
In-Reply-To: <2svtiwIHlqVLuQ07NV8Ysll-f5PeF8b9mWEXdZ-ztX0=.c54c801c-e121-4794-bf32-e0cfbb66f87d@github.com>
References: <2svtiwIHlqVLuQ07NV8Ysll-f5PeF8b9mWEXdZ-ztX0=.c54c801c-e121-4794-bf32-e0cfbb66f87d@github.com>
Message-ID: <-FV5XDaDGPsx7SJvUtsHkuXzfU3p0aoqIATryi_cO8I=.9cbd0935-4b67-493c-82e3-2b6ff23203af@github.com>

On Thu, 15 Aug 2024 21:10:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change cleans up access levels, uses keyword `override` instead of `virtual`. Fixes whitespace and typos. Removes unused code an unnecessary assert.

This pull request has now been integrated.

Changeset: 7cc63abc
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/7cc63abcb28f5e1db9303fb174be382809387901
Stats:     58 lines in 9 files changed: 3 ins; 45 del; 10 mod

8338473: GenShen: Cleanup access levels, whitespace, typos and unused code

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/shenandoah/pull/471

From ysr at openjdk.org  Fri Aug 16 14:58:38 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 14:58:38 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered
Message-ID: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>

De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.


**Testing:**

- [x] GHA
- [x] jtreg:tier1
- [ ] codepipeline
- [ ] SPECjbb

-------------

Commit messages:
 - JDK-8338479 : GenShen: Detemplatize ShenandoahScanRemembered

Changes: https://git.openjdk.org/shenandoah/pull/472/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338479
  Stats: 1320 lines in 10 files changed: 591 ins; 669 del; 60 mod
  Patch: https://git.openjdk.org/shenandoah/pull/472.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/472/head:pull/472

PR: https://git.openjdk.org/shenandoah/pull/472

From ysr at openjdk.org  Fri Aug 16 15:28:11 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 15:28:11 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered
In-Reply-To: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
Message-ID: <tZa73twnfWHH4ZQXp31JIrt2qBLEwgOapNBMmWHmXvQ=.56f5767f-9436-40b9-9ff8-aa41604c2e8b@github.com>

On Fri, 16 Aug 2024 07:10:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
> 
> 
> **Testing:**
> 
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] codepipeline
> - [ ] SPECjbb

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 1:

> 1: /*

These method definitions have moved verbatim from the .inline.hpp.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 1:

> 1: /*

These method definitions have been moved verbatim to the .cpp file.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/472#discussion_r1719995571
PR Review Comment: https://git.openjdk.org/shenandoah/pull/472#discussion_r1719993204

From kdnilsen at openjdk.org  Fri Aug 16 15:32:03 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 16 Aug 2024 15:32:03 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered
In-Reply-To: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
Message-ID: <3wFZbebw5bqgsSGGwNWV5v00rDlrYYACQwiB_Z8rEjc=.6e394d06-9e9d-47dc-b804-753218c668d9@github.com>

On Fri, 16 Aug 2024 07:10:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
> 
> 
> **Testing:**
> 
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] codepipeline
> - [ ] SPECjbb

Thanks for quick turnaround on this.  I assume we'll complete all tests before integrating.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/472#pullrequestreview-2242978012

From wkemper at openjdk.org  Fri Aug 16 16:30:09 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Aug 2024 16:30:09 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered
In-Reply-To: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
Message-ID: <gwmvDqr0OnHdfiijHS2r-IRV7BrRkH4MQ6uXDpcSEXk=.a147724e-5c44-41c2-86e6-39c5fe164c08@github.com>

On Fri, 16 Aug 2024 07:10:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
> 
> 
> **Testing:**
> 
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] codepipeline
> - [ ] SPECjbb

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 228:

> 226:   size_t card_index_for_addr(HeapWord *p) const;
> 227:   HeapWord *addr_for_card_index(size_t card_index) const;
> 228:   inline const CardValue* get_card_table_byte_map(bool write_table) const;

Should these smaller, non-templated functions remain inline?

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/472#discussion_r1720059179

From ysr at openjdk.org  Fri Aug 16 18:44:39 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 18:44:39 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v2]
In-Reply-To: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
Message-ID: <WqH_s5iYtUAnjGnB5bsZ_95NIrqQ0g_ULcAkFod1wBs=.b9821a5a-fba5-427d-8c2a-81ead2115e59@github.com>

> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
> 
> 
> **Testing:**
> 
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] codepipeline
> - [ ] SPECjbb

Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:

  Leave the `inline` specifier intact against the smaller methods previously
  declared inline.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/472/files
  - new: https://git.openjdk.org/shenandoah/pull/472/files/b97b7a14..8433b9cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/shenandoah/pull/472.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/472/head:pull/472

PR: https://git.openjdk.org/shenandoah/pull/472

From ysr at openjdk.org  Fri Aug 16 18:54:13 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 18:54:13 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v2]
In-Reply-To: <gwmvDqr0OnHdfiijHS2r-IRV7BrRkH4MQ6uXDpcSEXk=.a147724e-5c44-41c2-86e6-39c5fe164c08@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
 <gwmvDqr0OnHdfiijHS2r-IRV7BrRkH4MQ6uXDpcSEXk=.a147724e-5c44-41c2-86e6-39c5fe164c08@github.com>
Message-ID: <iIWQEhbp8pVaLSaBxO8VOpNN6dF9_siWZQ6fPXlpVz4=.4d1b0f4e-460e-4369-b902-23c0e2020662@github.com>

On Fri, 16 Aug 2024 16:24:37 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Leave the `inline` specifier intact against the smaller methods previously
>>   declared inline.
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 228:
> 
>> 226:   size_t card_index_for_addr(HeapWord *p) const;
>> 227:   HeapWord *addr_for_card_index(size_t card_index) const;
>> 228:   inline const CardValue* get_card_table_byte_map(bool write_table) const;
> 
> Should these smaller, non-templated functions remain inline?

ok, let me revert the specifier back.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/472#discussion_r1720210912

From ysr at openjdk.org  Fri Aug 16 18:59:34 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 18:59:34 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v3]
In-Reply-To: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
Message-ID: <KD3uyQkmw_Nn0sC5Bb5DunFaZuRZtlqksiMCqZXkBIY=.0c42103b-788f-4f1f-a388-314debf08dd0@github.com>

> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
> 
> 
> **Testing:**
> 
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] codepipeline
> - [ ] SPECjbb

Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:

  Leave get_card_table_byte_map() also inline like it was before; required
  moving definition into the hpp file as it was used by the tempated
  methods that needed it in multiple translation units presumably.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/472/files
  - new: https://git.openjdk.org/shenandoah/pull/472/files/8433b9cd..4ebd404a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=01-02

  Stats: 10 lines in 2 files changed: 3 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/472.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/472/head:pull/472

PR: https://git.openjdk.org/shenandoah/pull/472

From ysr at openjdk.org  Fri Aug 16 19:47:34 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 19:47:34 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v4]
In-Reply-To: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
Message-ID: <UR_uWIbbOaP0bn3muWFgi3x8VdBB9IMAfQUdV_rYJkw=.abf80c28-7860-4136-92ee-3b29b39e10dd@github.com>

> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
> 
> 
> **Testing:**
> 
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] codepipeline
> - [x] SPECjbb

Y. Srinivas Ramakrishna 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 detemplatize
 - Leave get_card_table_byte_map() also inline like it was before; required
   moving definition into the hpp file as it was used by the tempated
   methods that needed it in multiple translation units presumably.
 - Leave the `inline` specifier intact against the smaller methods previously
   declared inline.
 - JDK-8338479 : GenShen: Detemplatize ShenandoahScanRemembered
   
   De-templatize ShenandoahScanRemembered and ShenandoahCardCluster

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/472/files
  - new: https://git.openjdk.org/shenandoah/pull/472/files/4ebd404a..0c19ca5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=03
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=02-03

  Stats: 58 lines in 9 files changed: 3 ins; 45 del; 10 mod
  Patch: https://git.openjdk.org/shenandoah/pull/472.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/472/head:pull/472

PR: https://git.openjdk.org/shenandoah/pull/472

From ysr at openjdk.org  Fri Aug 16 19:54:03 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 19:54:03 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v4]
In-Reply-To: <UR_uWIbbOaP0bn3muWFgi3x8VdBB9IMAfQUdV_rYJkw=.abf80c28-7860-4136-92ee-3b29b39e10dd@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
 <UR_uWIbbOaP0bn3muWFgi3x8VdBB9IMAfQUdV_rYJkw=.abf80c28-7860-4136-92ee-3b29b39e10dd@github.com>
Message-ID: <WUSjpI_9G5kPh_PDDh3Nz6kSQmmPpqO7RjQtkQ_VvTM=.c86eb33d-183e-40ae-99c6-adbbe4066269@github.com>

On Fri, 16 Aug 2024 19:47:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
>> 
>> 
>> **Testing:**
>> 
>> - [x] GHA
>> - [x] jtreg:tier1
>> - [ ] codepipeline
>> - [x] SPECjbb
>
> Y. Srinivas Ramakrishna 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 detemplatize
>  - Leave get_card_table_byte_map() also inline like it was before; required
>    moving definition into the hpp file as it was used by the tempated
>    methods that needed it in multiple translation units presumably.
>  - Leave the `inline` specifier intact against the smaller methods previously
>    declared inline.
>  - JDK-8338479 : GenShen: Detemplatize ShenandoahScanRemembered
>    
>    De-templatize ShenandoahScanRemembered and ShenandoahCardCluster

Running specjbb perf numbers and codepipeline again after syncing with latest changes in master. Will push later today once all is clear and no perf differences (don't expect any). Left the inline specifier intact on those methods as requested by William.

Thanks for your reviews!

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/472#issuecomment-2294133140

From ysr at openjdk.org  Fri Aug 16 19:58:02 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 19:58:02 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v4]
In-Reply-To: <UR_uWIbbOaP0bn3muWFgi3x8VdBB9IMAfQUdV_rYJkw=.abf80c28-7860-4136-92ee-3b29b39e10dd@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
 <UR_uWIbbOaP0bn3muWFgi3x8VdBB9IMAfQUdV_rYJkw=.abf80c28-7860-4136-92ee-3b29b39e10dd@github.com>
Message-ID: <_g7Wxi_5ROPrzhEGcGXDxKvu7t9lwFHxex1Gra-v6e8=.e85e8376-45eb-4b5e-8697-a8d12f389646@github.com>

On Fri, 16 Aug 2024 19:47:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
>> 
>> 
>> **Testing:**
>> 
>> - [x] GHA
>> - [x] jtreg:tier1
>> - [ ] codepipeline
>> - [x] SPECjbb
>
> Y. Srinivas Ramakrishna 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 detemplatize
>  - Leave get_card_table_byte_map() also inline like it was before; required
>    moving definition into the hpp file as it was used by the tempated
>    methods that needed it in multiple translation units presumably.
>  - Leave the `inline` specifier intact against the smaller methods previously
>    declared inline.
>  - JDK-8338479 : GenShen: Detemplatize ShenandoahScanRemembered
>    
>    De-templatize ShenandoahScanRemembered and ShenandoahCardCluster

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 1021:

> 1019:   // Fills in assignment with next chunk of work and returns true iff there is more work.
> 1020:   // Otherwise, returns false.  This is multi-thread-safe.
> 1021:   inline bool next(struct ShenandoahRegionChunk *assignment);

Missed these; will restore these as well.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/472#discussion_r1720291557

From ysr at openjdk.org  Fri Aug 16 20:37:40 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 20:37:40 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v5]
In-Reply-To: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
Message-ID: <BIB_9I0RyDoQAYrm-8fLjlMI5INm__KXDfF_NBoQOwM=.ce2a679f-5f97-4c04-8bdf-1920dba59d0f@github.com>

> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
> 
> 
> **Testing:**
> 
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] codepipeline
> - [x] SPECjbb

Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:

  Restore `inline` specifier for a few other smaller methods.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/472/files
  - new: https://git.openjdk.org/shenandoah/pull/472/files/0c19ca5f..ed6a0a96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=04
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=472&range=03-04

  Stats: 89 lines in 3 files changed: 44 ins; 43 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah/pull/472.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/472/head:pull/472

PR: https://git.openjdk.org/shenandoah/pull/472

From ysr at openjdk.org  Fri Aug 16 20:41:02 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 16 Aug 2024 20:41:02 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v3]
In-Reply-To: <_g7Wxi_5ROPrzhEGcGXDxKvu7t9lwFHxex1Gra-v6e8=.e85e8376-45eb-4b5e-8697-a8d12f389646@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
 <UR_uWIbbOaP0bn3muWFgi3x8VdBB9IMAfQUdV_rYJkw=.abf80c28-7860-4136-92ee-3b29b39e10dd@github.com>
 <_g7Wxi_5ROPrzhEGcGXDxKvu7t9lwFHxex1Gra-v6e8=.e85e8376-45eb-4b5e-8697-a8d12f389646@github.com>
Message-ID: <8emoOJbTghNVTDKsrIU38PeIQ7GgFSHjPcGhIphnK9A=.1922e442-dec5-40a9-8916-9030ffc5e1f3@github.com>

On Fri, 16 Aug 2024 19:55:10 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Leave get_card_table_byte_map() also inline like it was before; required
>>   moving definition into the hpp file as it was used by the tempated
>>   methods that needed it in multiple translation units presumably.
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 1021:
> 
>> 1019:                                ShenandoahRegionChunkIterator* work_list,
>> 1020:                                bool is_concurrent);
>> 1021: 
> 
> Missed these; will restore these as well.

restored.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/472#discussion_r1720325366

From wkemper at openjdk.org  Fri Aug 16 20:44:01 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Aug 2024 20:44:01 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v5]
In-Reply-To: <BIB_9I0RyDoQAYrm-8fLjlMI5INm__KXDfF_NBoQOwM=.ce2a679f-5f97-4c04-8bdf-1920dba59d0f@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
 <BIB_9I0RyDoQAYrm-8fLjlMI5INm__KXDfF_NBoQOwM=.ce2a679f-5f97-4c04-8bdf-1920dba59d0f@github.com>
Message-ID: <BDv6VdaJYc0AIOxV9PhvCSOd_KX5u6Y4EF7y4Q6rRQk=.fb589663-0735-4d93-ab1b-ff76b2f9fc8c@github.com>

On Fri, 16 Aug 2024 20:37:40 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
>> 
>> 
>> **Testing:**
>> 
>> - [x] GHA
>> - [x] jtreg:tier1
>> - [ ] codepipeline
>> - [x] SPECjbb
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore `inline` specifier for a few other smaller methods.

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/472#pullrequestreview-2243517059

From wkemper at openjdk.org  Fri Aug 16 21:58:58 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Aug 2024 21:58:58 GMT
Subject: RFR: 8338477: GenShen: Cleanup generational heap
Message-ID: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>

* Inline heap accessor
* break up huge do_work method
* remove TODOs

-------------

Commit messages:
 - Inline heap accessor, break up huge do_work method

Changes: https://git.openjdk.org/shenandoah/pull/474/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=474&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338477
  Stats: 224 lines in 2 files changed: 90 ins; 95 del; 39 mod
  Patch: https://git.openjdk.org/shenandoah/pull/474.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/474/head:pull/474

PR: https://git.openjdk.org/shenandoah/pull/474

From wkemper at openjdk.org  Fri Aug 16 23:13:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Aug 2024 23:13:52 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v3]
In-Reply-To: <JKIBlgmk9ZKxHhgdoyLc_q76-75St9M_DHvXBeANFls=.28973696-ab2f-4e7b-bc0c-9ea6ccb5611f@github.com>
References: <JKIBlgmk9ZKxHhgdoyLc_q76-75St9M_DHvXBeANFls=.28973696-ab2f-4e7b-bc0c-9ea6ccb5611f@github.com>
Message-ID: <JWvFnu1ap8dV_ZaW_cfGB_R8kK3_seBAlPI2_8Zw2nY=.ce66c25e-9646-4f7a-867b-e25846d9a6a4@github.com>

> Merges tag jdk-21.0.5+3

William Kemper 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 12 additional commits since the last revision:

 - Merge remote-tracking branch 'shenandoah-jdk21u/master' into merge-jdk-21.0.5+3
 - 8336343: Add more known sysroot library locations for ALSA
   
   Backport-of: 9e6e0a8f341389215f0db6b2260f2b16351f02be
 - 8336928: GHA: Bundle artifacts removal broken
   
   Backport-of: 98562166e4a4c8921709014423c6cbc993aa0d97
 - 8336342: Fix known X11 library locations in sysroot
   
   Backport-of: ee365d75cca6f33e5781fe514e557caba2b67c32
 - 8337283: configure.log is truncated when build dir is on different filesystem
   
   Backport-of: 7e925d727f716e5c366b0d85b9c0de24efe43103
 - 8327501: Common ForkJoinPool prevents class unloading in some cases
   8328366: Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501
   
   Backport-of: 53c4714aab2e072ba18631875dcaa3b2d5d22243
 - 8330146: assert(!_thread->is_in_any_VTMS_transition()) failed
   
   Backport-of: c4ff58b9bcfd08eae0623a648a837e08f25b3f9b
 - 8328642: Convert applet test MouseDraggedOutCauseScrollingTest.html to main
   
   Backport-of: ab183e437c18b445e9c022a4d74de818d4ccecbe
 - 8334618: ubsan: support setting additional ubsan check options
   
   Backport-of: efb905e57ab7a5299952419fa9961316541056c2
 - 8333639: ubsan: cppVtables.cpp:81:55: runtime error: index 14 out of bounds for type 'long int [1]'
   
   Backport-of: 0199fee431e0dccdd570b38595ea29c760dbed44
 - ... and 2 more: https://git.openjdk.org/shenandoah-jdk21u/compare/b662c494...4d91471b

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/72/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/72/files/75c82f63..4d91471b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=72&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=72&range=01-02

  Stats: 26152 lines in 244 files changed: 23494 ins; 1482 del; 1176 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/72.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/72/head:pull/72

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/72

From wkemper at openjdk.org  Fri Aug 16 23:29:45 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 16 Aug 2024 23:29:45 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <bZJpsoEBGKa6HW6qlPDdK7d8yFLxQjiIs21hcft1T3I=.b75c4baa-4c04-4084-9b2f-a8e893ec6e2c@github.com>
References: <bZJpsoEBGKa6HW6qlPDdK7d8yFLxQjiIs21hcft1T3I=.b75c4baa-4c04-4084-9b2f-a8e893ec6e2c@github.com>
Message-ID: <4ZF9D42Ih5qOTjM1QO5CcH969CwWzA3kHY-4wunYPHs=.b675675a-21e6-41c0-9cf3-7f8317a08904@github.com>

> Merges tag jdk-24+11

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 85 commits:

 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-24+11
 - 8338304: clang on Linux - check for lld presence after JDK-8333189
   
   Reviewed-by: erikj, ihse
 - 8337102: JITTester: Fix breaks in static initialization blocks
   
   Reviewed-by: kvn, iveresov
 - 8338344: Test TestPrivilegedMode.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Platform
   
   Reviewed-by: chagedorn, shade
 - 8338333: Add jls links to javax.lang.model.element.Modifier
   
   Reviewed-by: liach, iris, prappo, vromero, jlahoda
 - 8332488: Add JVMTI DataDumpRequest to the debug agent
   
   Reviewed-by: sspitsyn, lmesnik
 - 8337237: Use FFM instead of Unsafe for Java 2D RenderBuffer class
   
   Reviewed-by: jvernee, jdv
 - 8338110: Exclude Fingerprinter::do_type from ubsan checks
   
   Reviewed-by: jwaters, rrich
 - 8338393: Parallel: Remove unused ParallelCompactData::clear_range
   
   Reviewed-by: tschatzl
 - 8338402: GHA: some of bundles may not get removed
   
   Reviewed-by: ihse, shade
 - ... and 75 more: https://git.openjdk.org/shenandoah/compare/7cc63abc...2a07905b

-------------

Changes: https://git.openjdk.org/shenandoah/pull/473/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=473&range=01
  Stats: 8761 lines in 323 files changed: 3565 ins; 4039 del; 1157 mod
  Patch: https://git.openjdk.org/shenandoah/pull/473.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/473/head:pull/473

PR: https://git.openjdk.org/shenandoah/pull/473

From shade at openjdk.org  Mon Aug 19 11:20:06 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Aug 2024 11:20:06 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v4]
In-Reply-To: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
Message-ID: <1ozQDeJqM5Cr5jHU_vX7I5SW9BKm0ce6JWo4LqBZdcE=.9eb60c15-17ff-4a70-b0c4-4e132720e2d1@github.com>

> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
> 
> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
> 
> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
> 
> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`

Aleksey Shipilev 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 12 additional commits since the last revision:

 - Review feedback
 - Merge branch 'master' into JDK-8337981-shenandoah-is-in
 - Merge branch 'master' into JDK-8337981-shenandoah-is-in
 - Even stronger is_in check
 - Use is_in_reserved
 - Drop raw_referent to HeapWord*
 - Add some overrides
 - Merge branch 'master' into JDK-8337981-shenandoah-is-in
 - Style touchups
 - Fixing ShenandoahReferenceProcessor
 - ... and 2 more: https://git.openjdk.org/jdk/compare/ed2af769...2da163d1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20492/files
  - new: https://git.openjdk.org/jdk/pull/20492/files/0a0859a4..2da163d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20492&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20492&range=02-03

  Stats: 11187 lines in 265 files changed: 7236 ins; 2667 del; 1284 mod
  Patch: https://git.openjdk.org/jdk/pull/20492.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20492/head:pull/20492

PR: https://git.openjdk.org/jdk/pull/20492

From shade at openjdk.org  Mon Aug 19 11:20:08 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Aug 2024 11:20:08 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v3]
In-Reply-To: <UDia7nMiGvOX91_jgZopMr8l6bV6V7101DRhld_PplM=.1f263782-8de8-4119-9025-b3daa2ffd672@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <yA01cDNwRDO2_B_HOtuaUXvyEF4twRLUTQo6qjQ2a08=.76e5e418-ee5c-4101-8ed2-1233f6efd93a@github.com>
 <UDia7nMiGvOX91_jgZopMr8l6bV6V7101DRhld_PplM=.1f263782-8de8-4119-9025-b3daa2ffd672@github.com>
Message-ID: <OlmYiJnb9FEVuHAxSZl6gGc0m_6mVM2FiSWOs_Ds36s=.6739abb6-b3bd-4bcb-a395-8b6430152358@github.com>

On Wed, 14 Aug 2024 18:31:32 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev 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:
>> 
>>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>>  - Even stronger is_in check
>>  - Use is_in_reserved
>>  - Drop raw_referent to HeapWord*
>>  - Add some overrides
>>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>>  - Style touchups
>>  - Fixing ShenandoahReferenceProcessor
>>  - Verifier fix
>>  - Fix
>
> src/hotspot/share/gc/shenandoah/shenandoahAsserts.cpp line 214:
> 
>> 212: 
>> 213:   ShenandoahHeapRegion* obj_reg = heap->heap_region_containing(obj);
>> 214:   if (!heap->is_full_gc_move_in_progress() && !obj_reg->is_active()) {
> 
> This is essentially ShenandoahHeap::is_in(), right? Might also want to check for obj < region->top() here? Or use is_in() to begin with?

All right, true. We might just use `is_in` here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20492#discussion_r1721629410

From wkemper at openjdk.org  Mon Aug 19 15:33:24 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 19 Aug 2024 15:33:24 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <JKIBlgmk9ZKxHhgdoyLc_q76-75St9M_DHvXBeANFls=.28973696-ab2f-4e7b-bc0c-9ea6ccb5611f@github.com>
References: <JKIBlgmk9ZKxHhgdoyLc_q76-75St9M_DHvXBeANFls=.28973696-ab2f-4e7b-bc0c-9ea6ccb5611f@github.com>
Message-ID: <QyuIFqvjdOF90JrIBeiEs3IG0MF1aa0-v5eMLAfqBZ8=.2b231b87-5167-4450-9fc3-e7aa13224d08@github.com>

On Thu, 15 Aug 2024 14:17:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+3

This pull request has now been integrated.

Changeset: 446f5b77
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/446f5b7725e66e6f9157b2e918cee07572a6a724
Stats:     494 lines in 16 files changed: 170 ins; 256 del; 68 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/72

From ysr at openjdk.org  Mon Aug 19 16:56:11 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 19 Aug 2024 16:56:11 GMT
Subject: RFR: 8338479: GenShen: Detemplatize ShenandoahScanRemembered [v5]
In-Reply-To: <BIB_9I0RyDoQAYrm-8fLjlMI5INm__KXDfF_NBoQOwM=.ce2a679f-5f97-4c04-8bdf-1920dba59d0f@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
 <BIB_9I0RyDoQAYrm-8fLjlMI5INm__KXDfF_NBoQOwM=.ce2a679f-5f97-4c04-8bdf-1920dba59d0f@github.com>
Message-ID: <BFv_2KHemNl6uaP5MCGmUa5WaH8uBwCNwmL4I-2Ikuo=.01983670-19f7-4e5c-8a94-908361b35473@github.com>

On Fri, 16 Aug 2024 20:37:40 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
>> 
>> 
>> **Testing:**
>> 
>> - [x] GHA
>> - [x] jtreg:tier1
>> - [x] codepipeline
>> - [x] SPECjbb
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore `inline` specifier for a few other smaller methods.

Thanks for your reviews!

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/472#issuecomment-2297014428

From ysr at openjdk.org  Mon Aug 19 16:56:12 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 19 Aug 2024 16:56:12 GMT
Subject: Integrated: 8338479: GenShen: Detemplatize ShenandoahScanRemembered
In-Reply-To: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
References: <ELmTdchDLC93Oh2YbA_zriXTAcc2YFE_qNcgB7MV-NE=.901af24d-bed8-441f-a895-6c30a4a5fc00@github.com>
Message-ID: <fHgklTnBhoLXxx0YYqO9VNO1kTyAmAwD6DWAaZPBtkY=.d2b3546a-58df-483d-96ac-5c0a24f9fcf7@github.com>

On Fri, 16 Aug 2024 07:10:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> De-templatize ShenandoahScanRemembered and ShenandoahCardCluster, based on Roman's review feedback at https://github.com/openjdk/jdk/pull/20395/files/46638cdef26fd25c290e6f63035ff5d2f1dc3bdb#r1718773835.
> 
> 
> **Testing:**
> 
> - [x] GHA
> - [x] jtreg:tier1
> - [x] codepipeline
> - [x] SPECjbb

This pull request has now been integrated.

Changeset: 78277f9f
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/78277f9f6e61ecc61eddd3fa72d963f08d7e754f
Stats:     1216 lines in 10 files changed: 545 ins; 625 del; 46 mod

8338479: GenShen: Detemplatize ShenandoahScanRemembered

Reviewed-by: kdnilsen, wkemper

-------------

PR: https://git.openjdk.org/shenandoah/pull/472

From rkennke at openjdk.org  Mon Aug 19 17:31:52 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 19 Aug 2024 17:31:52 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v4]
In-Reply-To: <1ozQDeJqM5Cr5jHU_vX7I5SW9BKm0ce6JWo4LqBZdcE=.9eb60c15-17ff-4a70-b0c4-4e132720e2d1@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <1ozQDeJqM5Cr5jHU_vX7I5SW9BKm0ce6JWo4LqBZdcE=.9eb60c15-17ff-4a70-b0c4-4e132720e2d1@github.com>
Message-ID: <xMaX4bHe5lcKAr9OviKcNfl17KXKTzih97kiWqq7kfo=.a1ac4438-488c-4e72-af9f-e29f7722f852@github.com>

On Mon, 19 Aug 2024 11:20:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
>> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
>> 
>> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
>> 
>> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
>> 
>> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>
> Aleksey Shipilev 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 12 additional commits since the last revision:
> 
>  - Review feedback
>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>  - Even stronger is_in check
>  - Use is_in_reserved
>  - Drop raw_referent to HeapWord*
>  - Add some overrides
>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>  - Style touchups
>  - Fixing ShenandoahReferenceProcessor
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/11b06bb1...2da163d1

Looks good, thanks!

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20492#pullrequestreview-2246095728

From shade at openjdk.org  Mon Aug 19 18:51:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 19 Aug 2024 18:51:52 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <zN5Tl6Bm9LOTXi9fxSgtTpubkuuEwvMNPm-5huCpngQ=.77ff564f-71f8-450e-bb12-b94fdf781242@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
 <zN5Tl6Bm9LOTXi9fxSgtTpubkuuEwvMNPm-5huCpngQ=.77ff564f-71f8-450e-bb12-b94fdf781242@github.com>
Message-ID: <IdER6FNf5FSDZddI_tpeNtiyeppZnyhQlSKZdHfwdZo=.c4a4ed23-7a01-411b-9a2d-efe729e71347@github.com>

On Wed, 14 Aug 2024 16:43:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Style touchups
>>  - Fixing ShenandoahReferenceProcessor
>>  - Verifier fix
>
> Marked as reviewed by wkemper (Committer).

@earthling-amzn -- this might cause more "fun" down the line with GenShen merges. Tell me when you want this to appear in mainline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20492#issuecomment-2297219193

From kdnilsen at openjdk.org  Mon Aug 19 19:34:11 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 19 Aug 2024 19:34:11 GMT
Subject: RFR: 8338477: GenShen: Cleanup generational heap
In-Reply-To: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
References: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
Message-ID: <6IyAL1pPuN0T8BgIQIS3wIrZoHPdMWvX_3mUwWSliAA=.b9914c1c-36c6-44e3-8267-01c53a74de13@github.com>

On Fri, 16 Aug 2024 21:53:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Inline heap accessor
> * break up huge do_work method
> * remove TODOs

Marked as reviewed by kdnilsen (Committer).

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 321:

> 319:   if (result == copy_val) {
> 320:     // Successfully evacuated. Our copy is now the public one!
> 321:     ContinuationGCSupport::relativize_stack_chunk(copy_val);

I don't remember the significance of relative_stack_chunk().  Should we have a comment to explain what this is doing?

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/474#pullrequestreview-2246304716
PR Review Comment: https://git.openjdk.org/shenandoah/pull/474#discussion_r1722254382

From wkemper at openjdk.org  Mon Aug 19 20:44:13 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 19 Aug 2024 20:44:13 GMT
Subject: RFR: 8338477: GenShen: Cleanup generational heap [v2]
In-Reply-To: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
References: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
Message-ID: <zGIKwSPbzkvMrEv6zgmfaJXEkQCRnRq6P-NsLKCcqjQ=.df8f4a45-64fb-499b-80a8-e1d74bb3a410@github.com>

> * Inline heap accessor
> * break up huge do_work method
> * remove TODOs

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'shenandoah/master' into gen-heap-feedback
 - Inline heap accessor, break up huge do_work method

-------------

Changes: https://git.openjdk.org/shenandoah/pull/474/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=474&range=01
  Stats: 221 lines in 2 files changed: 87 ins; 95 del; 39 mod
  Patch: https://git.openjdk.org/shenandoah/pull/474.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/474/head:pull/474

PR: https://git.openjdk.org/shenandoah/pull/474

From wkemper at openjdk.org  Mon Aug 19 20:49:15 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 19 Aug 2024 20:49:15 GMT
Subject: RFR: 8338477: GenShen: Cleanup generational heap [v2]
In-Reply-To: <6IyAL1pPuN0T8BgIQIS3wIrZoHPdMWvX_3mUwWSliAA=.b9914c1c-36c6-44e3-8267-01c53a74de13@github.com>
References: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
 <6IyAL1pPuN0T8BgIQIS3wIrZoHPdMWvX_3mUwWSliAA=.b9914c1c-36c6-44e3-8267-01c53a74de13@github.com>
Message-ID: <SOUe94qxf9uJ6NqCVDESEWy_FHgBGFeJKdgGo6Hazyk=.9e23f639-342a-43cd-9381-1af333581ca8@github.com>

On Mon, 19 Aug 2024 19:29:18 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'shenandoah/master' into gen-heap-feedback
>>  - Inline heap accessor, break up huge do_work method
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 321:
> 
>> 319:   if (result == copy_val) {
>> 320:     // Successfully evacuated. Our copy is now the public one!
>> 321:     ContinuationGCSupport::relativize_stack_chunk(copy_val);
> 
> I don't remember the significance of relative_stack_chunk().  Should we have a comment to explain what this is doing?

I don't really know what `relativize_stack_chunk` is doing either (something to do with Virtual Threads). The important thing here is that it may inspect the header without realizing the header is a forwarding pointer. Secondarily, we don't want to do work on oops that aren't going to be visible (i.e, it lost the evacuation race). I'll add a comment here.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/474#discussion_r1722330984

From kdnilsen at openjdk.org  Mon Aug 19 21:07:17 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 19 Aug 2024 21:07:17 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementationle
Message-ID: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>

1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
3. Remove unhelpful comment from shenandoahFullGC.cpp

-------------

Commit messages:
 - Remove unhelpful comment from shenandoahFullGC.cpp
 - Use accessor methods and tagged access for more maintainable code
 - Change type declaration for establish_preselected argument
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 13 more: https://git.openjdk.org/shenandoah/compare/7cc63abc...45057ce5

Changes: https://git.openjdk.org/shenandoah/pull/475/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338535
  Stats: 118 lines in 22 files changed: 62 ins; 5 del; 51 mod
  Patch: https://git.openjdk.org/shenandoah/pull/475.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/475/head:pull/475

PR: https://git.openjdk.org/shenandoah/pull/475

From wkemper at openjdk.org  Mon Aug 19 21:11:39 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 19 Aug 2024 21:11:39 GMT
Subject: RFR: 8338477: GenShen: Cleanup generational heap [v3]
In-Reply-To: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
References: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
Message-ID: <4MBWCPg3BdqE_530w3hafhX7yIFoJHxKlqUGJL2rc-0=.eaf15ec5-ec4c-4580-a52c-a5fe02ee9190@github.com>

> * Inline heap accessor
> * break up huge do_work method
> * remove TODOs

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment for relativizing stack chunks of evacuated objects

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/474/files
  - new: https://git.openjdk.org/shenandoah/pull/474/files/5c6261c6..9116643d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=474&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=474&range=01-02

  Stats: 10 lines in 1 file changed: 9 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/474.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/474/head:pull/474

PR: https://git.openjdk.org/shenandoah/pull/474

From kdnilsen at openjdk.org  Mon Aug 19 21:14:26 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 19 Aug 2024 21:14:26 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementationle [v2]
In-Reply-To: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
Message-ID: <AktNBkbN0jT-EnyvagiOFg30iD5lFyAaWkWHji03vdA=.cdf9ac43-683e-4ee2-8bb7-745f60a51c8d@github.com>

> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
> 2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
> 3. Remove unhelpful comment from shenandoahFullGC.cpp

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix name of zero_RegionData function

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/475/files
  - new: https://git.openjdk.org/shenandoah/pull/475/files/45057ce5..7fa4a49c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/shenandoah/pull/475.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/475/head:pull/475

PR: https://git.openjdk.org/shenandoah/pull/475

From wkemper at openjdk.org  Mon Aug 19 21:31:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 19 Aug 2024 21:31:03 GMT
Subject: Integrated: 8338477: GenShen: Cleanup generational heap
In-Reply-To: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
References: <GFxWfezqVtAXDvzwGJdjy7g8jJTPBx8z49YAsje44hU=.040b9af4-2284-4a68-9348-3d7b83e09b5c@github.com>
Message-ID: <NiQxLRZRUId5_kRZK6He77IXKKVMxydO1NaGll0sJS4=.0e8b40eb-368c-448c-8026-05f71b6a2e4a@github.com>

On Fri, 16 Aug 2024 21:53:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Inline heap accessor
> * break up huge do_work method
> * remove TODOs

This pull request has now been integrated.

Changeset: 1ed7586b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/1ed7586be1c5271e7a223f1cd14effd2a83b0b84
Stats:     231 lines in 2 files changed: 96 ins; 96 del; 39 mod

8338477: GenShen: Cleanup generational heap

Reviewed-by: kdnilsen

-------------

PR: https://git.openjdk.org/shenandoah/pull/474

From wkemper at openjdk.org  Mon Aug 19 21:37:09 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 19 Aug 2024 21:37:09 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementationle [v2]
In-Reply-To: <AktNBkbN0jT-EnyvagiOFg30iD5lFyAaWkWHji03vdA=.cdf9ac43-683e-4ee2-8bb7-745f60a51c8d@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <AktNBkbN0jT-EnyvagiOFg30iD5lFyAaWkWHji03vdA=.cdf9ac43-683e-4ee2-8bb7-745f60a51c8d@github.com>
Message-ID: <oqyEOLwEl8SM-Rdk5x6D5OqHWOacYC-q5KvsIKCTDXc=.b0089f36-e794-48c7-9451-36312b666d2e@github.com>

On Mon, 19 Aug 2024 21:14:26 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
>> 2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
>> 3. Remove unhelpful comment from shenandoahFullGC.cpp
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix name of zero_RegionData function

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 92:

> 90:   } RegionData;
> 91: 
> 92:   static inline void set_RegionData_region_and_garbage(RegionData& region_data, ShenandoahHeapRegion* region, size_t garbage) {

Can these static functions just be instance methods? call sites would then be:
```C++
region_data->set_region_and_garbage(region, garbage);

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/475#pullrequestreview-2246498696
PR Review Comment: https://git.openjdk.org/shenandoah/pull/475#discussion_r1722372855

From ysr at openjdk.org  Mon Aug 19 21:49:06 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 19 Aug 2024 21:49:06 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementationle [v2]
In-Reply-To: <oqyEOLwEl8SM-Rdk5x6D5OqHWOacYC-q5KvsIKCTDXc=.b0089f36-e794-48c7-9451-36312b666d2e@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <AktNBkbN0jT-EnyvagiOFg30iD5lFyAaWkWHji03vdA=.cdf9ac43-683e-4ee2-8bb7-745f60a51c8d@github.com>
 <oqyEOLwEl8SM-Rdk5x6D5OqHWOacYC-q5KvsIKCTDXc=.b0089f36-e794-48c7-9451-36312b666d2e@github.com>
Message-ID: <Y26jVo4AWJk3lT-rFBgm5pYpskux0RGv78W3sNQVQVc=.86f6fe23-dd14-4578-8ffe-8cdafb175113@github.com>

On Mon, 19 Aug 2024 21:34:18 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix name of zero_RegionData function
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 92:
> 
>> 90:   } RegionData;
>> 91: 
>> 92:   static inline void set_RegionData_region_and_garbage(RegionData& region_data, ShenandoahHeapRegion* region, size_t garbage) {
> 
> Can these static functions just be instance methods? call sites would then be:
> ```C++
> region_data->set_region_and_garbage(region, garbage);

+1

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/475#discussion_r1722384459

From wkemper at openjdk.org  Mon Aug 19 23:30:51 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 19 Aug 2024 23:30:51 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v2]
In-Reply-To: <zN5Tl6Bm9LOTXi9fxSgtTpubkuuEwvMNPm-5huCpngQ=.77ff564f-71f8-450e-bb12-b94fdf781242@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <bBpY5sQ3sCjlekzYkt-wLKqMDGTbfRDVGNL-EPmMOv4=.2129c5f3-81ed-4b37-a682-c69eb6ed93b9@github.com>
 <zN5Tl6Bm9LOTXi9fxSgtTpubkuuEwvMNPm-5huCpngQ=.77ff564f-71f8-450e-bb12-b94fdf781242@github.com>
Message-ID: <ZJzeHKJxnjWC-Cghf5Ukcx72_Lyh7l7XKtGe8yC4B_M=.c8ddf394-b3e1-4fa0-a450-11e8488a832e@github.com>

On Wed, 14 Aug 2024 16:43:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Style touchups
>>  - Fixing ShenandoahReferenceProcessor
>>  - Verifier fix
>
> Marked as reviewed by wkemper (Committer).

> @earthling-amzn -- this might cause more "fun" down the line with GenShen merges. Tell me when you want this to appear in mainline.

I don't want the GenShen PR to hold anything up. Feel free to integrate, we'll deal with any repercussions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20492#issuecomment-2297687138

From kdnilsen at openjdk.org  Tue Aug 20 00:05:33 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 20 Aug 2024 00:05:33 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v3]
In-Reply-To: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
Message-ID: <_osGhXGhNmSlk8psnto4scWg8gwOrnP2MbneNUPfa-0=.3a73a444-141f-4f97-a3f6-7daaa70124ef@github.com>

> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
> 2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
> 3. Remove unhelpful comment from shenandoahFullGC.cpp

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Code touchup
  
  Remove 2 unneeded blank lines
  Move and simplify a comment from call point to called method
  implementation

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/475/files
  - new: https://git.openjdk.org/shenandoah/pull/475/files/7fa4a49c..83e84fce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=01-02

  Stats: 6 lines in 4 files changed: 1 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/475.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/475/head:pull/475

PR: https://git.openjdk.org/shenandoah/pull/475

From wkemper at openjdk.org  Tue Aug 20 00:44:28 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Aug 2024 00:44:28 GMT
Subject: RFR: Merge openjdk/jdk:master [v3]
In-Reply-To: <bZJpsoEBGKa6HW6qlPDdK7d8yFLxQjiIs21hcft1T3I=.b75c4baa-4c04-4084-9b2f-a8e893ec6e2c@github.com>
References: <bZJpsoEBGKa6HW6qlPDdK7d8yFLxQjiIs21hcft1T3I=.b75c4baa-4c04-4084-9b2f-a8e893ec6e2c@github.com>
Message-ID: <eSn72AqV3rI6YVluPCZcHVSwYyrBJlUrM9xsFupyIbA=.e75332d2-e01a-4474-bf01-b3c210436a09@github.com>

> Merges tag jdk-24+11

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Parallel phase must immediately follow worker phase

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/473/files
  - new: https://git.openjdk.org/shenandoah/pull/473/files/2a07905b..7ca1ba14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=473&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=473&range=01-02

  Stats: 16 lines in 2 files changed: 1 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/shenandoah/pull/473.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/473/head:pull/473

PR: https://git.openjdk.org/shenandoah/pull/473

From shade at openjdk.org  Tue Aug 20 08:43:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Aug 2024 08:43:54 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
 [v4]
In-Reply-To: <1ozQDeJqM5Cr5jHU_vX7I5SW9BKm0ce6JWo4LqBZdcE=.9eb60c15-17ff-4a70-b0c4-4e132720e2d1@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
 <1ozQDeJqM5Cr5jHU_vX7I5SW9BKm0ce6JWo4LqBZdcE=.9eb60c15-17ff-4a70-b0c4-4e132720e2d1@github.com>
Message-ID: <ikmEuRo04hT-TX4FAr9WCqdph7_Cgh7BX8JGlbCgQgE=.cdf0bc96-d405-444a-976e-253ea4bfa94b@github.com>

On Mon, 19 Aug 2024 11:20:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
>> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
>> 
>> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
>> 
>> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
>> 
>> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`
>
> Aleksey Shipilev 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 12 additional commits since the last revision:
> 
>  - Review feedback
>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>  - Even stronger is_in check
>  - Use is_in_reserved
>  - Drop raw_referent to HeapWord*
>  - Add some overrides
>  - Merge branch 'master' into JDK-8337981-shenandoah-is-in
>  - Style touchups
>  - Fixing ShenandoahReferenceProcessor
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/b2c2bda0...2da163d1

All right, thanks! Integrating now then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20492#issuecomment-2298300216

From shade at openjdk.org  Tue Aug 20 08:43:55 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Aug 2024 08:43:55 GMT
Subject: Integrated: 8337981: ShenandoahHeap::is_in should check for alive
 regions
In-Reply-To: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
References: <eBsXjv73d1SOHUssmNEKvjDKcIEFhxKYDk1xRmyM-Oo=.35385db1-22e9-4f04-815e-57d58e51b536@github.com>
Message-ID: <rGo1RtglkDLyFt2zfcLJssAUrrhp6D5uibiuqs3jsjk=.babd2a5a-3f5e-4ffa-9127-fc0d37bfd771@github.com>

On Wed, 7 Aug 2024 11:51:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The expected behavior of `CollectedHeap::is_in` is to check whether the object belongs to the committed parts of the heap:
> https://github.com/openjdk/jdk/blob/d19ba81ce12a99de1114c1bfe67392f5aee2104e/src/hotspot/share/gc/shared/collectedHeap.hpp#L273-L276
> 
> This is useful to check if object resides in the parts of the heap the GC knows are not dead. Yet, Shenandoah's check just verifies that oop is within the heap bounds. So `is_in` check for an object that is in trashed/empty region would pass by accident, and we will miss detecting bugs. This should be rectified. I believe "committed" is too weak for the test as well, since we really want to know if we can touch the object, i.e. if it is in active region.
> 
> I re-wired assertions/verification code to be clear whether we check for heap bounds or actual in-heap conditions.
> 
> Deeper testing revealed that reference processing code potentially loads a dead referent, but only to null-check it, or ask bitmap about it. Still, more precise `in_heap` check fails asserts in `CompressedOops::decode`. That required a bit of touchup as well.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC`
>  - [x] Linux AArch64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`

This pull request has now been integrated.

Changeset: b9d49dce
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9d49dcef22ab81a087d890bbac0329a5244a2ef
Stats:     118 lines in 12 files changed: 58 ins; 7 del; 53 mod

8337981: ShenandoahHeap::is_in should check for alive regions

Reviewed-by: rkennke, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/20492

From shade at openjdk.org  Tue Aug 20 09:03:12 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Aug 2024 09:03:12 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v3]
In-Reply-To: <_osGhXGhNmSlk8psnto4scWg8gwOrnP2MbneNUPfa-0=.3a73a444-141f-4f97-a3f6-7daaa70124ef@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <_osGhXGhNmSlk8psnto4scWg8gwOrnP2MbneNUPfa-0=.3a73a444-141f-4f97-a3f6-7daaa70124ef@github.com>
Message-ID: <bsu4XgNmTn_dAI3JziwOyQxlEEmLrIIzAyflu9luqjo=.7d110f8b-fe2f-4247-bbd8-026f03634964@github.com>

On Tue, 20 Aug 2024 00:05:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
>> 2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
>> 3. Remove unhelpful comment from shenandoahFullGC.cpp
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code touchup
>   
>   Remove 2 unneeded blank lines
>   Move and simplify a comment from call point to called method
>   implementation

Understand the intent: it is good to have guardrail that checks the tags. Stylistic nits:

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 73:

> 71: 
> 72:   virtual void choose_collection_set_from_regiondata(ShenandoahCollectionSet* cset,
> 73:                                                      RegionData data[], size_t size,

Not at all sure this is a great style. It is also not consistent with the rest of Hotspot: searching for `[],` or `[] ` in `.cpp` files yields no hits. Leave it be at `RegionData*`.

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/475#pullrequestreview-2247391390
PR Review Comment: https://git.openjdk.org/shenandoah/pull/475#discussion_r1722952459

From shade at openjdk.org  Tue Aug 20 10:27:21 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Aug 2024 10:27:21 GMT
Subject: RFR: 8338662: Shenandoah: Remove excessive
 ShenandoahVerifier::verify_during_evacuation
Message-ID: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>

`ShenandoahVerifier::verify_during_evacuation` is a relaxed version of `ShenandoahVerifier::verify_before_evacuation`. In current code, "during" verification is called shortly after "before" check, which really gains us nothing checking-wise, and only really wastes verification time. This is the only "during" verification check we have, all other checks verify things before/after the phases. It makes sense to remove "during evac" verification check for extra debug performance and cleanliness. 

Additional testing:
 - [ ] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
 - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/20641/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20641&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338662
  Stats: 39 lines in 4 files changed: 4 ins; 34 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20641.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20641/head:pull/20641

PR: https://git.openjdk.org/jdk/pull/20641

From wkemper at openjdk.org  Tue Aug 20 16:19:22 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Aug 2024 16:19:22 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <bZJpsoEBGKa6HW6qlPDdK7d8yFLxQjiIs21hcft1T3I=.b75c4baa-4c04-4084-9b2f-a8e893ec6e2c@github.com>
References: <bZJpsoEBGKa6HW6qlPDdK7d8yFLxQjiIs21hcft1T3I=.b75c4baa-4c04-4084-9b2f-a8e893ec6e2c@github.com>
Message-ID: <5YuAttBDMWOQ91oUpa8zxKQ09hyaJg3o-qZiIXI_W00=.479e6b3d-a4df-4b2d-bd91-9ce68d570e5d@github.com>

On Fri, 16 Aug 2024 14:10:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+11

This pull request has now been integrated.

Changeset: 2ac54d51
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/2ac54d51d8abec8c89b99a6dad65b88b176e3c52
Stats:     8775 lines in 323 files changed: 3565 ins; 4039 del; 1171 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah/pull/473

From wkemper at openjdk.org  Tue Aug 20 16:47:04 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Aug 2024 16:47:04 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <ifJ35MHPxe2WBy6fKhuodLicTei8Ac1u5rT1SdUfiM4=.e03b9db4-b348-4783-8902-e3d320f31b5a@github.com>
References: <ifJ35MHPxe2WBy6fKhuodLicTei8Ac1u5rT1SdUfiM4=.e03b9db4-b348-4783-8902-e3d320f31b5a@github.com>
Message-ID: <wu4D0d1jcD5PQPfkh1vU1qZe0QEqSol4qrmlhuFekpI=.20f47ba7-faf0-439e-9eb7-051c90a8198f@github.com>

> Merges tag jdk-21.0.5+1

William Kemper 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/shenandoah-jdk21u/pull/70/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/70/files/2c9f741d..2c9f741d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=70&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=70&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/70.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/70/head:pull/70

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/70

From wkemper at openjdk.org  Tue Aug 20 16:48:05 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Aug 2024 16:48:05 GMT
Subject: RFR: 8338528: GenShen: Cleanup shenandoahHeapRegion
Message-ID: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>

* Break up huge methods in shenandoahHeapRegion
* Clarify comments
* Change confusing method names

-------------

Commit messages:
 - Merge remote-tracking branch 'shenandoah/master' into cleanup-heap-region
 - Break up large method, rename confusing method, fix typos, improve comments

Changes: https://git.openjdk.org/shenandoah/pull/476/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=476&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338528
  Stats: 79 lines in 6 files changed: 29 ins; 28 del; 22 mod
  Patch: https://git.openjdk.org/shenandoah/pull/476.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/476/head:pull/476

PR: https://git.openjdk.org/shenandoah/pull/476

From wkemper at openjdk.org  Tue Aug 20 16:57:24 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Aug 2024 16:57:24 GMT
Subject: RFR: 8338620: GenShen: Distinguish between young and old collector in
 GC configuration
Message-ID: <lsgb4yhITd92fZZcglogXRBZFH3a-Ri3Ry93b3_B7lg=.528a4b90-23e7-407c-ac57-7ae9c87b1644@github.com>

Return `ShenandoahYoung` for `young_collector` under generational mode (continue returning `N/A` for other modes). Return `ShenandoahOld` for `old_collector` under generational mode (continue returning `Shenandoah` for other modes).

-------------

Commit messages:
 - Merge remote-tracking branch 'shenandoah/master' into distinguish-young-old-gc
 - Add ShenandoahYoung and ShenandoahOld gc names

Changes: https://git.openjdk.org/shenandoah/pull/477/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=477&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338620
  Stats: 36 lines in 2 files changed: 22 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/477.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/477/head:pull/477

PR: https://git.openjdk.org/shenandoah/pull/477

From wkemper at openjdk.org  Tue Aug 20 17:00:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Aug 2024 17:00:48 GMT
Subject: RFR: 8338528: GenShen: Cleanup shenandoahHeapRegion [v2]
In-Reply-To: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
References: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
Message-ID: <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>

> * Break up huge methods in shenandoahHeapRegion
> * Clarify comments
> * Change confusing method names

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Simplify case for scanning all references within humongous object

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/476/files
  - new: https://git.openjdk.org/shenandoah/pull/476/files/3eca1a04..79f6ca25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=476&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=476&range=00-01

  Stats: 5 lines in 2 files changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/476.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/476/head:pull/476

PR: https://git.openjdk.org/shenandoah/pull/476

From shade at openjdk.org  Tue Aug 20 17:05:52 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 20 Aug 2024 17:05:52 GMT
Subject: RFR: 8338688: Shenandoah: Avoid calling java_lang_Class accessors in
 asserts/verifier
Message-ID: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>

In GC verification code, we are not always safe to touch the klass directly. This becomes a problem in Lilliput, where loading klass from the from-space is erroneous. Lilliput would replace `obj->klass()` with `obj->forward_safe_klass()` to make it right in GC code. But accessors like `java_lang_Class` would not be fixed. So we are better avoiding using these `java_lang_Class` accessors in GC verification code, and use the loaded `klass` directly. 

Additional tests:
 - [ ] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
 - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/20651/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20651&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338688
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20651.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20651/head:pull/20651

PR: https://git.openjdk.org/jdk/pull/20651

From rkennke at openjdk.org  Tue Aug 20 17:10:03 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 20 Aug 2024 17:10:03 GMT
Subject: RFR: 8338688: Shenandoah: Avoid calling java_lang_Class accessors
 in asserts/verifier
In-Reply-To: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
References: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
Message-ID: <W4sOTbOV7S8zPsQZH-OlScSA-OfJhJd546ugv9LO6Fs=.e55be75a-f45a-428b-9d9e-76795b4d0af9@github.com>

On Tue, 20 Aug 2024 16:55:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GC verification code, we are not always safe to touch the klass directly. This becomes a problem in Lilliput, where loading klass from the from-space is erroneous. Lilliput would replace `obj->klass()` with `obj->forward_safe_klass()` to make it right in GC code. But accessors like `java_lang_Class` would not be fixed: they would instead rely on barriers to always be called on to-space objects.
> 
> So we are better avoiding using these `java_lang_Class` accessors in GC verification code, and use the loaded `klass` directly. 
> 
> Additional tests:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Looks good to me, and I verified that it fixes the problems that I've observed in Lilliput.

-------------

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20651#pullrequestreview-2248582655

From wkemper at openjdk.org  Tue Aug 20 18:57:12 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Aug 2024 18:57:12 GMT
Subject: RFR: 8338620: GenShen: Distinguish between young and old collector
 in GC configuration [v2]
In-Reply-To: <lsgb4yhITd92fZZcglogXRBZFH3a-Ri3Ry93b3_B7lg=.528a4b90-23e7-407c-ac57-7ae9c87b1644@github.com>
References: <lsgb4yhITd92fZZcglogXRBZFH3a-Ri3Ry93b3_B7lg=.528a4b90-23e7-407c-ac57-7ae9c87b1644@github.com>
Message-ID: <lLdXBmrJpajFK4mCfT0l4TIpYT69VyaHl_zSzVx2QZg=.bc085b3e-5920-4c49-88fd-340fed537142@github.com>

> Return `ShenandoahYoung` for `young_collector` under generational mode (continue returning `N/A` for other modes). Return `ShenandoahOld` for `old_collector` under generational mode (continue returning `Shenandoah` for other modes).

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Fix minimal variant build

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/477/files
  - new: https://git.openjdk.org/shenandoah/pull/477/files/3b2e8f45..ecad1ffb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=477&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=477&range=00-01

  Stats: 10 lines in 1 file changed: 6 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/477.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/477/head:pull/477

PR: https://git.openjdk.org/shenandoah/pull/477

From ysr at openjdk.org  Tue Aug 20 20:04:31 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 20 Aug 2024 20:04:31 GMT
Subject: RFR: 8338620: GenShen: Distinguish between young and old collector
 in GC configuration [v2]
In-Reply-To: <lLdXBmrJpajFK4mCfT0l4TIpYT69VyaHl_zSzVx2QZg=.bc085b3e-5920-4c49-88fd-340fed537142@github.com>
References: <lsgb4yhITd92fZZcglogXRBZFH3a-Ri3Ry93b3_B7lg=.528a4b90-23e7-407c-ac57-7ae9c87b1644@github.com>
 <lLdXBmrJpajFK4mCfT0l4TIpYT69VyaHl_zSzVx2QZg=.bc085b3e-5920-4c49-88fd-340fed537142@github.com>
Message-ID: <_jCKAGCVzNXV3_VSBHhQG6hKmo2t7oslz46Sq7q78Z4=.7179a7aa-8b10-4b31-8cb6-6d2762485983@github.com>

On Tue, 20 Aug 2024 18:57:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Return `ShenandoahYoung` for `young_collector` under generational mode (continue returning `N/A` for other modes). Return `ShenandoahOld` for `old_collector` under generational mode (continue returning `Shenandoah` for other modes).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minimal variant build

Marked as reviewed by ysr (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/477#pullrequestreview-2248989427

From kdnilsen at openjdk.org  Tue Aug 20 21:35:19 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 20 Aug 2024 21:35:19 GMT
Subject: RFR: 8338620: GenShen: Distinguish between young and old collector
 in GC configuration [v2]
In-Reply-To: <lLdXBmrJpajFK4mCfT0l4TIpYT69VyaHl_zSzVx2QZg=.bc085b3e-5920-4c49-88fd-340fed537142@github.com>
References: <lsgb4yhITd92fZZcglogXRBZFH3a-Ri3Ry93b3_B7lg=.528a4b90-23e7-407c-ac57-7ae9c87b1644@github.com>
 <lLdXBmrJpajFK4mCfT0l4TIpYT69VyaHl_zSzVx2QZg=.bc085b3e-5920-4c49-88fd-340fed537142@github.com>
Message-ID: <u0GafyAv2aQKppru9JYABJdbMW7OG1K0P_BoY6Fk1Cs=.3ffa4fa6-bb59-4d61-95e5-dc243fcbf128@github.com>

On Tue, 20 Aug 2024 18:57:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Return `ShenandoahYoung` for `young_collector` under generational mode (continue returning `N/A` for other modes). Return `ShenandoahOld` for `old_collector` under generational mode (continue returning `Shenandoah` for other modes).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minimal variant build

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/477#pullrequestreview-2249131737

From kdnilsen at openjdk.org  Tue Aug 20 21:49:22 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 20 Aug 2024 21:49:22 GMT
Subject: RFR: 8338528: GenShen: Cleanup shenandoahHeapRegion [v2]
In-Reply-To: <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>
References: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
 <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>
Message-ID: <6Erw1xGn8BpbRXx-RcPFFsf_UfABCbEzJOZ77r3tZ_0=.306292ba-9ab2-43df-ab01-3204a5eafeb5@github.com>

On Tue, 20 Aug 2024 17:00:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> * Break up huge methods in shenandoahHeapRegion
>> * Clarify comments
>> * Change confusing method names
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify case for scanning all references within humongous object

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 512:

> 510: }
> 511: 
> 512: void ShenandoahHeapRegion::oop_iterate_humongous_slice_dirty(OopIterateClosure* blk,

We're removing the dirty_only bool argument?  Was that always true for all callers?  Or always true if write table?

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/476#discussion_r1724010879

From kdnilsen at openjdk.org  Tue Aug 20 21:49:22 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 20 Aug 2024 21:49:22 GMT
Subject: RFR: 8338528: GenShen: Cleanup shenandoahHeapRegion [v2]
In-Reply-To: <6Erw1xGn8BpbRXx-RcPFFsf_UfABCbEzJOZ77r3tZ_0=.306292ba-9ab2-43df-ab01-3204a5eafeb5@github.com>
References: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
 <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>
 <6Erw1xGn8BpbRXx-RcPFFsf_UfABCbEzJOZ77r3tZ_0=.306292ba-9ab2-43df-ab01-3204a5eafeb5@github.com>
Message-ID: <p2ATFkEfyjT0hmk8-7GE0v-sRFLBg248TyEs4HEGBZU=.28585b0b-84ea-4eeb-9557-885171728496@github.com>

On Tue, 20 Aug 2024 21:45:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify case for scanning all references within humongous object
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 512:
> 
>> 510: }
>> 511: 
>> 512: void ShenandoahHeapRegion::oop_iterate_humongous_slice_dirty(OopIterateClosure* blk,
> 
> We're removing the dirty_only bool argument?  Was that always true for all callers?  Or always true if write table?

I see, I think.  You've introduced a new method to handle the not-dirty case.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/476#discussion_r1724011895

From kdnilsen at openjdk.org  Tue Aug 20 21:52:18 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 20 Aug 2024 21:52:18 GMT
Subject: RFR: 8338528: GenShen: Cleanup shenandoahHeapRegion [v2]
In-Reply-To: <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>
References: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
 <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>
Message-ID: <wVk7v8XntNreBMLDX6sTOylv_abap1tIWPxltUKOh3o=.455c89ef-d721-422f-91f1-7736b6397cdf@github.com>

On Tue, 20 Aug 2024 17:00:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> * Break up huge methods in shenandoahHeapRegion
>> * Clarify comments
>> * Change confusing method names
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify case for scanning all references within humongous object

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/476#pullrequestreview-2249154106

From wkemper at openjdk.org  Tue Aug 20 22:50:18 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 20 Aug 2024 22:50:18 GMT
Subject: RFR: 8338528: GenShen: Cleanup shenandoahHeapRegion [v2]
In-Reply-To: <p2ATFkEfyjT0hmk8-7GE0v-sRFLBg248TyEs4HEGBZU=.28585b0b-84ea-4eeb-9557-885171728496@github.com>
References: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
 <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>
 <6Erw1xGn8BpbRXx-RcPFFsf_UfABCbEzJOZ77r3tZ_0=.306292ba-9ab2-43df-ab01-3204a5eafeb5@github.com>
 <p2ATFkEfyjT0hmk8-7GE0v-sRFLBg248TyEs4HEGBZU=.28585b0b-84ea-4eeb-9557-885171728496@github.com>
Message-ID: <rOqruQ_VQtccsOylGc43TEdsNWGQ3tCr3Ea0HXhQoK8=.df7da679-5c75-4fb5-b70e-6d653a8a084e@github.com>

On Tue, 20 Aug 2024 21:46:57 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 512:
>> 
>>> 510: }
>>> 511: 
>>> 512: void ShenandoahHeapRegion::oop_iterate_humongous_slice_dirty(OopIterateClosure* blk,
>> 
>> We're removing the dirty_only bool argument?  Was that always true for all callers?  Or always true if write table?
>
> I see, I think.  You've introduced a new method to handle the not-dirty case.

The original method was split it into two. The code path that handles _all_ cards didn't actually even need to look at the card table. The call sites where `dirty_only == false` call this new method. The call sites where `dirty_only == true` call this `oop_iterate_humongous_slice_dirty`.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/476#discussion_r1724067551

From ysr at openjdk.org  Wed Aug 21 08:38:22 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 21 Aug 2024 08:38:22 GMT
Subject: RFR: 8338528: GenShen: Cleanup shenandoahHeapRegion [v2]
In-Reply-To: <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>
References: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
 <MvCNcmZlEeDynEtMOZslykj-CdIMlpYt2EZTYYDxjVU=.92e05f78-8e2a-4823-b574-2e8e976509e7@github.com>
Message-ID: <ZHrOZBEjTHMZAauQBcYkb8OY2V7kJQ5xQsN6PIJNdBo=.2d909191-7701-4c4d-b139-fee456edf11d@github.com>

On Tue, 20 Aug 2024 17:00:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> * Break up huge methods in shenandoahHeapRegion
>> * Clarify comments
>> * Change confusing method names
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify case for scanning all references within humongous object

LGTM.

Prior to landing the changes, please record in the PR summary the testing that was done.

-------------

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/476#pullrequestreview-2250160340

From ysr at openjdk.org  Wed Aug 21 08:51:04 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 21 Aug 2024 08:51:04 GMT
Subject: RFR: 8338717: GenShen: Fix up some assertions
Message-ID: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>

In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various assertions. This ticket gathers together several of those changes.

**Testing:**
- [ ] GHA
- [ ] jtreg:tier1
- [ ] Codepipeline
- [ ] SPECjbb w/GenShen

-------------

Commit messages:
 - Unref variable deleted so as to eliminate -werror on Windows.
 - Fix up some assertions etc. based on review feedback from Shipilev.

Changes: https://git.openjdk.org/shenandoah/pull/478/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338717
  Stats: 74 lines in 9 files changed: 49 ins; 8 del; 17 mod
  Patch: https://git.openjdk.org/shenandoah/pull/478.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/478/head:pull/478

PR: https://git.openjdk.org/shenandoah/pull/478

From shade at openjdk.org  Wed Aug 21 09:02:25 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Aug 2024 09:02:25 GMT
Subject: RFR: 8338717: GenShen: Fix up some assertions
In-Reply-To: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
References: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
Message-ID: <2psdSSxxC-ZXKc0WEsYeCOQ6x_gzvdx5nmjOkpLqLrA=.41b2f380-4b8d-43f2-a107-eedadfd05b25@github.com>

On Wed, 21 Aug 2024 08:17:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various assertions. This ticket gathers together several of those changes.
> 
> **Testing:**
> - [ ] GHA
> - [ ] jtreg:tier1
> - [ ] Codepipeline
> - [ ] SPECjbb w/GenShen

Marked as reviewed by shade (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/478#pullrequestreview-2250219242

From shade at openjdk.org  Wed Aug 21 15:31:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Aug 2024 15:31:03 GMT
Subject: RFR: 8338688: Shenandoah: Avoid calling java_lang_Class accessors
 in asserts/verifier
In-Reply-To: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
References: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
Message-ID: <AvO7xG16wtW0QitLMgeTuu0iasW3nKH3Nvy_mWOdeI0=.b4019654-e393-43b3-a522-a938c8398e12@github.com>

On Tue, 20 Aug 2024 16:55:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GC verification code, we are not always safe to touch the klass directly. This becomes a problem in Lilliput, where loading klass from the from-space is erroneous. Lilliput would replace `obj->klass()` with `obj->forward_safe_klass()` to make it right in GC code. But accessors like `java_lang_Class` would not be fixed: they would instead rely on barriers to always be called on to-space objects.
> 
> So we are better avoiding using these `java_lang_Class` accessors in GC verification code, and use the loaded `klass` directly. 
> 
> Additional tests:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Thanks! I think I need a second review, @earthling-amzn ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20651#issuecomment-2302377707

From wkemper at openjdk.org  Wed Aug 21 16:07:29 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 16:07:29 GMT
Subject: Integrated: 8338620: GenShen: Distinguish between young and old
 collector in GC configuration
In-Reply-To: <lsgb4yhITd92fZZcglogXRBZFH3a-Ri3Ry93b3_B7lg=.528a4b90-23e7-407c-ac57-7ae9c87b1644@github.com>
References: <lsgb4yhITd92fZZcglogXRBZFH3a-Ri3Ry93b3_B7lg=.528a4b90-23e7-407c-ac57-7ae9c87b1644@github.com>
Message-ID: <G8Gmtz8OyCNdTKPSVVbN3bdUr0rzrp6kfhUe2DjtcKw=.11ffdeac-7843-49a3-9b1a-8c14ade20d5e@github.com>

On Tue, 20 Aug 2024 16:38:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Return `ShenandoahYoung` for `young_collector` under generational mode (continue returning `N/A` for other modes). Return `ShenandoahOld` for `old_collector` under generational mode (continue returning `Shenandoah` for other modes).

This pull request has now been integrated.

Changeset: e31d1e49
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/e31d1e49885f02ae25bd5758c8d4a2705f4b97e1
Stats:     38 lines in 2 files changed: 24 ins; 14 del; 0 mod

8338620: GenShen: Distinguish between young and old collector in GC configuration

Reviewed-by: ysr, kdnilsen

-------------

PR: https://git.openjdk.org/shenandoah/pull/477

From wkemper at openjdk.org  Wed Aug 21 16:09:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 16:09:42 GMT
Subject: Integrated: 8338528: GenShen: Cleanup shenandoahHeapRegion
In-Reply-To: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
References: <XvuDB7LmMd_fPYTbIA3SMzRy6qDZemUCVYj2pDEkWiU=.432416c4-99da-4d51-8f6f-421b71dca02e@github.com>
Message-ID: <3u7GTEIg8Pvhic-hQ5WUftR8ZVNYMgydQCQYoLW3IxY=.379e0a8e-7a7e-47e2-9856-5d24fe61ebd8@github.com>

On Tue, 20 Aug 2024 16:28:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Break up huge methods in shenandoahHeapRegion
> * Clarify comments
> * Change confusing method names
> 
> ## Testing
> 
> GHA, internal pipelines: dacapo, extremem, specjbb2015, specjvm2008, dilluvian, heapothesys with and without gc stress flags.

This pull request has now been integrated.

Changeset: 27d0e617
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/27d0e617f97be03fae0b110ca58a3860c15d5679
Stats:     81 lines in 6 files changed: 31 ins; 28 del; 22 mod

8338528: GenShen: Cleanup shenandoahHeapRegion

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/shenandoah/pull/476

From shade at openjdk.org  Wed Aug 21 16:13:11 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Aug 2024 16:13:11 GMT
Subject: Integrated: 8338688: Shenandoah: Avoid calling java_lang_Class
 accessors in asserts/verifier
In-Reply-To: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
References: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
Message-ID: <VacDiRnXZheoxUtCtUT7Qn380WLnZy4DHyx4SZBlvQY=.2c692788-9579-4059-90a3-3cff93a4bfe5@github.com>

On Tue, 20 Aug 2024 16:55:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GC verification code, we are not always safe to touch the klass directly. This becomes a problem in Lilliput, where loading klass from the from-space is erroneous. Lilliput would replace `obj->klass()` with `obj->forward_safe_klass()` to make it right in GC code. But accessors like `java_lang_Class` would not be fixed: they would instead rely on barriers to always be called on to-space objects.
> 
> So we are better avoiding using these `java_lang_Class` accessors in GC verification code, and use the loaded `klass` directly. 
> 
> Additional tests:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

This pull request has now been integrated.

Changeset: e297e881
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e297e8817f486e4af850c97fcff859c3e9a9e21c
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8338688: Shenandoah: Avoid calling java_lang_Class accessors in asserts/verifier

Reviewed-by: rkennke, wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/20651

From wkemper at openjdk.org  Wed Aug 21 16:13:10 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 16:13:10 GMT
Subject: RFR: 8338688: Shenandoah: Avoid calling java_lang_Class accessors
 in asserts/verifier
In-Reply-To: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
References: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
Message-ID: <kKsJQD8nuHEOcDQVNGGlIZIfTrN1w0unJONKE-gLKys=.21f2e9a9-a01d-4fd0-ade7-348fe2393b27@github.com>

On Tue, 20 Aug 2024 16:55:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GC verification code, we are not always safe to touch the klass directly. This becomes a problem in Lilliput, where loading klass from the from-space is erroneous. Lilliput would replace `obj->klass()` with `obj->forward_safe_klass()` to make it right in GC code. But accessors like `java_lang_Class` would not be fixed: they would instead rely on barriers to always be called on to-space objects.
> 
> So we are better avoiding using these `java_lang_Class` accessors in GC verification code, and use the loaded `klass` directly. 
> 
> Additional tests:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Thanks, LGTM.

-------------

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20651#pullrequestreview-2251295201

From shade at openjdk.org  Wed Aug 21 16:13:11 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 21 Aug 2024 16:13:11 GMT
Subject: RFR: 8338688: Shenandoah: Avoid calling java_lang_Class accessors
 in asserts/verifier
In-Reply-To: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
References: <oc4TO_X5yKUVc-2l2fgvfrzBQZWc6Q2ArXyypfiXxjI=.ac2c4722-9af1-4e39-9f22-963118252a87@github.com>
Message-ID: <BOg_pcNR7uK8ncgb690vy26JW9UvLGuw1bt6REP16RM=.7b9ac1f4-a007-41e8-aef3-cc1899634054@github.com>

On Tue, 20 Aug 2024 16:55:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> In GC verification code, we are not always safe to touch the klass directly. This becomes a problem in Lilliput, where loading klass from the from-space is erroneous. Lilliput would replace `obj->klass()` with `obj->forward_safe_klass()` to make it right in GC code. But accessors like `java_lang_Class` would not be fixed: they would instead rely on barriers to always be called on to-space objects.
> 
> So we are better avoiding using these `java_lang_Class` accessors in GC verification code, and use the loaded `klass` directly. 
> 
> Additional tests:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC`

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20651#issuecomment-2302462734

From wkemper at openjdk.org  Wed Aug 21 17:53:46 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 17:53:46 GMT
Subject: RFR: 8338695: GenShen: Clean up jtreg tests
Message-ID: <PB-gvJm9nZws1yuP3WDP6fKXTlhEe7qKfvf7B61vW9g=.709a4e2a-96cf-448d-afe9-48cf03d6ed5f@github.com>

* Reformat new jtreg tests for generational mode
* Run tests with verifier enabled first
* Include generational mode in barrier enable/disable tests (and fix passive mode)

## Testing

* GHA
* internal tests
* make exploded-test TEST="hotspot_gc_shenandoah"

-------------

Commit messages:
 - Fix compilation errors, don't let passive mode run with card barrier enabled
 - Fix compilation errors
 - Clean up tests

Changes: https://git.openjdk.org/shenandoah/pull/480/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=480&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338695
  Stats: 496 lines in 17 files changed: 123 ins; 196 del; 177 mod
  Patch: https://git.openjdk.org/shenandoah/pull/480.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/480/head:pull/480

PR: https://git.openjdk.org/shenandoah/pull/480

From wkemper at openjdk.org  Wed Aug 21 18:05:29 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 18:05:29 GMT
Subject: RFR: 8338717: GenShen: Fix up some assertions
In-Reply-To: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
References: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
Message-ID: <RSbKdERZIrO-X66R-kHW9uXY9i31p_d88JxYO68wpGA=.ed0171f0-0426-4a78-944d-5e6f2fb7eb10@github.com>

On Wed, 21 Aug 2024 08:17:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various assertions. This ticket gathers together several of those changes.
> 
> **Testing:**
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] Codepipeline (investigating what appears to be an unrelated failure I encountered in testing)
> - [ ] SPECjbb w/GenShen (in progress)

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/478#pullrequestreview-2251549798

From wkemper at openjdk.org  Wed Aug 21 18:01:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 18:01:03 GMT
Subject: RFR: 8338662: Shenandoah: Remove excessive
 ShenandoahVerifier::verify_during_evacuation
In-Reply-To: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>
References: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>
Message-ID: <XlT0jujJiq3lAy84FXfduPIDgBhpQx0xlJPz8Tf3aQg=.db48f90f-a92d-4900-9e57-50623787aebf@github.com>

On Tue, 20 Aug 2024 10:22:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `ShenandoahVerifier::verify_during_evacuation` is a relaxed version of `ShenandoahVerifier::verify_before_evacuation`. In current code, "during" verification is called shortly after "before" check, which really gains us nothing checking-wise, and only really wastes verification time. This is the only "during" verification check we have, all other checks verify things before/after the phases. It makes sense to remove "during evac" verification check for extra debug performance and cleanliness. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`

Looks okay to me.

-------------

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20641#pullrequestreview-2251541139

From kdnilsen at openjdk.org  Wed Aug 21 19:00:32 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 21 Aug 2024 19:00:32 GMT
Subject: RFR: 8338695: GenShen: Clean up jtreg tests
In-Reply-To: <PB-gvJm9nZws1yuP3WDP6fKXTlhEe7qKfvf7B61vW9g=.709a4e2a-96cf-448d-afe9-48cf03d6ed5f@github.com>
References: <PB-gvJm9nZws1yuP3WDP6fKXTlhEe7qKfvf7B61vW9g=.709a4e2a-96cf-448d-afe9-48cf03d6ed5f@github.com>
Message-ID: <t3_bQ-GLpcy3x2QGbwsEJzt-pJOa9pFYLjw0p0K72T8=.12049348-b448-48fe-aa5e-d0576a16fd07@github.com>

On Wed, 21 Aug 2024 17:47:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Reformat new jtreg tests for generational mode
> * Run tests with verifier enabled first
> * Include generational mode in barrier enable/disable tests (and fix passive mode)
> 
> ## Testing
> 
> * GHA
> * internal tests
> * make exploded-test TEST="hotspot_gc_shenandoah"

Thanks for this meticulous work...

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/480#pullrequestreview-2251663467

From ysr at openjdk.org  Wed Aug 21 19:18:31 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 21 Aug 2024 19:18:31 GMT
Subject: RFR: 8338717: GenShen: Fix up some assertions [v2]
In-Reply-To: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
References: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
Message-ID: <fy5hOQPFJ2bVgo4M8S3tbSzeJXJItOhIoGNxh7Ydk7o=.be002fd8-9676-4626-8ec6-58fc6f6d20a8@github.com>

> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various assertions. This ticket gathers together several of those changes.
> 
> **Testing:**
> - [x] GHA
> - [x] jtreg:tier1
> - [ ] Codepipeline (investigating what appears to be an unrelated failure I encountered in testing)
> - [ ] SPECjbb w/GenShen (in progress)

Y. Srinivas Ramakrishna 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 three additional commits since the last revision:

 - Merge branch 'master' into review_assert
 - Unref variable deleted so as to eliminate -werror on Windows.
 - Fix up some assertions etc. based on review feedback from Shipilev.

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/478/files
  - new: https://git.openjdk.org/shenandoah/pull/478/files/b95c26df..21061519

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=478&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=478&range=00-01

  Stats: 119 lines in 8 files changed: 55 ins; 42 del; 22 mod
  Patch: https://git.openjdk.org/shenandoah/pull/478.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/478/head:pull/478

PR: https://git.openjdk.org/shenandoah/pull/478

From ysr at openjdk.org  Wed Aug 21 19:31:04 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 21 Aug 2024 19:31:04 GMT
Subject: RFR: 8338662: Shenandoah: Remove excessive
 ShenandoahVerifier::verify_during_evacuation
In-Reply-To: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>
References: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>
Message-ID: <LVF1SxGTePcRBv-lBm5zT-SulghN8siMitwZf7vBcTw=.bdae566d-1106-4ca7-a7dc-646f615f771f@github.com>

On Tue, 20 Aug 2024 10:22:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `ShenandoahVerifier::verify_during_evacuation` is a relaxed version of `ShenandoahVerifier::verify_before_evacuation`. In current code, "during" verification is called shortly after "before" check, which really gains us nothing checking-wise, and only really wastes verification time. This is the only "during" verification check we have, all other checks verify things before/after the phases. It makes sense to remove "during evac" verification check for extra debug performance and cleanliness. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`

LGTM.

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20641#pullrequestreview-2251773370

From kdnilsen at openjdk.org  Wed Aug 21 20:18:30 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 21 Aug 2024 20:18:30 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v3]
In-Reply-To: <bsu4XgNmTn_dAI3JziwOyQxlEEmLrIIzAyflu9luqjo=.7d110f8b-fe2f-4247-bbd8-026f03634964@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <_osGhXGhNmSlk8psnto4scWg8gwOrnP2MbneNUPfa-0=.3a73a444-141f-4f97-a3f6-7daaa70124ef@github.com>
 <bsu4XgNmTn_dAI3JziwOyQxlEEmLrIIzAyflu9luqjo=.7d110f8b-fe2f-4247-bbd8-026f03634964@github.com>
Message-ID: <BcWUzUhpd4aNR--AIZunBC9CL55eF9jP5-kCS2LBZ7Y=.51e69d3d-7545-4cf6-ae28-0f69de3ded59@github.com>

On Tue, 20 Aug 2024 08:58:43 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code touchup
>>   
>>   Remove 2 unneeded blank lines
>>   Move and simplify a comment from call point to called method
>>   implementation
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp line 73:
> 
>> 71: 
>> 72:   virtual void choose_collection_set_from_regiondata(ShenandoahCollectionSet* cset,
>> 73:                                                      RegionData data[], size_t size,
> 
> Not at all sure this is a great style. It is also not consistent with the rest of Hotspot: searching for `[],` or `[] ` in `.cpp` files yields no hits. Leave it be at `RegionData*`.

Will revert these changes.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/475#discussion_r1725703307

From kdnilsen at openjdk.org  Wed Aug 21 20:18:30 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 21 Aug 2024 20:18:30 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v2]
In-Reply-To: <Y26jVo4AWJk3lT-rFBgm5pYpskux0RGv78W3sNQVQVc=.86f6fe23-dd14-4578-8ffe-8cdafb175113@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <AktNBkbN0jT-EnyvagiOFg30iD5lFyAaWkWHji03vdA=.cdf9ac43-683e-4ee2-8bb7-745f60a51c8d@github.com>
 <oqyEOLwEl8SM-Rdk5x6D5OqHWOacYC-q5KvsIKCTDXc=.b0089f36-e794-48c7-9451-36312b666d2e@github.com>
 <Y26jVo4AWJk3lT-rFBgm5pYpskux0RGv78W3sNQVQVc=.86f6fe23-dd14-4578-8ffe-8cdafb175113@github.com>
Message-ID: <UvV7mKlnUqNLChhWL6AzhN_9Vz702DvTp0xZPXoPdrs=.14e0720f-e913-47d7-b83c-66f156675809@github.com>

On Mon, 19 Aug 2024 21:46:36 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 92:
>> 
>>> 90:   } RegionData;
>>> 91: 
>>> 92:   static inline void set_RegionData_region_and_garbage(RegionData& region_data, ShenandoahHeapRegion* region, size_t garbage) {
>> 
>> Can these static functions just be instance methods? call sites would then be:
>> ```C++
>> region_data->set_region_and_garbage(region, garbage);
>
> +1

very good suggestions.  it looks much better this way.  will make this change momentarily.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/475#discussion_r1725704053

From kdnilsen at openjdk.org  Wed Aug 21 20:32:03 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 21 Aug 2024 20:32:03 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v4]
In-Reply-To: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
Message-ID: <I652vATBD5kw6T5HBCNTbl2Gnqh0j0Guglp-MleB3vg=.8d39accb-8c03-4615-91ec-16d2bef02a82@github.com>

> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
> 2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
> 3. Remove unhelpful comment from shenandoahFullGC.cpp

Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:

 - Remove deprecated code
 - Revert changes to declaration of RegionData array argument
   
   Use RegionData* rather than RegionData[] declaration style for
   consistency with other hotspot code.
 - Turn RegionData into a class and fix accessors

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/475/files
  - new: https://git.openjdk.org/shenandoah/pull/475/files/83e84fce..15cdbada

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=03
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=02-03

  Stats: 92 lines in 20 files changed: 10 ins; 7 del; 75 mod
  Patch: https://git.openjdk.org/shenandoah/pull/475.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/475/head:pull/475

PR: https://git.openjdk.org/shenandoah/pull/475

From kdnilsen at openjdk.org  Wed Aug 21 20:34:47 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 21 Aug 2024 20:34:47 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v5]
In-Reply-To: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
Message-ID: <33kPwkMGq1l99va2tcC9ykRj3zI821GG36w1ZHM6o20=.fabfc6f4-063f-474a-9445-b075d4dcc752@github.com>

> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
> 2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
> 3. Remove unhelpful comment from shenandoahFullGC.cpp

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/475/files
  - new: https://git.openjdk.org/shenandoah/pull/475/files/15cdbada..b6f06a4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=04
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/475.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/475/head:pull/475

PR: https://git.openjdk.org/shenandoah/pull/475

From ysr at openjdk.org  Wed Aug 21 22:36:16 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 21 Aug 2024 22:36:16 GMT
Subject: RFR: 8338695: GenShen: Clean up jtreg tests
In-Reply-To: <PB-gvJm9nZws1yuP3WDP6fKXTlhEe7qKfvf7B61vW9g=.709a4e2a-96cf-448d-afe9-48cf03d6ed5f@github.com>
References: <PB-gvJm9nZws1yuP3WDP6fKXTlhEe7qKfvf7B61vW9g=.709a4e2a-96cf-448d-afe9-48cf03d6ed5f@github.com>
Message-ID: <8mD-sUdHexDsH-l0LmF5kj6UKvVcHsdhePah4RJczeU=.946aae59-4ea7-4835-9f6e-78b7cab6875f@github.com>

On Wed, 21 Aug 2024 17:47:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Reformat new jtreg tests for generational mode
> * Run tests with verifier enabled first
> * Include generational mode in barrier enable/disable tests (and fix passive mode)
> 
> ## Testing
> 
> * GHA
> * internal tests
> * make exploded-test TEST="hotspot_gc_shenandoah"

LGTM.

-------------

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/480#pullrequestreview-2252162589

From wkemper at openjdk.org  Wed Aug 21 22:50:24 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 22:50:24 GMT
Subject: Integrated: 8338695: GenShen: Clean up jtreg tests
In-Reply-To: <PB-gvJm9nZws1yuP3WDP6fKXTlhEe7qKfvf7B61vW9g=.709a4e2a-96cf-448d-afe9-48cf03d6ed5f@github.com>
References: <PB-gvJm9nZws1yuP3WDP6fKXTlhEe7qKfvf7B61vW9g=.709a4e2a-96cf-448d-afe9-48cf03d6ed5f@github.com>
Message-ID: <8sbUoteaQBvwnSpUtz8cIPRJxirBzTgGANf0cDkiNEU=.3da5a043-1c4c-4337-a06b-f5ff3d26ad1a@github.com>

On Wed, 21 Aug 2024 17:47:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Reformat new jtreg tests for generational mode
> * Run tests with verifier enabled first
> * Include generational mode in barrier enable/disable tests (and fix passive mode)
> 
> ## Testing
> 
> * GHA
> * internal tests
> * make exploded-test TEST="hotspot_gc_shenandoah"

This pull request has now been integrated.

Changeset: 49994b3f
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/49994b3f2e84063eeec9ab493af7ba9d0c165e79
Stats:     496 lines in 17 files changed: 123 ins; 196 del; 177 mod

8338695: GenShen: Clean up jtreg tests

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/shenandoah/pull/480

From wkemper at openjdk.org  Wed Aug 21 23:05:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 23:05:17 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v5]
In-Reply-To: <33kPwkMGq1l99va2tcC9ykRj3zI821GG36w1ZHM6o20=.fabfc6f4-063f-474a-9445-b075d4dcc752@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <33kPwkMGq1l99va2tcC9ykRj3zI821GG36w1ZHM6o20=.fabfc6f4-063f-474a-9445-b075d4dcc752@github.com>
Message-ID: <LGNmgC40G9OdnPEZCF9KbRk-RK8Dex6acqsRJ60dVF4=.c5aab26f-4f1b-40fb-b06c-f028f3186b38@github.com>

On Wed, 21 Aug 2024 20:34:47 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
>> 2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
>> 3. Remove unhelpful comment from shenandoahFullGC.cpp
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp line 39:

> 37:   friend class ShenandoahCollectionSetPreselector;
> 38: 
> 39:   void establish_preselected(bool preselected[]) {

Are we going with `bool* preselected` now?

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/475#pullrequestreview-2252250037
PR Review Comment: https://git.openjdk.org/shenandoah/pull/475#discussion_r1725944837

From kdnilsen at openjdk.org  Wed Aug 21 23:13:27 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 21 Aug 2024 23:13:27 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v6]
In-Reply-To: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
Message-ID: <Hja5VQt1BSoAT0rL0gWnrGaQIuTHLzeqi0iPZpQNyxw=.4d22419a-e518-4d4f-acc6-7cccad56a5ae@github.com>

> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
> 2. Change type of ShenandoahCollectionSet::establish_preselected from byte* to byte[] to clarify intended usage.
> 3. Remove unhelpful comment from shenandoahFullGC.cpp

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix another array parameter declaration

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/475/files
  - new: https://git.openjdk.org/shenandoah/pull/475/files/b6f06a4a..33b63ee5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=05
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=475&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/475.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/475/head:pull/475

PR: https://git.openjdk.org/shenandoah/pull/475

From kdnilsen at openjdk.org  Wed Aug 21 23:13:28 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 21 Aug 2024 23:13:28 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v5]
In-Reply-To: <LGNmgC40G9OdnPEZCF9KbRk-RK8Dex6acqsRJ60dVF4=.c5aab26f-4f1b-40fb-b06c-f028f3186b38@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <33kPwkMGq1l99va2tcC9ykRj3zI821GG36w1ZHM6o20=.fabfc6f4-063f-474a-9445-b075d4dcc752@github.com>
 <LGNmgC40G9OdnPEZCF9KbRk-RK8Dex6acqsRJ60dVF4=.c5aab26f-4f1b-40fb-b06c-f028f3186b38@github.com>
Message-ID: <WRFhehmXar-k_X5PhTGy_AbW12u1vRE0K-u_5wRjwps=.bb1ab3f6-7db5-47af-a08c-4e0929c18fa8@github.com>

On Wed, 21 Aug 2024 23:02:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp line 39:
> 
>> 37:   friend class ShenandoahCollectionSetPreselector;
>> 38: 
>> 39:   void establish_preselected(bool preselected[]) {
> 
> Are we going with `bool* preselected` now?

Thanks for finding that.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/475#discussion_r1725949055

From ysr at openjdk.org  Wed Aug 21 23:32:17 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 21 Aug 2024 23:32:17 GMT
Subject: RFR: 8338717: GenShen: Fix up some assertions [v2]
In-Reply-To: <fy5hOQPFJ2bVgo4M8S3tbSzeJXJItOhIoGNxh7Ydk7o=.be002fd8-9676-4626-8ec6-58fc6f6d20a8@github.com>
References: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
 <fy5hOQPFJ2bVgo4M8S3tbSzeJXJItOhIoGNxh7Ydk7o=.be002fd8-9676-4626-8ec6-58fc6f6d20a8@github.com>
Message-ID: <adsQCgxWoune1Be0OUhilX44vKaZU2-sTXy99PMpaiU=.3abc054d-213b-426c-a6b9-25c85cb87de8@github.com>

On Wed, 21 Aug 2024 19:18:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various assertions. This ticket gathers together several of those changes.
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] jtreg:tier1
>> - [x] Codepipeline (investigating what appears to be an unrelated failure I encountered in testing)
>> - [x] SPECjbb w/GenShen (in progress)
>
> Y. Srinivas Ramakrishna 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into review_assert
>  - Unref variable deleted so as to eliminate -werror on Windows.
>  - Fix up some assertions etc. based on review feedback from Shipilev.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/478#issuecomment-2303289586

From ysr at openjdk.org  Wed Aug 21 23:32:17 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 21 Aug 2024 23:32:17 GMT
Subject: Integrated: 8338717: GenShen: Fix up some assertions
In-Reply-To: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
References: <3pOTF_LaBUnsstsQxoEL8VKRordNm6xnnUWl_30AlrU=.4e4e34e2-e3e7-4cdd-804d-b1684756016a@github.com>
Message-ID: <G5yeFTgA_4NxzI0Ho2FRYEuvF9takTGnoNcYz8CUO08=.e81da4c7-09b0-4031-9ac4-6c5bea23a480@github.com>

On Wed, 21 Aug 2024 08:17:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various assertions. This ticket gathers together several of those changes.
> 
> **Testing:**
> - [x] GHA
> - [x] jtreg:tier1
> - [x] Codepipeline (investigating what appears to be an unrelated failure I encountered in testing)
> - [x] SPECjbb w/GenShen (in progress)

This pull request has now been integrated.

Changeset: d7e22354
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/d7e22354f30a1260fc55006cafe8fd80bdad9e04
Stats:     74 lines in 9 files changed: 49 ins; 8 del; 17 mod

8338717: GenShen: Fix up some assertions

Reviewed-by: shade, wkemper

-------------

PR: https://git.openjdk.org/shenandoah/pull/478

From wkemper at openjdk.org  Wed Aug 21 23:40:30 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 21 Aug 2024 23:40:30 GMT
Subject: RFR: 8338779: GenShen: Prefer log_develop_debug in performance
 critical code
Message-ID: <PrQSWao-tEN5Dmimm3aUVghkHit9ndH_dxpi61sNg1U=.a057e939-049c-4f78-af8b-c4ea773c841e@github.com>

There are a couple of places where the log level check is proportional to the number of oops being processed.

-------------

Commit messages:
 - Fix whitespace
 - Use log_develop_debug in high traffic areas

Changes: https://git.openjdk.org/shenandoah/pull/481/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=481&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338779
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/shenandoah/pull/481.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/481/head:pull/481

PR: https://git.openjdk.org/shenandoah/pull/481

From ysr at openjdk.org  Thu Aug 22 01:25:22 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Aug 2024 01:25:22 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v6]
In-Reply-To: <Hja5VQt1BSoAT0rL0gWnrGaQIuTHLzeqi0iPZpQNyxw=.4d22419a-e518-4d4f-acc6-7cccad56a5ae@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <Hja5VQt1BSoAT0rL0gWnrGaQIuTHLzeqi0iPZpQNyxw=.4d22419a-e518-4d4f-acc6-7cccad56a5ae@github.com>
Message-ID: <DfejswZBD_6tgYMaU5ipSWvxQPkI7FJAb_--uJxta_I=.eaf736a7-785f-412f-9714-3056fb11cbbe@github.com>

On Wed, 21 Aug 2024 23:13:27 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
>> 2. Remove unhelpful comment from shenandoahFullGC.cpp
>> 3. Extraneous white space
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another array parameter declaration

LGTM

-------------

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/475#pullrequestreview-2252638572

From ysr at openjdk.org  Thu Aug 22 01:27:23 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Aug 2024 01:27:23 GMT
Subject: RFR: 8338779: GenShen: Prefer log_develop_debug in performance
 critical code
In-Reply-To: <PrQSWao-tEN5Dmimm3aUVghkHit9ndH_dxpi61sNg1U=.a057e939-049c-4f78-af8b-c4ea773c841e@github.com>
References: <PrQSWao-tEN5Dmimm3aUVghkHit9ndH_dxpi61sNg1U=.a057e939-049c-4f78-af8b-c4ea773c841e@github.com>
Message-ID: <NLpYZQEdfprrZrm62dADgA3-Ux9KVVXnS6SLbt8x8ns=.58afbb13-e0f7-4acf-ad38-30d8cf85b9d0@github.com>

On Wed, 21 Aug 2024 23:35:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are a couple of places where the log level check is proportional to the number of oops being processed.

LGTM ?

-------------

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/481#pullrequestreview-2252646435

From shade at openjdk.org  Thu Aug 22 11:07:22 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Aug 2024 11:07:22 GMT
Subject: RFR: 8338779: GenShen: Prefer log_develop_debug in performance
 critical code
In-Reply-To: <PrQSWao-tEN5Dmimm3aUVghkHit9ndH_dxpi61sNg1U=.a057e939-049c-4f78-af8b-c4ea773c841e@github.com>
References: <PrQSWao-tEN5Dmimm3aUVghkHit9ndH_dxpi61sNg1U=.a057e939-049c-4f78-af8b-c4ea773c841e@github.com>
Message-ID: <ZCfj35VUqtvl9sQ8Kt80G23ndI4UQFbTfw5vF2lMVhc=.3868bfa3-0d8d-4f2a-a31a-24c759b8720a@github.com>

On Wed, 21 Aug 2024 23:35:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are a couple of places where the log level check is proportional to the number of oops being processed.

Marked as reviewed by shade (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/481#pullrequestreview-2254210940

From shade at openjdk.org  Thu Aug 22 11:42:08 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Aug 2024 11:42:08 GMT
Subject: RFR: 8338662: Shenandoah: Remove excessive
 ShenandoahVerifier::verify_during_evacuation
In-Reply-To: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>
References: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>
Message-ID: <McTR2R_xsJ-dSd5rlOatcZKaVeTri5ntawLnsCiscWQ=.1da76f06-6a60-4672-9f0f-ea5402e3be70@github.com>

On Tue, 20 Aug 2024 10:22:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `ShenandoahVerifier::verify_during_evacuation` is a relaxed version of `ShenandoahVerifier::verify_before_evacuation`. In current code, "during" verification is called shortly after "before" check, which really gains us nothing checking-wise, and only really wastes verification time. This is the only "during" verification check we have, all other checks verify things before/after the phases. It makes sense to remove "during evac" verification check for extra debug performance and cleanliness. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20641#issuecomment-2304454798

From shade at openjdk.org  Thu Aug 22 11:42:08 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 22 Aug 2024 11:42:08 GMT
Subject: Integrated: 8338662: Shenandoah: Remove excessive
 ShenandoahVerifier::verify_during_evacuation
In-Reply-To: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>
References: <zOS5XQy-k-knB3nms4kNGGR-qXlFR2sCSGwWEHBac5A=.c20e0d7d-00ef-4760-99b6-8f1dab789b47@github.com>
Message-ID: <Sx5HmZ3okzWW7RWticyIZ6SjuHrAmLJzd8AJqHYu5k8=.a151cba6-796c-4eb2-9a9a-45993cae8399@github.com>

On Tue, 20 Aug 2024 10:22:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> `ShenandoahVerifier::verify_during_evacuation` is a relaxed version of `ShenandoahVerifier::verify_before_evacuation`. In current code, "during" verification is called shortly after "before" check, which really gains us nothing checking-wise, and only really wastes verification time. This is the only "during" verification check we have, all other checks verify things before/after the phases. It makes sense to remove "during evac" verification check for extra debug performance and cleanliness. 
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `all` with `-XX:+UseShenandoahGC -XX:+ShenandoahVerify`

This pull request has now been integrated.

Changeset: 6cf7f9c4
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6cf7f9c4a76b99ed7aa4dc7ee54692331fc73408
Stats:     39 lines in 4 files changed: 4 ins; 34 del; 1 mod

8338662: Shenandoah: Remove excessive ShenandoahVerifier::verify_during_evacuation

Reviewed-by: wkemper, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/20641

From wkemper at openjdk.org  Thu Aug 22 14:26:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 14:26:38 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <kz8_XWE4N4RBaIyaAq_qFvYWZpImK7L3v6HlNtzAIr0=.39a500de-4eb3-4fd5-8811-3f1c25ed1ef1@github.com>

Merges tag jdk-21.0.5+4

-------------

Commit messages:
 - 8331572: Allow using OopMapCache outside of STW GC phases
 - 8330520: linux clang build fails in os_linux.cpp with static_assert with no message is a C++17 extension
 - 8310683: Refactor StandardCharset/standard.java to use JUnit
 - 8317738: CodeCacheFullCountTest failed with "VirtualMachineError: Out of space in CodeCache for method handle intrinsic"
 - 8325022: Incorrect error message on client authentication
 - 8331153: JFR: Improve logging of jdk/jfr/api/consumer/filestream/TestOrdered.java
 - 8321206: Make Locale related system properties `StaticProperty`
 - 8303920: Avoid calling out to python in DataDescriptorSignatureMissing test
 - 8319817: Charset constructor should make defensive copy of aliases
 - 8073061: (fs) Files.copy(foo, bar, REPLACE_EXISTING) deletes bar even if foo is not readable
 - ... and 7 more: https://git.openjdk.org/shenandoah-jdk21u/compare/75c82f63...ed77abd4

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/74/files
  Stats: 2781 lines in 68 files changed: 2196 ins; 155 del; 430 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/74.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/74/head:pull/74

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/74

From wkemper at openjdk.org  Thu Aug 22 14:40:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 14:40:26 GMT
Subject: RFR: 8338535: GenShen: some style improvements to source code
 implementation [v6]
In-Reply-To: <Hja5VQt1BSoAT0rL0gWnrGaQIuTHLzeqi0iPZpQNyxw=.4d22419a-e518-4d4f-acc6-7cccad56a5ae@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
 <Hja5VQt1BSoAT0rL0gWnrGaQIuTHLzeqi0iPZpQNyxw=.4d22419a-e518-4d4f-acc6-7cccad56a5ae@github.com>
Message-ID: <rxu9z3m7ID_VsxvBmDI-I1OHJFqJuOHYXoJnhcpUn0Y=.9f459545-7a3c-438b-97b9-e8b4a8696c55@github.com>

On Wed, 21 Aug 2024 23:13:27 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
>> 2. Remove unhelpful comment from shenandoahFullGC.cpp
>> 3. Extraneous white space
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another array parameter declaration

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/475#pullrequestreview-2254720192

From wkemper at openjdk.org  Thu Aug 22 14:40:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 14:40:26 GMT
Subject: Integrated: 8338779: GenShen: Prefer log_develop_debug in performance
 critical code
In-Reply-To: <PrQSWao-tEN5Dmimm3aUVghkHit9ndH_dxpi61sNg1U=.a057e939-049c-4f78-af8b-c4ea773c841e@github.com>
References: <PrQSWao-tEN5Dmimm3aUVghkHit9ndH_dxpi61sNg1U=.a057e939-049c-4f78-af8b-c4ea773c841e@github.com>
Message-ID: <Mijhf1mrnSOPDFnipGWZ4Y6lHNiYRVmANrcyb2uGisE=.06bfe55a-d836-4c42-97da-4141dc226995@github.com>

On Wed, 21 Aug 2024 23:35:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are a couple of places where the log level check is proportional to the number of oops being processed.

This pull request has now been integrated.

Changeset: d2ed6519
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/d2ed6519cace41354bbcd073b46a00c9055f6060
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8338779: GenShen: Prefer log_develop_debug in performance critical code

Reviewed-by: ysr, shade

-------------

PR: https://git.openjdk.org/shenandoah/pull/481

From rkennke at openjdk.org  Thu Aug 22 14:53:47 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 14:53:47 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental)
Message-ID: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>

This is the main body of the JEP 450: Compact Object Headers (Experimental).

It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.

Main changes:
 - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
 - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
 - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
 - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
 - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
 - Arrays will now store their length at offset 8.
 - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archives are generated, next to the _nocoops variant.
 - Note that oopDesc::klass_offset_in_bytes() is not used by +UCOH paths anymore. The only exception is C2, which uses it as a placeholder/identifier of the special memory slice that only LoadNKlass uses. The backend then extracts the original oop and loads its mark-word and extracts the narrow-Klass* from that. I played with other approaches to implement LoadNKlass. Expanding it as a macro did not easily work, because C2 is missing a way to cast a word-sized integral to a narrow-Klass* (or at least I could not find it), and also I fear that doing so could mess with optimizations. This may be useful to revisit. OTOH, the approach that I have taken works and is similar to DecodeNKlass and similar instructions.

Testing:
 (+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests.)
The below testing has been run many times, but not with this exact base version of the JDK. I want to hold off the full testing until we also have the Tiny Class-Pointers PR lined-up, and test with that.

 - [x] tier1 (x86_64)
 - [ ] tier2 (x86_64)
 - [ ] tier3 (x86_64)
 - [ ] tier4 (x86_64)
 - [x] tier1 (aarch64)
 - [ ] tier2 (aarch64)
 - [ ] tier3 (aarch64)
 - [ ] tier4 (aarch64)
 - [x] tier1 (x86_64) +UseCompactObjectHeaders
 - [ ] tier2 (x86_64) +UseCompactObjectHeaders
 - [ ] tier3 (x86_64) +UseCompactObjectHeaders
 - [ ] tier4 (x86_64) +UseCompactObjectHeaders
 - [x] tier1 (aarch64) +UseCompactObjectHeaders
 - [ ] tier2 (aarch64) +UseCompactObjectHeaders
 - [ ] tier3 (aarch64) +UseCompactObjectHeaders
 - [ ] tier4 (aarch64) +UseCompactObjectHeaders
 - [x] Running as a backport in production since >1 year.

-------------

Commit messages:
 - 8305895: Implement JEP 450: Compact Object Headers (Experimental)

Changes: https://git.openjdk.org/jdk/pull/20677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305895
  Stats: 4526 lines in 187 files changed: 3238 ins; 671 del; 617 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From rkennke at openjdk.org  Thu Aug 22 15:00:09 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 15:00:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v2]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <dfwWs-WA77sOPzUwJw_9Zaa40qpzGO5BI70_YmyqD2g=.d3346941-4f23-47ee-b599-b0c90703ca2f@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Add missing newline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/ed032173..18e08c1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From kdnilsen at openjdk.org  Thu Aug 22 15:14:28 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 22 Aug 2024 15:14:28 GMT
Subject: Integrated: 8338535: GenShen: some style improvements to source code
 implementation
In-Reply-To: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
References: <BeNp7o5eUvo0Ew_0Yk_Q4W7UE2UYf22muZMObCJvctg=.de6d13e3-9203-45e0-9acd-633878729ac6@github.com>
Message-ID: <w-cAE7OsyhIdOCNUZZQhiL3jr547tYf1DW1XhWB1RCk=.80e3b449-1989-4579-a806-2a63fa06d1c6@github.com>

On Mon, 19 Aug 2024 21:03:46 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> 1. Hide union data structure behind accessor methods for ShenandoahHeuristics::RegionData._u
> 2. Remove unhelpful comment from shenandoahFullGC.cpp
> 3. Extraneous white space

This pull request has now been integrated.

Changeset: 07c540d9
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/07c540d96592c150ba99ec8c08d4dbcb85f0c7e0
Stats:     112 lines in 16 files changed: 66 ins; 10 del; 36 mod

8338535: GenShen: some style improvements to source code implementation

Reviewed-by: wkemper, ysr

-------------

PR: https://git.openjdk.org/shenandoah/pull/475

From rkennke at openjdk.org  Thu Aug 22 16:23:48 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 16:23:48 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Remove hashcode leftovers from SA

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/18e08c1e..1578ffae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From wkemper at openjdk.org  Thu Aug 22 16:32:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 16:32:17 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <kz8_XWE4N4RBaIyaAq_qFvYWZpImK7L3v6HlNtzAIr0=.39a500de-4eb3-4fd5-8811-3f1c25ed1ef1@github.com>
References: <kz8_XWE4N4RBaIyaAq_qFvYWZpImK7L3v6HlNtzAIr0=.39a500de-4eb3-4fd5-8811-3f1c25ed1ef1@github.com>
Message-ID: <E7sXROcWLBYwm1gWCHYgyVTaClnimvB2thHuggakxt8=.9b587e86-ec39-4c76-9284-17d1d2e9fb18@github.com>

> Merges tag jdk-21.0.5+4

William Kemper 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/shenandoah-jdk21u/pull/74/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/74/files/ed77abd4..ed77abd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=74&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=74&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/74.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/74/head:pull/74

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/74

From wkemper at openjdk.org  Thu Aug 22 16:32:20 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 16:32:20 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <kz8_XWE4N4RBaIyaAq_qFvYWZpImK7L3v6HlNtzAIr0=.39a500de-4eb3-4fd5-8811-3f1c25ed1ef1@github.com>
References: <kz8_XWE4N4RBaIyaAq_qFvYWZpImK7L3v6HlNtzAIr0=.39a500de-4eb3-4fd5-8811-3f1c25ed1ef1@github.com>
Message-ID: <jGzeZZRdNXKyKP4Omzho7f5htQAnZVyW-gLT-bSpPdA=.c926a5de-154b-4267-85c3-0c023fa1e89a@github.com>

On Thu, 22 Aug 2024 14:21:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.5+4

This pull request has now been integrated.

Changeset: d2bfbc4e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/d2bfbc4ef3752de80bd4d37a726fad0603ef228e
Stats:     2781 lines in 68 files changed: 2196 ins; 155 del; 430 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/74

From wkemper at openjdk.org  Thu Aug 22 16:45:58 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 16:45:58 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>

Merges tag jdk-24+12

-------------

Commit messages:
 - 8334357: Use NonInterleavingLogStream for report_metadata_oome
 - 8333265: De-duplicate method references in java.util.stream.FindOps
 - 8338146: Improve Exchanger performance with VirtualThreads
 - 8338688: Shenandoah: Avoid calling java_lang_Class accessors in asserts/verifier
 - 8338677: Improve startup of memory access var handles by simplifying combinator chains
 - 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor
 - 8338490: Serial: Move Generation::print_on to subclasses
 - 8338545: Functional interface implementations for common pre-boot ClassFile operations
 - 8338595: Add more linesize for MIME decoder in macro bench test Base64Decode
 - 8338539: New Object to ObjectMonitor mapping: riscv64 implementation
 - ... and 56 more: https://git.openjdk.org/shenandoah/compare/4c344335...1d05989b

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah/pull/483/files
  Stats: 13957 lines in 365 files changed: 8678 ins; 3321 del; 1958 mod
  Patch: https://git.openjdk.org/shenandoah/pull/483.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/483/head:pull/483

PR: https://git.openjdk.org/shenandoah/pull/483

From ysr at openjdk.org  Thu Aug 22 17:26:38 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Aug 2024 17:26:38 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments
Message-ID: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>

In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various comments. This ticket gathers together several of those changes.

**Testing:**
- [x] GHA
- [x] SPECjbb w/GenShen
- [x] jtreg:tier1
- [ ] Codepipeline testing

-------------

Commit messages:
 - Merge branch 'master' into review_changes_2
 - JDK-8338780 GenShen: Fix up some comments

Changes: https://git.openjdk.org/shenandoah/pull/484/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=484&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338780
  Stats: 87 lines in 3 files changed: 35 ins; 45 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah/pull/484.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/484/head:pull/484

PR: https://git.openjdk.org/shenandoah/pull/484

From ysr at openjdk.org  Thu Aug 22 17:32:23 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Aug 2024 17:32:23 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments
In-Reply-To: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
Message-ID: <kFhQsM8mY03k37pXIW01jMbqmGddjJQ-QrP4OuCZ70A=.f3905cfd-c5d2-4c83-ac55-c5b612baefe6@github.com>

On Thu, 22 Aug 2024 17:20:49 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various comments. This ticket gathers together several of those changes.
> 
> **Testing:**
> - [x] GHA
> - [x] SPECjbb w/GenShen
> - [x] jtreg:tier1
> - [ ] Codepipeline testing

src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 115:

> 113:     ShenandoahHeapRegion* r = data[idx].get_region();
> 114:     if (cset->is_preselected(r->index())) {
> 115:       assert(false, "There should be no preselected regions during GLOBAL GC");

If this is a true invariant (which it is in testing to date), then it must be the case that the call at line 55 above to `add_preselected_regions_to_collection_set()` doesn't do anything, and indeed returns `0` into `cur_young_garbage` there.

Clearly, I am missing something here. @kdnilsen ?

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/484#discussion_r1727547920

From ysr at openjdk.org  Thu Aug 22 17:44:18 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Aug 2024 17:44:18 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments
In-Reply-To: <kFhQsM8mY03k37pXIW01jMbqmGddjJQ-QrP4OuCZ70A=.f3905cfd-c5d2-4c83-ac55-c5b612baefe6@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
 <kFhQsM8mY03k37pXIW01jMbqmGddjJQ-QrP4OuCZ70A=.f3905cfd-c5d2-4c83-ac55-c5b612baefe6@github.com>
Message-ID: <I8P4o64OEsHZzFiSOpYWmRYmZ-jHdjYSDm9ZWY3SXcE=.a864e118-a7a1-42fa-a573-3bc887f715fc@github.com>

On Thu, 22 Aug 2024 17:29:50 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various comments. This ticket gathers together several of those changes.
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] SPECjbb w/GenShen
>> - [x] jtreg:tier1
>> - [ ] Codepipeline testing
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 115:
> 
>> 113:     ShenandoahHeapRegion* r = data[idx].get_region();
>> 114:     if (cset->is_preselected(r->index())) {
>> 115:       assert(false, "There should be no preselected regions during GLOBAL GC");
> 
> If this is a true invariant (which it is in testing to date), then it must be the case that the call at line 55 above to `add_preselected_regions_to_collection_set()` doesn't do anything, and indeed returns `0` into `cur_young_garbage` there.
> 
> Clearly, I am missing something here. @kdnilsen ?

I'll run some testing with another assert at the code at line 55 to check my (mis)understanding.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/484#discussion_r1727562566

From rkennke at openjdk.org  Thu Aug 22 17:59:10 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 17:59:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v4]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <jzdcu_4W9ntyW1POE6uoXyLHD4Z1EcQtwIKiiuT98aM=.1ccc2769-fed3-4570-80a0-49d7b8d8ee2b@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix hash_mask_in_place in ClhsdbLongConstant test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/1578ffae..7009e147

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From kdnilsen at openjdk.org  Thu Aug 22 18:05:26 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 22 Aug 2024 18:05:26 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments
In-Reply-To: <I8P4o64OEsHZzFiSOpYWmRYmZ-jHdjYSDm9ZWY3SXcE=.a864e118-a7a1-42fa-a573-3bc887f715fc@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
 <kFhQsM8mY03k37pXIW01jMbqmGddjJQ-QrP4OuCZ70A=.f3905cfd-c5d2-4c83-ac55-c5b612baefe6@github.com>
 <I8P4o64OEsHZzFiSOpYWmRYmZ-jHdjYSDm9ZWY3SXcE=.a864e118-a7a1-42fa-a573-3bc887f715fc@github.com>
Message-ID: <bfhUE3j1T1i0VTW6l_oMBQDouG7mB1nsijsbwoZCUms=.20de1c98-88ce-4f09-8804-55389fa9a4e7@github.com>

On Thu, 22 Aug 2024 17:41:22 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 115:
>> 
>>> 113:     ShenandoahHeapRegion* r = data[idx].get_region();
>>> 114:     if (cset->is_preselected(r->index())) {
>>> 115:       assert(false, "There should be no preselected regions during GLOBAL GC");
>> 
>> If this is a true invariant (which it is in testing to date), then it must be the case that the call at line 55 above to `add_preselected_regions_to_collection_set()` doesn't do anything, and indeed returns `0` into `cur_young_garbage` there.
>> 
>> Clearly, I am missing something here. @kdnilsen ?
>
> I'll run some testing with another assert at the code at line 55 to check my (mis)understanding.

You are correct.  In ShenandoahGenerationalHeuristics::choose_collection_set(), we only call prime_collection_set() if generation->is_young().  For global collections, we will not prime the collection set, which means we will not preselect any regions for promotion.

Given this reality, we can remove the call to add_preselected_regions_to_collection_SET() from ShenandoahGlobalHeuristics::choose_collection_set_from_regiondata().  Keeping the assertion in place is how we know it was safe to remove the call to add preselected regions.

We could do some archeology on the code to remind ourselves how we got here.  But maybe not necessary.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/484#discussion_r1727594983

From rkennke at openjdk.org  Thu Aug 22 18:18:01 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 18:18:01 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix hash shift for 32 bit builds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/7009e147..5ffc582f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From kdnilsen at openjdk.org  Thu Aug 22 18:19:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 22 Aug 2024 18:19:35 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments
In-Reply-To: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
Message-ID: <z84tjKuwFicU8vcb8QZqNGbupj8uyamKmf3GzD4sAfA=.93b9b786-4149-4ed1-8dd8-63971d7095d4@github.com>

On Thu, 22 Aug 2024 17:20:49 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various comments. This ticket gathers together several of those changes.
> 
> **Testing:**
> - [x] GHA
> - [x] SPECjbb w/GenShen
> - [x] jtreg:tier1
> - [ ] Codepipeline testing

src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp line 46:

> 44:   // we do the same here, but with the following adjustments for generational mode:
> 45:   //
> 46:   // In generational mode, the sort order within the data array is not strictly descending amounts

Given discussion below, this comment is not true for Global collections.  Since global collection do not preselect aged regions.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/484#discussion_r1727609774

From kdnilsen at openjdk.org  Thu Aug 22 18:19:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 22 Aug 2024 18:19:35 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments
In-Reply-To: <bfhUE3j1T1i0VTW6l_oMBQDouG7mB1nsijsbwoZCUms=.20de1c98-88ce-4f09-8804-55389fa9a4e7@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
 <kFhQsM8mY03k37pXIW01jMbqmGddjJQ-QrP4OuCZ70A=.f3905cfd-c5d2-4c83-ac55-c5b612baefe6@github.com>
 <I8P4o64OEsHZzFiSOpYWmRYmZ-jHdjYSDm9ZWY3SXcE=.a864e118-a7a1-42fa-a573-3bc887f715fc@github.com>
 <bfhUE3j1T1i0VTW6l_oMBQDouG7mB1nsijsbwoZCUms=.20de1c98-88ce-4f09-8804-55389fa9a4e7@github.com>
Message-ID: <XlZ_N8jGIJDyjDAy9RpxQtcsy3OW6XL_B6ek3JjqZQc=.3e53b2c1-b72e-49a0-8405-19e12fdec18e@github.com>

On Thu, 22 Aug 2024 18:02:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> I'll run some testing with another assert at the code at line 55 to check my (mis)understanding.
>
> You are correct.  In ShenandoahGenerationalHeuristics::choose_collection_set(), we only call prime_collection_set() if generation->is_young().  For global collections, we will not prime the collection set, which means we will not preselect any regions for promotion.
> 
> Given this reality, we can remove the call to add_preselected_regions_to_collection_SET() from ShenandoahGlobalHeuristics::choose_collection_set_from_regiondata().  Keeping the assertion in place is how we know it was safe to remove the call to add preselected regions.
> 
> We could do some archeology on the code to remind ourselves how we got here.  But maybe not necessary.

Could lines 114-118 be replaced with: assert(!cset->is_preselected(r->index(), comment)

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/484#discussion_r1727611561

From wkemper at openjdk.org  Thu Aug 22 18:54:49 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 18:54:49 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
Message-ID: <QdLUno_HUyQbb5q-lm-50NZPLI-V4N04Edwn2o3n6DQ=.3a09a119-d570-4b3e-b3b9-884d25d5e10a@github.com>

> Merges tag jdk-24+12

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:

 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-24+12
 - 8334357: Use NonInterleavingLogStream for report_metadata_oome
   
   Reviewed-by: jsjolen, stuefe
 - 8333265: De-duplicate method references in java.util.stream.FindOps
   
   Reviewed-by: liach
 - 8338146: Improve Exchanger performance with VirtualThreads
   
   Reviewed-by: alanb
 - 8338688: Shenandoah: Avoid calling java_lang_Class accessors in asserts/verifier
   
   Reviewed-by: rkennke, wkemper
 - 8338677: Improve startup of memory access var handles by simplifying combinator chains
   
   Reviewed-by: redestad
 - 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor
   
   Reviewed-by: redestad, liach
 - 8338490: Serial: Move Generation::print_on to subclasses
   
   Reviewed-by: gli
 - 8338545: Functional interface implementations for common pre-boot ClassFile operations
   
   Reviewed-by: asotona
 - 8338595: Add more linesize for MIME decoder in macro bench test Base64Decode
   
   Reviewed-by: rehn
 - ... and 57 more: https://git.openjdk.org/shenandoah/compare/07c540d9...19d9c58d

-------------

Changes: https://git.openjdk.org/shenandoah/pull/483/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=01
  Stats: 14059 lines in 366 files changed: 8688 ins; 3415 del; 1956 mod
  Patch: https://git.openjdk.org/shenandoah/pull/483.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/483/head:pull/483

PR: https://git.openjdk.org/shenandoah/pull/483

From wkemper at openjdk.org  Thu Aug 22 19:04:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 19:04:32 GMT
Subject: RFR: 8338763: GenShen: Global GC should not swap remembered sets for
 the verifier
Message-ID: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>

It seems that subsequent improvements to remembered set verification have made this change unnecessary.

## Testing
GHA, internal pipelines and local dacapo runs

-------------

Commit messages:
 - Remove vestigial comment
 - Do not swap remembered set for global collections

Changes: https://git.openjdk.org/shenandoah/pull/485/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=485&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338763
  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah/pull/485.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/485/head:pull/485

PR: https://git.openjdk.org/shenandoah/pull/485

From kdnilsen at openjdk.org  Thu Aug 22 19:04:32 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 22 Aug 2024 19:04:32 GMT
Subject: RFR: 8338763: GenShen: Global GC should not swap remembered sets
 for the verifier
In-Reply-To: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
References: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
Message-ID: <55IRcOFALCIZpcgMkm3nbezg-u0FF6DuG0EsGdka924=.68c97041-3627-47b9-aeca-3857710f83fd@github.com>

On Thu, 22 Aug 2024 18:57:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> It seems that subsequent improvements to remembered set verification have made this change unnecessary.
> 
> ## Testing
> GHA, internal pipelines and local dacapo runs

Marked as reviewed by kdnilsen (Committer).

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 601:

> 599: 
> 600:   if (heap->mode()->is_generational()) {
> 601:     if (_generation->is_young()) {

My recollection is that ShenandoahVerify (at least one time) would verify the remembered set even for a global GC.  So that's why we needed to do this, to make the verifier happy.  Has this changed?

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/485#pullrequestreview-2255432432
PR Review Comment: https://git.openjdk.org/shenandoah/pull/485#discussion_r1727666595

From kdnilsen at openjdk.org  Thu Aug 22 19:04:32 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 22 Aug 2024 19:04:32 GMT
Subject: RFR: 8338763: GenShen: Global GC should not swap remembered sets
 for the verifier
In-Reply-To: <55IRcOFALCIZpcgMkm3nbezg-u0FF6DuG0EsGdka924=.68c97041-3627-47b9-aeca-3857710f83fd@github.com>
References: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
 <55IRcOFALCIZpcgMkm3nbezg-u0FF6DuG0EsGdka924=.68c97041-3627-47b9-aeca-3857710f83fd@github.com>
Message-ID: <6wmvbKP4p-KIZz2uDgp2Nff9ra4WkTPugRFIdOs9ekY=.9245dced-3a90-436a-8c9c-5f8e8cf9a723@github.com>

On Thu, 22 Aug 2024 19:00:26 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> It seems that subsequent improvements to remembered set verification have made this change unnecessary.
>> 
>> ## Testing
>> GHA, internal pipelines and local dacapo runs
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 601:
> 
>> 599: 
>> 600:   if (heap->mode()->is_generational()) {
>> 601:     if (_generation->is_young()) {
> 
> My recollection is that ShenandoahVerify (at least one time) would verify the remembered set even for a global GC.  So that's why we needed to do this, to make the verifier happy.  Has this changed?

Your description of the PR says no longer necessary, so I guess that answers my question.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/485#discussion_r1727667378

From ihse at openjdk.org  Thu Aug 22 19:29:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 22 Aug 2024 19:29:03 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
Message-ID: <XLy_mB3TjLyOUGwNwrUGiyUtCHtOuVmCtZcFjuWvu8k=.ac3b111a-e665-49c5-994a-c52d8b06fddd@github.com>

On Thu, 22 Aug 2024 18:18:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix hash shift for 32 bit builds

Build changes look good. I have not looked at any other code.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2255474321

From rkennke at openjdk.org  Thu Aug 22 20:08:43 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 22 Aug 2024 20:08:43 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
Message-ID: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will now store their length at offset 8.
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv...

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix bit counts in GCForwarding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20677/files
  - new: https://git.openjdk.org/jdk/pull/20677/files/5ffc582f..eaec1117

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677

PR: https://git.openjdk.org/jdk/pull/20677

From ayang at openjdk.org  Thu Aug 22 20:16:07 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 22 Aug 2024 20:16:07 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
Message-ID: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>

On Thu, 22 Aug 2024 18:18:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix hash shift for 32 bit builds

src/hotspot/share/gc/shared/gcForwarding.cpp line 37:

> 35:   size_t max_narrow_heap_size = right_n_bits(NumLowBitsNarrow - Shift);
> 36:   if (UseCompactObjectHeaders && max_heap_size > max_narrow_heap_size * HeapWordSize) {
> 37:     FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);

Maybe a log-info/warning would be nice.

src/hotspot/share/gc/shared/gcForwarding.hpp line 36:

> 34:  * Implements forwarding for the full-GCs of Serial, Parallel, G1 and Shenandoah in
> 35:  * a way that preserves upper N bits of object mark-words, which contain crucial
> 36:  * Klass* information when running with compact headers. The encoding is similar to

This doc suggests this forwarding is only for compact-header so I wonder if we can check `UseCompactObjectHeaders` directly instead of heap-size in `GCForwarding::initialize`.

src/hotspot/share/gc/shared/gcForwarding.hpp line 40:

> 38:  * heap-base, shifts that difference into the right place, and sets the lowest two
> 39:  * bits (to indicate 'forwarded' state as usual).
> 40:  */

> "can use 40 bits for forwardee encoding. That's enough for 8TB of heap."

I feel this 8T-constraint is significant and should be in the doc.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727708193
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727727638
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727732496

From ayang at openjdk.org  Thu Aug 22 20:16:05 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 22 Aug 2024 20:16:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
Message-ID: <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>

On Thu, 22 Aug 2024 16:23:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove hashcode leftovers from SA

src/hotspot/share/gc/parallel/mutableSpace.cpp line 232:

> 230:         p += obj->forwardee()->size();
> 231:       } else {
> 232:         p += obj->size();

I feel it's more correct to go through the forwardee for forwarded objs even for the non-COMPACT_HEADERS case. (This method is meant to cover all objs, so should not be perf-critical.) IOW, the `false` case should just be dropped.

src/hotspot/share/gc/serial/defNewGeneration.cpp line 707:

> 705:       } else if (obj->is_forwarded()) {
> 706:         // To restore the klass-bits in the header.
> 707:         obj->forward_safe_init_mark();

I wonder if not modifying successful-forwarded objs is cleaner. Sth like:


reset_self_forwarded_in_space(space) {
  cur = space->bottom();
  top = space->top();

  while (cur < top) {
    obj = cast_to_oop(cur);

    if (obj->is_self_forwarded()) {
      obj->unset_self_forwarded();
      obj_size = obj->size();
    } else {
      assert(obj->is_forwarded(), "inv");
      obj_size = obj->forwardee()->size();
    }

    cur += obj_size;
  }
}

reset_self_forwarded_in_space(eden());
reset_self_forwarded_in_space(from());

src/hotspot/share/gc/serial/serialArguments.cpp line 33:

> 31: void SerialArguments::initialize_heap_flags_and_sizes() {
> 32:   GenArguments::initialize_heap_flags_and_sizes();
> 33:   GCForwarding::initialize_flags(MaxNewSize + MaxOldSize);

Can one use `MaxHeapSize` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727547638
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727524479
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1727548413

From ysr at openjdk.org  Thu Aug 22 20:57:42 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Aug 2024 20:57:42 GMT
Subject: RFR: 8338763: GenShen: Global GC should not swap remembered sets
 for the verifier
In-Reply-To: <6wmvbKP4p-KIZz2uDgp2Nff9ra4WkTPugRFIdOs9ekY=.9245dced-3a90-436a-8c9c-5f8e8cf9a723@github.com>
References: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
 <55IRcOFALCIZpcgMkm3nbezg-u0FF6DuG0EsGdka924=.68c97041-3627-47b9-aeca-3857710f83fd@github.com>
 <6wmvbKP4p-KIZz2uDgp2Nff9ra4WkTPugRFIdOs9ekY=.9245dced-3a90-436a-8c9c-5f8e8cf9a723@github.com>
Message-ID: <AhyLo-lIGSXKZzY-Qg2Ancsc8SkIBSIzrq97UJAFgaY=.0e0b8dd2-6596-40de-9309-2d92f2b3d543@github.com>

On Thu, 22 Aug 2024 19:01:11 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 601:
>> 
>>> 599: 
>>> 600:   if (heap->mode()->is_generational()) {
>>> 601:     if (_generation->is_young()) {
>> 
>> My recollection is that ShenandoahVerify (at least one time) would verify the remembered set even for a global GC.  So that's why we needed to do this, to make the verifier happy.  Has this changed?
>
> Your description of the PR says no longer necessary, so I guess that answers my question.

Can you check if there's a similar issue in `ShenandoahDegenGC::op_degenerated()` too?

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/485#discussion_r1727800196

From wkemper at openjdk.org  Thu Aug 22 21:29:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 21:29:33 GMT
Subject: RFR: 8338763: GenShen: Global GC should not swap remembered sets
 for the verifier [v2]
In-Reply-To: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
References: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
Message-ID: <xKTCAyOLAcCT_mfwj6RRsyHFcACR0naUpqga2Ft3RZU=.7a0de82d-08d6-4f4d-abd1-22fc0209ea13@github.com>

> It seems that subsequent improvements to remembered set verification have made this change unnecessary.
> 
> ## Testing
> GHA, internal pipelines and local dacapo runs

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Do not swap remembered set for global degenerated cycles either

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/485/files
  - new: https://git.openjdk.org/shenandoah/pull/485/files/d52cdcc6..e5d27d1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=485&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=485&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah/pull/485.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/485/head:pull/485

PR: https://git.openjdk.org/shenandoah/pull/485

From wkemper at openjdk.org  Thu Aug 22 21:29:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 22 Aug 2024 21:29:33 GMT
Subject: RFR: 8338763: GenShen: Global GC should not swap remembered sets
 for the verifier [v2]
In-Reply-To: <AhyLo-lIGSXKZzY-Qg2Ancsc8SkIBSIzrq97UJAFgaY=.0e0b8dd2-6596-40de-9309-2d92f2b3d543@github.com>
References: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
 <55IRcOFALCIZpcgMkm3nbezg-u0FF6DuG0EsGdka924=.68c97041-3627-47b9-aeca-3857710f83fd@github.com>
 <6wmvbKP4p-KIZz2uDgp2Nff9ra4WkTPugRFIdOs9ekY=.9245dced-3a90-436a-8c9c-5f8e8cf9a723@github.com>
 <AhyLo-lIGSXKZzY-Qg2Ancsc8SkIBSIzrq97UJAFgaY=.0e0b8dd2-6596-40de-9309-2d92f2b3d543@github.com>
Message-ID: <oJRXrsbeBdcGU9c41sceB5l2usMH4PrTcJElqoTLLl0=.4a6c513d-0379-4762-8fa8-8f27e706e5b7@github.com>

On Thu, 22 Aug 2024 20:54:22 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Your description of the PR says no longer necessary, so I guess that answers my question.
>
> Can you check if there's a similar issue in `ShenandoahDegenGC::op_degenerated()` too?

Good catch @ysramakrishna . Updated PR and will wait for tests to complete.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/485#discussion_r1727888149

From ysr at openjdk.org  Thu Aug 22 22:26:23 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 22 Aug 2024 22:26:23 GMT
Subject: RFR: 8338763: GenShen: Global GC should not swap remembered sets
 for the verifier [v2]
In-Reply-To: <xKTCAyOLAcCT_mfwj6RRsyHFcACR0naUpqga2Ft3RZU=.7a0de82d-08d6-4f4d-abd1-22fc0209ea13@github.com>
References: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
 <xKTCAyOLAcCT_mfwj6RRsyHFcACR0naUpqga2Ft3RZU=.7a0de82d-08d6-4f4d-abd1-22fc0209ea13@github.com>
Message-ID: <hIVbnVR3yI7Mvvnqz3H5SzRvdpFDsg1V8ULMts_1SlQ=.e4af166c-d443-4286-a319-6bce9830d178@github.com>

On Thu, 22 Aug 2024 21:29:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> It seems that subsequent improvements to remembered set verification have made this change unnecessary.
>> 
>> ## Testing
>> GHA, internal pipelines and local dacapo runs
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not swap remembered set for global degenerated cycles either

Yes, it looks like the verification closure makes a distinction between when it's called and checks the appropriate version of the card table.

But the code is a bit subtle, and might benefit with a documentation note to this effect in the closure where one or the other version of the card table is used for the checks.


inline void work(T* p) {
    T o = RawAccess<>::oop_load(p);
    if (!CompressedOops::is_null(o)) {
      oop obj = CompressedOops::decode_not_null(o);
      if (_heap->is_in_young(obj)) {
        size_t card_index = _scanner->card_index_for_addr((HeapWord*) p);
        if (_init_mark && !_scanner->is_card_dirty(card_index)) {
          ShenandoahAsserts::print_failure(ShenandoahAsserts::_safe_all, obj, p, nullptr,
                                           "Verify init-mark remembered set violation", "clean card should be dirty", __FILE__, __LINE__);
        } else if (!_init_mark && !_scanner->is_write_card_dirty(card_index)) {
          ShenandoahAsserts::print_failure(ShenandoahAsserts::_safe_all, obj, p, nullptr,
                                           "Verify init-update-refs remembered set violation", "clean card should be dirty", __FILE__, __LINE__);
        }
      }
    }
  }

-------------

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/485#pullrequestreview-2255906122

From mdoerr at openjdk.org  Fri Aug 23 10:02:34 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 23 Aug 2024 10:02:34 GMT
Subject: RFR: 8338814: [PPC64] Unify interface of cmpxchg for different types
Message-ID: <N8lAGfvFmvDXgG0CC7wXjhaAPXNvYdjuI9o5csgsJzo=.5bba3822-a256-401a-b3b7-891eab0cdf05@github.com>

PPC64 code has very complicated cmpxchg functions in MacroAssembler. We should have at least a unified argument list for the different types and the features should be usable with all types.
I have also cleaned up the `RegisterOrConstant` functions because they are used by the cmpxchg code.

One difference in the argument list still exists: `cmpxchgb` and `cmpxchgh` use extra temp registers to support older processors. They should get removed with [JDK-8331859](https://bugs.openjdk.org/browse/JDK-8331859).

-------------

Commit messages:
 - 8338814: [PPC64] Unify interface of cmpxchg for different types

Changes: https://git.openjdk.org/jdk/pull/20689/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20689&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338814
  Stats: 123 lines in 9 files changed: 38 ins; 3 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/20689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20689/head:pull/20689

PR: https://git.openjdk.org/jdk/pull/20689

From stefank at openjdk.org  Fri Aug 23 10:56:05 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 23 Aug 2024 10:56:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <MZnkyvL6XoHEuPO0DtoekBz4QH_I5uisKXGwCOFGcA4=.53525e3d-54aa-4298-be5d-9b70cb483f8b@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

I've looked through the changes to the gc/ directory and have a couple of proposal changes. Please have a look:
https://github.com/openjdk/jdk/compare/pr/20677...stefank:jdk:lilliput_review_gc_1

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2306834883

From wkemper at openjdk.org  Fri Aug 23 14:17:31 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 23 Aug 2024 14:17:31 GMT
Subject: RFR: Merge openjdk/jdk:master [v3]
In-Reply-To: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
Message-ID: <9qDTCnbETN18MEQsCuvajnW8JPqv7kSsAXj2qvCA830=.e0e113b2-3d62-4dae-addd-d54633101136@github.com>

> Merges tag jdk-24+12

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits:

 - 8334357: Use NonInterleavingLogStream for report_metadata_oome
   
   Reviewed-by: jsjolen, stuefe
 - 8333265: De-duplicate method references in java.util.stream.FindOps
   
   Reviewed-by: liach
 - 8338146: Improve Exchanger performance with VirtualThreads
   
   Reviewed-by: alanb
 - 8338688: Shenandoah: Avoid calling java_lang_Class accessors in asserts/verifier
   
   Reviewed-by: rkennke, wkemper
 - 8338677: Improve startup of memory access var handles by simplifying combinator chains
   
   Reviewed-by: redestad
 - 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor
   
   Reviewed-by: redestad, liach
 - 8338490: Serial: Move Generation::print_on to subclasses
   
   Reviewed-by: gli
 - 8338545: Functional interface implementations for common pre-boot ClassFile operations
   
   Reviewed-by: asotona
 - 8338595: Add more linesize for MIME decoder in macro bench test Base64Decode
   
   Reviewed-by: rehn
 - 8338539: New Object to ObjectMonitor mapping: riscv64 implementation
   
   Reviewed-by: fyang, rehn, mli
 - ... and 56 more: https://git.openjdk.org/shenandoah/compare/4c344335...1d05989b

-------------

Changes: https://git.openjdk.org/shenandoah/pull/483/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=02
  Stats: 13957 lines in 365 files changed: 8678 ins; 3321 del; 1958 mod
  Patch: https://git.openjdk.org/shenandoah/pull/483.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/483/head:pull/483

PR: https://git.openjdk.org/shenandoah/pull/483

From lmesnik at openjdk.org  Fri Aug 23 16:37:05 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 23 Aug 2024 16:37:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <JEzJGLkDHhgNGFns5-xLFV1TGH2-EkzWd568IcAO1Rg=.b48dc38e-57a9-4e4f-b512-fc86efdb77c4@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

Changes requested by lmesnik (Reviewer).

make/Images.gmk line 135:

> 133: #
> 134: # Param1 - VM variant (e.g., server, client, zero, ...)
> 135: # Param2 - _nocoops, _coh, _nocoops_coh, or empty

The -XX:+UseCompactObjectHeaders ssems to incompatible withe zero vm. The zero vm build start failing while generating shared archive with +UseCompactObjectHeaders. Generation should be disabled by default for zero to don't break the build.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2257621775
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1729222671

From wkemper at openjdk.org  Fri Aug 23 17:11:58 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 23 Aug 2024 17:11:58 GMT
Subject: RFR: 8338881: GenShen: Use explicit third temp register for post
 barrier
Message-ID: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>

* Use register given as `tmp3` argument instead of "out of the blue" `r3`
* Simplify logic for post barrier call

## Testing
GHA, internal pipelines

-------------

Commit messages:
 - Simplify post barrier

Changes: https://git.openjdk.org/shenandoah/pull/486/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=486&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338881
  Stats: 19 lines in 1 file changed: 5 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/486.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/486/head:pull/486

PR: https://git.openjdk.org/shenandoah/pull/486

From wkemper at openjdk.org  Fri Aug 23 17:21:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 23 Aug 2024 17:21:26 GMT
Subject: Integrated: 8338763: GenShen: Global GC should not swap remembered
 sets for the verifier
In-Reply-To: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
References: <JnbIFoivACulpRM744NfsTAao2uXIar1_titHZw8-E4=.a73e298e-26bc-412a-8e67-548a6c74dd34@github.com>
Message-ID: <IxBroJLscagefNuABQoUJRDwe-9mEJMc3eCW1WHOBT0=.7ab733c0-d085-472e-b819-3b18216d5ca9@github.com>

On Thu, 22 Aug 2024 18:57:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> It seems that subsequent improvements to remembered set verification have made this change unnecessary.
> 
> ## Testing
> GHA, internal pipelines and local dacapo runs

This pull request has now been integrated.

Changeset: fc1acee6
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/fc1acee6474022d6e9d3c7c2ba2f94f9a5ec5ff0
Stats:     9 lines in 2 files changed: 0 ins; 5 del; 4 mod

8338763: GenShen: Global GC should not swap remembered sets for the verifier

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/shenandoah/pull/485

From shade at openjdk.org  Fri Aug 23 17:28:15 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 23 Aug 2024 17:28:15 GMT
Subject: RFR: 8338881: GenShen: Use explicit third temp register for post
 barrier
In-Reply-To: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>
References: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>
Message-ID: <cImj2MvbySO_HMSIJ05lS2H16GsC7ubHL8_it9OTdPM=.580e70a3-d307-482a-a251-11dbb925f6d3@github.com>

On Fri, 23 Aug 2024 17:06:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Use register given as `tmp3` argument instead of "out of the blue" `r3`
> * Simplify logic for post barrier call
> 
> ## Testing
> GHA, internal pipelines

OK, so comprehension check. The deleted "Barrier needs uncompressed oop for region cross check." thing is copied from G1, which needed "original" value oop for the post-barrier to work. The call to `BSA::store_at` would compress `val`, destroying it. This is irrelevant for Shenandoah code, because we only pass the "location" for card table update, not the actual "value" we store. So this "corruption" is irrelevant. Saves some moves then, nice.

src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 422:

> 420: 
> 421:   bool in_heap = (decorators & IN_HEAP) != 0;
> 422:   bool needs_post_barrier = val != noreg && in_heap && ShenandoahCardBarrier;

Consider `(val != noreg)`.

-------------

Marked as reviewed by shade (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/486#pullrequestreview-2257732779
PR Review Comment: https://git.openjdk.org/shenandoah/pull/486#discussion_r1729290600

From wkemper at openjdk.org  Fri Aug 23 18:11:56 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 23 Aug 2024 18:11:56 GMT
Subject: RFR: 8338881: GenShen: Use explicit third temp register for post
 barrier [v2]
In-Reply-To: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>
References: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>
Message-ID: <vQM6LK7RYpCFwWWJhqgLjJCDkhknoPVv0SzNxe2UIcU=.d3f2e468-ad1e-4eee-83d7-c80ba00e05d2@github.com>

> * Use register given as `tmp3` argument instead of "out of the blue" `r3`
> * Simplify logic for post barrier call
> 
> ## Testing
> GHA, internal pipelines

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Use parentheses for comparison operation

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/486/files
  - new: https://git.openjdk.org/shenandoah/pull/486/files/fa7dc0c4..b178e3b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=486&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=486&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/486.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/486/head:pull/486

PR: https://git.openjdk.org/shenandoah/pull/486

From wkemper at openjdk.org  Fri Aug 23 18:11:56 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 23 Aug 2024 18:11:56 GMT
Subject: RFR: 8338881: GenShen: Use explicit third temp register for post
 barrier
In-Reply-To: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>
References: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>
Message-ID: <dqX4-PH1ooNT6vy8GeBa6m7TsAnR7-h60clWpQ-Ik-c=.181fb595-f404-459c-8045-b5ef2287b4b0@github.com>

On Fri, 23 Aug 2024 17:06:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Use register given as `tmp3` argument instead of "out of the blue" `r3`
> * Simplify logic for post barrier call
> 
> ## Testing
> GHA, internal pipelines

Right, Shenandoah doesn't check that the destination for the store now holds a pointer that points into a different region before updating the card table.

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/486#issuecomment-2307572240

From wkemper at openjdk.org  Fri Aug 23 18:21:52 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 23 Aug 2024 18:21:52 GMT
Subject: RFR: Merge openjdk/jdk:master [v4]
In-Reply-To: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
Message-ID: <kjBhwZWQa7nDFDWps0dMx3_dcoJWOqtf5y8BUnlgnwY=.84025ed3-257b-41a6-afea-b82da5c31c0b@github.com>

> Merges tag jdk-24+12

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 68 commits:

 - Use  when sanity checking
 - Merge remote-tracking branch 'shenandoah/master' into merge-jdk-24+12
 - 8334357: Use NonInterleavingLogStream for report_metadata_oome
   
   Reviewed-by: jsjolen, stuefe
 - 8333265: De-duplicate method references in java.util.stream.FindOps
   
   Reviewed-by: liach
 - 8338146: Improve Exchanger performance with VirtualThreads
   
   Reviewed-by: alanb
 - 8338688: Shenandoah: Avoid calling java_lang_Class accessors in asserts/verifier
   
   Reviewed-by: rkennke, wkemper
 - 8338677: Improve startup of memory access var handles by simplifying combinator chains
   
   Reviewed-by: redestad
 - 8338532: Speed up the ClassFile API MethodTypeDesc#ofDescriptor
   
   Reviewed-by: redestad, liach
 - 8338490: Serial: Move Generation::print_on to subclasses
   
   Reviewed-by: gli
 - 8338545: Functional interface implementations for common pre-boot ClassFile operations
   
   Reviewed-by: asotona
 - ... and 58 more: https://git.openjdk.org/shenandoah/compare/07c540d9...67aabca1

-------------

Changes: https://git.openjdk.org/shenandoah/pull/483/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=03
  Stats: 14062 lines in 366 files changed: 8688 ins; 3415 del; 1959 mod
  Patch: https://git.openjdk.org/shenandoah/pull/483.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/483/head:pull/483

PR: https://git.openjdk.org/shenandoah/pull/483

From mli at openjdk.org  Fri Aug 23 18:49:05 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 23 Aug 2024 18:49:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp line 170:

> 168:   mv(tmp1, (int32_t)(intptr_t)markWord::prototype().value());
> 169:   sd(tmp1, Address(obj, oopDesc::mark_offset_in_bytes()));
> 170: // Todo UseCompactObjectHeaders

Can I ask, will this pr fullly support riscv?

src/hotspot/share/oops/oop.inline.hpp line 94:

> 92: 
> 93: void oopDesc::init_mark() {
> 94:   if (UseCompactObjectHeaders) {

Seems only `set_mark(prototype_mark());` is fine for both cases?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1729383247
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1728833750

From lmesnik at openjdk.org  Fri Aug 23 19:06:04 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 23 Aug 2024 19:06:04 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <roqs5Spc1UGAUaoLhyc7-hVGR0pNLPcofkdaT_6R7Pg=.fda59880-aac8-4ec3-bc26-286639a519bd@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 59:

> 57:     public static void main(String... args) throws Exception {
> 58:          String zGenerational = args[0];
> 59:          String compactHeaders = "-XX:" + (zGenerational.equals("-XX:+ZGenerational") ? "+" : "-") + "UseCompactObjectHeaders";

The test failing with
 stdout: [[0.176s][info][cds] trying to map /opt/mach5/mesos/work_dir/slaves/a20696e7-ae7d-4d37-8e9c-83f99ef002cb-S2261/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f0801999-993f-4e08-b017-08b33a8ec44f/runs/34cc555e-ae8f-4a48-8175-e998194f204b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_cds_relocation/scratch/5/appcds-18h50m16s773.jsa
[0.176s][info][cds] Opened archive /opt/mach5/mesos/work_dir/slaves/a20696e7-ae7d-4d37-8e9c-83f99ef002cb-S2261/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f0801999-993f-4e08-b017-08b33a8ec44f/runs/34cc555e-ae8f-4a48-8175-e998194f204b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_cds_relocation/scratch/5/appcds-18h50m16s773.jsa.
[0.176s][info][cds] Archive was created with UseCompressedOops = 0, UseCompressedClassPointers = 1
[0.176s][info][cds] The shared archive file's UseCompactObjectHeaders setting (enabled) does not equal the current UseCompactObjectHeaders setting (disabled).
[0.176s][info][cds] Initialize static archive failed.
[0.176s][info][cds] Unable to map shared spaces
[0.176s][error][cds] An error has occurred while processing the shared archive file.
[0.176s][error][cds] Unable to map shared spaces
Error occurred during initialization of VM
Unable to use shared archive.
];
 stderr: []
 exitValue = 1

java.lang.RuntimeException: 'Hello World' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:252)
	at TestZGCWithCDS.main(TestZGCWithCDS.java:123)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1729404477

From stuefe at openjdk.org  Mon Aug 26 08:06:09 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 26 Aug 2024 08:06:09 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <roqs5Spc1UGAUaoLhyc7-hVGR0pNLPcofkdaT_6R7Pg=.fda59880-aac8-4ec3-bc26-286639a519bd@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <roqs5Spc1UGAUaoLhyc7-hVGR0pNLPcofkdaT_6R7Pg=.fda59880-aac8-4ec3-bc26-286639a519bd@github.com>
Message-ID: <GLFs2h_prTbuRe_A3rKZRt3Yfb4AErMRaxyjH2fcdBE=.f3ab0807-3dec-4ae1-b042-7181bba0a7f1@github.com>

On Fri, 23 Aug 2024 19:03:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 59:
> 
>> 57:     public static void main(String... args) throws Exception {
>> 58:          String zGenerational = args[0];
>> 59:          String compactHeaders = "-XX:" + (zGenerational.equals("-XX:+ZGenerational") ? "+" : "-") + "UseCompactObjectHeaders";
> 
> The test failing with
>  stdout: [[0.176s][info][cds] trying to map /opt/mach5/mesos/work_dir/slaves/a20696e7-ae7d-4d37-8e9c-83f99ef002cb-S2261/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f0801999-993f-4e08-b017-08b33a8ec44f/runs/34cc555e-ae8f-4a48-8175-e998194f204b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_cds_relocation/scratch/5/appcds-18h50m16s773.jsa
> [0.176s][info][cds] Opened archive /opt/mach5/mesos/work_dir/slaves/a20696e7-ae7d-4d37-8e9c-83f99ef002cb-S2261/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/f0801999-993f-4e08-b017-08b33a8ec44f/runs/34cc555e-ae8f-4a48-8175-e998194f204b/testoutput/test-support/jtreg_open_test_hotspot_jtreg_hotspot_cds_relocation/scratch/5/appcds-18h50m16s773.jsa.
> [0.176s][info][cds] Archive was created with UseCompressedOops = 0, UseCompressedClassPointers = 1
> [0.176s][info][cds] The shared archive file's UseCompactObjectHeaders setting (enabled) does not equal the current UseCompactObjectHeaders setting (disabled).
> [0.176s][info][cds] Initialize static archive failed.
> [0.176s][info][cds] Unable to map shared spaces
> [0.176s][error][cds] An error has occurred while processing the shared archive file.
> [0.176s][error][cds] Unable to map shared spaces
> Error occurred during initialization of VM
> Unable to use shared archive.
> ];
>  stderr: []
>  exitValue = 1
> 
> java.lang.RuntimeException: 'Hello World' missing from stdout/stderr
> 	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:252)
> 	at TestZGCWithCDS.main(TestZGCWithCDS.java:123)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException
> JavaTest Message: shutting down test

Roman has two weeks of vacation; I am taking a look at this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1730855152

From ysr at openjdk.org  Mon Aug 26 16:17:47 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 26 Aug 2024 16:17:47 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments [v2]
In-Reply-To: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
Message-ID: <Mg2MBMHTmJhTt-ljZM3VHC4cIe_pOVxeLquMcWTsMNw=.99a02f01-1113-44f3-b65b-b0daa5c998d6@github.com>

> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various comments. This ticket gathers together several of those changes.
> 
> **Testing:** 
> - [x] GHA
> - [x] SPECjbb w/GenShen
> - [x] jtreg:tier1
> - [x] jtreg:hotspot_gc (one test fails with OOM in master as well as current branch; will investigate that separately)
> - [ ] Codepipeline testing (in progress)

Y. Srinivas Ramakrishna 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 review_changes_2
 - Cleanup and get ready for testing & review.
 - Sharpen assert for testing. Need more changes after this. Don't review
   yet.
 - Testing only: do not review this change.
 - Merge branch 'master' into review_changes_2
 - JDK-8338780 GenShen: Fix up some comments

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/484/files
  - new: https://git.openjdk.org/shenandoah/pull/484/files/2e889682..9e994326

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=484&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=484&range=00-01

  Stats: 47 lines in 4 files changed: 1 ins; 34 del; 12 mod
  Patch: https://git.openjdk.org/shenandoah/pull/484.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/484/head:pull/484

PR: https://git.openjdk.org/shenandoah/pull/484

From ysr at openjdk.org  Mon Aug 26 16:17:47 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 26 Aug 2024 16:17:47 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments [v2]
In-Reply-To: <XlZ_N8jGIJDyjDAy9RpxQtcsy3OW6XL_B6ek3JjqZQc=.3e53b2c1-b72e-49a0-8405-19e12fdec18e@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
 <kFhQsM8mY03k37pXIW01jMbqmGddjJQ-QrP4OuCZ70A=.f3905cfd-c5d2-4c83-ac55-c5b612baefe6@github.com>
 <I8P4o64OEsHZzFiSOpYWmRYmZ-jHdjYSDm9ZWY3SXcE=.a864e118-a7a1-42fa-a573-3bc887f715fc@github.com>
 <bfhUE3j1T1i0VTW6l_oMBQDouG7mB1nsijsbwoZCUms=.20de1c98-88ce-4f09-8804-55389fa9a4e7@github.com>
 <XlZ_N8jGIJDyjDAy9RpxQtcsy3OW6XL_B6ek3JjqZQc=.3e53b2c1-b72e-49a0-8405-19e12fdec18e@github.com>
Message-ID: <2KypKcLaOzUvuS2fpG1nW-_AwHg1bb_rnjuP94RVsYU=.8827c4d9-6c1b-4a14-bdec-0b97ec4d7428@github.com>

On Thu, 22 Aug 2024 18:16:06 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> You are correct.  In ShenandoahGenerationalHeuristics::choose_collection_set(), we only call prime_collection_set() if generation->is_young().  For global collections, we will not prime the collection set, which means we will not preselect any regions for promotion.
>> 
>> Given this reality, we can remove the call to add_preselected_regions_to_collection_SET() from ShenandoahGlobalHeuristics::choose_collection_set_from_regiondata().  Keeping the assertion in place is how we know it was safe to remove the call to add preselected regions.
>> 
>> We could do some archeology on the code to remind ourselves how we got here.  But maybe not necessary.
>
> Could lines 114-118 be replaced with: assert(!cset->is_preselected(r->index(), comment)

Thanks Kelvin! I'll convert this to a draft while I do a few experiments/investigations etc. along the lines of your suggestions... (Feel free to leave more comments here as necessary though; thanks!)

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/484#discussion_r1727810775

From ysr at openjdk.org  Mon Aug 26 16:17:47 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 26 Aug 2024 16:17:47 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments [v2]
In-Reply-To: <2KypKcLaOzUvuS2fpG1nW-_AwHg1bb_rnjuP94RVsYU=.8827c4d9-6c1b-4a14-bdec-0b97ec4d7428@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
 <kFhQsM8mY03k37pXIW01jMbqmGddjJQ-QrP4OuCZ70A=.f3905cfd-c5d2-4c83-ac55-c5b612baefe6@github.com>
 <I8P4o64OEsHZzFiSOpYWmRYmZ-jHdjYSDm9ZWY3SXcE=.a864e118-a7a1-42fa-a573-3bc887f715fc@github.com>
 <bfhUE3j1T1i0VTW6l_oMBQDouG7mB1nsijsbwoZCUms=.20de1c98-88ce-4f09-8804-55389fa9a4e7@github.com>
 <XlZ_N8jGIJDyjDAy9RpxQtcsy3OW6XL_B6ek3JjqZQc=.3e53b2c1-b72e-49a0-8405-19e12fdec18e@github.com>
 <2KypKcLaOzUvuS2fpG1nW-_AwHg1bb_rnjuP94RVsYU=.8827c4d9-6c1b-4a14-bdec-0b97ec4d7428@github.com>
Message-ID: <DAE7sxV1DG0GlQ7D2dF2O26_m1CAibD93EYf7KKBHm0=.7f484f1e-825c-4be6-baef-f4a0b70f0179@github.com>

On Thu, 22 Aug 2024 21:02:45 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Could lines 114-118 be replaced with: assert(!cset->is_preselected(r->index(), comment)
>
> Thanks Kelvin! I'll convert this to a draft while I do a few experiments/investigations etc. along the lines of your suggestions... (Feel free to leave more comments here as necessary though; thanks!)

You are right Kelvin. I made the changes you suggested and will run them through all of the tests. Once that is done, I'll reopen this for a quick re-review. Thanks!

PS: (Archeology) The code was duplicated in https://github.com/openjdk/shenandoah/pull/292 and then the `fatal()` was added in https://github.com/openjdk/shenandoah/pull/318.
Interestingly, for the latter, I had a bunch of review feedback (of a general nature of refactoring) that I never quite got around to submitting, it seems (as I discovered when I loaded the PR in my browser; it's probably pretty stale by now).

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/484#discussion_r1730455087

From wkemper at openjdk.org  Mon Aug 26 20:49:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 26 Aug 2024 20:49:26 GMT
Subject: Integrated: 8338881: GenShen: Use explicit third temp register for
 post barrier
In-Reply-To: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>
References: <Ml5QNmiJ7t9f0tWNvG9qt7qLsqyOrqzcVEjsvXHMc5c=.4f92f6f9-5a5f-4a7d-8c8f-4fd98b095cf8@github.com>
Message-ID: <d-trRvHh5BgPAJYldamoYIpOUBfP5KT-DM1magBEPXQ=.7e9f3fd4-f581-4a4f-bec9-457ab1fc4ef7@github.com>

On Fri, 23 Aug 2024 17:06:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Use register given as `tmp3` argument instead of "out of the blue" `r3`
> * Simplify logic for post barrier call
> 
> ## Testing
> GHA, internal pipelines

This pull request has now been integrated.

Changeset: 12af9f62
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/12af9f629ab2f3d29392eb8e6ab2abd518723480
Stats:     19 lines in 1 file changed: 5 ins; 13 del; 1 mod

8338881: GenShen: Use explicit third temp register for post barrier

Reviewed-by: shade

-------------

PR: https://git.openjdk.org/shenandoah/pull/486

From cjplummer at openjdk.org  Mon Aug 26 21:56:04 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 26 Aug 2024 21:56:04 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <Og4I5G3w51d7zF27JawLM9pm_XpHwijYt3lJZ4hpeWQ=.fd974e82-2ce0-4ebd-b49e-108ab87690a9@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 85:

> 83: 
> 84:   private static Klass getKlass(Mark mark) {
> 85:     assert(VM.getVM().isCompactObjectHeadersEnabled());

`mark.getKlass()` already does this assert. I don't see any value in this `getKlass()` method. The caller should just call `getMark().getKlass()` rather than `getKlass(getMark())`.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Oop.java line 169:

> 167:         } else {
> 168:           visitor.doMetadata(klass, true);
> 169:         }

Why is there no `visitor.doMetadata()` call for the compressed object header case?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1731849434
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1731866842

From kdnilsen at openjdk.org  Mon Aug 26 23:16:32 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 26 Aug 2024 23:16:32 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments [v2]
In-Reply-To: <Mg2MBMHTmJhTt-ljZM3VHC4cIe_pOVxeLquMcWTsMNw=.99a02f01-1113-44f3-b65b-b0daa5c998d6@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
 <Mg2MBMHTmJhTt-ljZM3VHC4cIe_pOVxeLquMcWTsMNw=.99a02f01-1113-44f3-b65b-b0daa5c998d6@github.com>
Message-ID: <YnZYhBZMt7-6Il3aT455L51905gCzPLHH3JYXXUW7Js=.116ddf71-3b50-4c02-825e-bf76ef016811@github.com>

On Mon, 26 Aug 2024 16:17:47 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various comments. This ticket gathers together several of those changes.
>> 
>> **Testing:** 
>> - [x] GHA
>> - [x] SPECjbb w/GenShen
>> - [x] jtreg:tier1
>> - [x] jtreg:hotspot_gc (one test fails with OOM in master as well as current branch; will investigate that separately)
>> - [ ] Codepipeline testing (in progress)
>
> Y. Srinivas Ramakrishna 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 review_changes_2
>  - Cleanup and get ready for testing & review.
>  - Sharpen assert for testing. Need more changes after this. Don't review
>    yet.
>  - Testing only: do not review this change.
>  - Merge branch 'master' into review_changes_2
>  - JDK-8338780 GenShen: Fix up some comments

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/484#pullrequestreview-2261808429

From ysr at openjdk.org  Mon Aug 26 23:26:30 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 26 Aug 2024 23:26:30 GMT
Subject: Integrated: 8338780: GenShen: Fix up some comments
In-Reply-To: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
Message-ID: <IwhJorZtXR6wq3G4BzNkOppXaQcYMoq8FLbT0PenNlA=.6071a98f-3558-4bad-b00c-db509aaca480@github.com>

On Thu, 22 Aug 2024 17:20:49 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> In https://github.com/openjdk/jdk/pull/20395 Aleksey provided some suggestions for improving various comments. This ticket gathers together several of those changes. Additionally, there was a small simplification in the collection set construction for the global gc case as a result of the review & ensuing discussion.
> 
> **Testing:** 
> - [x] GHA
> - [x] SPECjbb w/GenShen
> - [x] jtreg:tier1
> - [x] jtreg:hotspot_gc (one test fails with OOM in master as well as current branch; will investigate that separately)
> - [x] Codepipeline testing

This pull request has now been integrated.

Changeset: 977200a0
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/977200a0c073e90754f56730477d0fa32fd7ec9a
Stats:     114 lines in 4 files changed: 34 ins; 72 del; 8 mod

8338780: GenShen: Fix up some comments

Reviewed-by: kdnilsen

-------------

PR: https://git.openjdk.org/shenandoah/pull/484

From ysr at openjdk.org  Mon Aug 26 23:26:30 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 26 Aug 2024 23:26:30 GMT
Subject: RFR: 8338780: GenShen: Fix up some comments [v2]
In-Reply-To: <YnZYhBZMt7-6Il3aT455L51905gCzPLHH3JYXXUW7Js=.116ddf71-3b50-4c02-825e-bf76ef016811@github.com>
References: <i64HNGy3ZDiHCdSvlfLADfZmaCsNb7TRDNRUOUsMaHY=.e242de93-f2d2-47f6-a6e9-cfa5fb3c2896@github.com>
 <Mg2MBMHTmJhTt-ljZM3VHC4cIe_pOVxeLquMcWTsMNw=.99a02f01-1113-44f3-b65b-b0daa5c998d6@github.com>
 <YnZYhBZMt7-6Il3aT455L51905gCzPLHH3JYXXUW7Js=.116ddf71-3b50-4c02-825e-bf76ef016811@github.com>
Message-ID: <6MFg9DT0QeR4_IfF67sC_9y89sIWFI2fExg02lFj-vo=.ebee0d72-41e7-4ff2-94cc-487b0e1aeb94@github.com>

On Mon, 26 Aug 2024 23:13:31 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna 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 review_changes_2
>>  - Cleanup and get ready for testing & review.
>>  - Sharpen assert for testing. Need more changes after this. Don't review
>>    yet.
>>  - Testing only: do not review this change.
>>  - Merge branch 'master' into review_changes_2
>>  - JDK-8338780 GenShen: Fix up some comments
>
> Marked as reviewed by kdnilsen (Committer).

Thanks @kdnilsen!

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/484#issuecomment-2311276192

From fyang at openjdk.org  Tue Aug 27 05:42:05 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 27 Aug 2024 05:42:05 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
Message-ID: <n33g0VZINE0Qly_UoJV2zOCDkapbuqFgRyzTYor6TrE=.7acb0ac5-5bbe-4747-bf3c-20110201616c@github.com>

On Fri, 23 Aug 2024 18:42:28 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp line 170:
> 
>> 168:   mv(tmp1, (int32_t)(intptr_t)markWord::prototype().value());
>> 169:   sd(tmp1, Address(obj, oopDesc::mark_offset_in_bytes()));
>> 170: // Todo UseCompactObjectHeaders
> 
> Can I ask, will this pr fullly support riscv?

@Hamlin-Li : AFAIK, porting to linux-riscv platform has NOT been started yet. To avoid duplicate work, please let me know if anyone is interested or has been working on it :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1732153574

From mli at openjdk.org  Tue Aug 27 07:46:10 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 27 Aug 2024 07:46:10 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <n33g0VZINE0Qly_UoJV2zOCDkapbuqFgRyzTYor6TrE=.7acb0ac5-5bbe-4747-bf3c-20110201616c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <utcfd2HiwL8a7ut2UJ7tHb1P_oz5TKXA9bwGQ5G_FnE=.63fa2666-dc3f-406d-b8d2-4f960f05f05d@github.com>
 <n33g0VZINE0Qly_UoJV2zOCDkapbuqFgRyzTYor6TrE=.7acb0ac5-5bbe-4747-bf3c-20110201616c@github.com>
Message-ID: <wVUrQQtzaYdZNPBPyiuln0Zd8C67zG2y0yX2Iik6l_I=.0be5dcf7-c48d-4bb9-9966-23530f0b8d2e@github.com>

On Tue, 27 Aug 2024 05:37:30 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp line 170:
>> 
>>> 168:   mv(tmp1, (int32_t)(intptr_t)markWord::prototype().value());
>>> 169:   sd(tmp1, Address(obj, oopDesc::mark_offset_in_bytes()));
>>> 170: // Todo UseCompactObjectHeaders
>> 
>> Can I ask, will this pr fullly support riscv?
>
> @Hamlin-Li : AFAIK, porting to linux-riscv platform has NOT been started yet. To avoid duplicate work, please let me know if anyone is interested or has been working on it :-)

Yes, I'm interested in it. Thanks for raising the discussion. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1732312058

From ysr at openjdk.org  Tue Aug 27 16:35:31 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 27 Aug 2024 16:35:31 GMT
Subject: RFR: 8339094: Shenandoah: Fix up test output from
 ShenandoahNumberSeqTest
Message-ID: <2zAxAnKX_KTQxJeX5NzyRlEtEhuHdZS0_LletIDPkC8=.62cf3371-5963-4fa8-a70e-0db7f630b123@github.com>

8339094: Shenandoah: Fix up test output from ShenandoahNumberSeqTest

-------------

Commit messages:
 - JDK-8339094 : Shenandoah: Fix up test output from ShenandoahNumberSeqTest

Changes: https://git.openjdk.org/shenandoah/pull/487/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=487&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339094
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah/pull/487.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/487/head:pull/487

PR: https://git.openjdk.org/shenandoah/pull/487

From wkemper at openjdk.org  Tue Aug 27 17:54:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 27 Aug 2024 17:54:26 GMT
Subject: RFR: 8339094: Shenandoah: Fix up test output from
 ShenandoahNumberSeqTest
In-Reply-To: <2zAxAnKX_KTQxJeX5NzyRlEtEhuHdZS0_LletIDPkC8=.62cf3371-5963-4fa8-a70e-0db7f630b123@github.com>
References: <2zAxAnKX_KTQxJeX5NzyRlEtEhuHdZS0_LletIDPkC8=.62cf3371-5963-4fa8-a70e-0db7f630b123@github.com>
Message-ID: <hpiW-o9TE8WrnuTOfNKCa1honhonCpX82fEiAXx4lS4=.b4ae274d-b480-47a0-8bea-4353909f3003@github.com>

On Tue, 27 Aug 2024 16:30:16 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> 8339094: Shenandoah: Fix up test output from ShenandoahNumberSeqTest

Marked as reviewed by wkemper (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/487#pullrequestreview-2264103379

From wkemper at openjdk.org  Tue Aug 27 18:19:55 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 27 Aug 2024 18:19:55 GMT
Subject: RFR: Merge openjdk/jdk:master [v5]
In-Reply-To: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
Message-ID: <Hcj03cCVxt480BwX6s7EKJ5VYkOLyLXHgtAQWVbNOiM=.369b615f-88ae-46a1-9d1e-967e3ea4a78e@github.com>

> Merges tag jdk-24+12

William Kemper has updated the pull request incrementally with 31 additional commits since the last revision:

 - Fix merge issues
 - 8338936: StringConcatFactory optimize the construction of MethodType and MethodTypeDesc
   
   Reviewed-by: redestad, liach
 - 8338928: Update SwingSet2 "About" image to reference openjdk.org
   
   Reviewed-by: abhiscxk, honkar
 - 8338538: [JVMCI] Allow HotSpotJVMCIRuntime#getJObjectValue to be called by a HotSpot CompileBroker compiler thread
   
   Reviewed-by: dnsimon
 - 8338906: Avoid passing EnumDescs and extra classes to type switch methods that don't use them
   
   Reviewed-by: liach, jlahoda
 - 8338979: Avoid bootstrapped switches in the classfile API
   
   Reviewed-by: liach, asotona
 - 8331671: Implement JEP 472: Prepare to Restrict the Use of JNI
   
   Reviewed-by: jpai, prr, ihse, kcr, alanb
 - 8338844: C2: remove useless code in PhaseIdealLoop::place_outside_loop() after 8335709
   
   Reviewed-by: chagedorn, thartmann
 - 8336830: C2: assert(get_loop(lca)->_nest < n_loop->_nest || lca->in(0)->is_NeverBranch()) failed: must not be moved into inner loop
   
   Co-authored-by: Emanuel Peter <epeter at openjdk.org>
   Reviewed-by: thartmann, chagedorn, epeter
 - 8338785: The java.awt.datatransfer.SystemFlavorMap#FLAVOR_MAP_KEY field is not used
   
   Reviewed-by: honkar, dnguyen, prr
 - ... and 21 more: https://git.openjdk.org/shenandoah/compare/67aabca1...2f79cafe

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/483/files
  - new: https://git.openjdk.org/shenandoah/pull/483/files/67aabca1..2f79cafe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=04
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=03-04

  Stats: 3678 lines in 222 files changed: 3010 ins; 232 del; 436 mod
  Patch: https://git.openjdk.org/shenandoah/pull/483.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/483/head:pull/483

PR: https://git.openjdk.org/shenandoah/pull/483

From kdnilsen at openjdk.org  Tue Aug 27 19:51:18 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 27 Aug 2024 19:51:18 GMT
Subject: RFR: 8339094: Shenandoah: Fix up test output from
 ShenandoahNumberSeqTest
In-Reply-To: <2zAxAnKX_KTQxJeX5NzyRlEtEhuHdZS0_LletIDPkC8=.62cf3371-5963-4fa8-a70e-0db7f630b123@github.com>
References: <2zAxAnKX_KTQxJeX5NzyRlEtEhuHdZS0_LletIDPkC8=.62cf3371-5963-4fa8-a70e-0db7f630b123@github.com>
Message-ID: <DUq9iy5r5H0s8t4CpkggkWZe__JnwBivfC5zAXskoOA=.9e6c8af5-b3df-467e-8754-2f7a30aa4faa@github.com>

On Tue, 27 Aug 2024 16:30:16 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> 8339094: Shenandoah: Fix up test output from ShenandoahNumberSeqTest

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/487#pullrequestreview-2264318364

From gziemski at openjdk.org  Tue Aug 27 21:16:31 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 27 Aug 2024 21:16:31 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <ZVP0_QOiwVHjfQgUdgyAf1DaDVQM16rsG1GIDkd1ajg=.ebf04832-282f-45d0-96d2-f73ff8c5d505@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <aSpuAgobZeTLeb6vZy2u21kXbbHgIUV10YTgyqn3XMo=.1679b329-1cc0-4cb5-840d-d46c624e8498@github.com>
 <pX0Uw3i-woU_vZbSjZqDeEVVIM9QLvbni_pozvVtf2M=.22ee8d97-9ade-4139-bed4-07cd85908707@github.com>
 <ZVP0_QOiwVHjfQgUdgyAf1DaDVQM16rsG1GIDkd1ajg=.ebf04832-282f-45d0-96d2-f73ff8c5d505@github.com>
Message-ID: <sX1uf8espOQu5Ly9Wh6ujmdpuqlO8nGgiPVoem_AVgk=.c1c652ff-b1f3-4928-80d1-9e5b64e167a6@github.com>

On Thu, 15 Aug 2024 06:31:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I agree with @tstuefe here. MemFlag and MemType sound far too general when this is NMT specific.
>> 
>> Yes, it is not very specific, but it also not hard to learn and then know what this type is all about.
>> 
>>> My preference to keep the "flags" part of the type was to avoid needing to rename many parameters. The usage of MEMFLAGS flags is quite extensive. I would not want to see a partial approach here where we end up with a non-flag type name but a flag variable name.
>> 
>> I think we should rename all the 'flags' variables in the same change.
>> 
>>> NMTTypeFlag would I hope satisfy Thomas's requirement and avoid the need to do variable renames.
>> 
>> * To me, that's really not an appealing name for a type that is going to be used by all parts of the HotSpot code base. I much more prefer a shorter name that is easy on the eyes, then a longer and more specific name that is an eyesore.
>> 
>> * And even as a longer name, it doesn't tell what it is going to be used for. What is a Native Memory Tracker Type Flag?
>> 
>> * I don't want us to select a bad name so that we don't have to change the variable names.
>> 
>> * Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.
>> 
>> With all that said, I hope it is clear that we various reviewers have different opinions around this and that we don't integrate this before we have some kind of consensus about the way forward with this.
>
>> What is a Native Memory Tracker Type Flag?
> 
> It is a flag telling us the type of native memory being tracked.
> 
>> Whatever we choose we also need to consider the mt prefix of things like mtGC, mtClass, etc.
> 
> And what does that stand for: memory type? memory tracker? Arguably they should have been nmtGC etc.
> 
>> I think we should rename all the 'flags' variables in the same change.
> 
> Okay. That's a big change but I'd prefer it to any half-way measures.

@dholmes-ora @tstuefe @stefank @kimbarrett @afshin-zafari @jdksjolen 

hi all,

I would like to see if we can give this another go, now that we got some time to sleep on it.

How about this - I created a table with some name candidates, so everyone can see where everyone else is. We all can choose 3 candidates that we can rank 1, 2 and 3. At the end we tabulate the answer and the one with highest score wins?

| developer | MemType | MemTypeFlag | NMTCat | NMTGroup | NMT_MemType | NMT::MemType |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| gerard | 1 | 0 | 0 | 0 | 2 | 3 |
| David  | ? | ? | ? | ? | ? | ? |
| Thomas | ? | ? | ? | ? | ? | ? |
| Johan  | ? | ? | ? | ? | ? | ? |
| Afshin | ? | ? | ? | ? | ? | ? |
| Stefan | ? | ? | ? | ? | ? | ? |
| Kim    | ? | ? | ? | ? | ? | ? |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2313584428

From wkemper at openjdk.org  Tue Aug 27 21:33:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 27 Aug 2024 21:33:02 GMT
Subject: RFR: 8339127: GenShen: Restore completed mark context assertion during
 class unloading
Message-ID: <KfCq30cfijM3QG-LPv2D4lPKT4gtI9D-bF6Nx7mSonA=.a7eee744-5fd5-439f-b13c-ffb99477d925@github.com>

We only unload classes during a global GC, so it should be safe to reinstate this assertion.

-------------

Commit messages:
 - Assert mark context is complete before unloading classes

Changes: https://git.openjdk.org/shenandoah/pull/488/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=488&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339127
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/488.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/488/head:pull/488

PR: https://git.openjdk.org/shenandoah/pull/488

From ysr at openjdk.org  Tue Aug 27 23:20:45 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 27 Aug 2024 23:20:45 GMT
Subject: Integrated: 8339094: Shenandoah: Fix up test output from
 ShenandoahNumberSeqTest
In-Reply-To: <2zAxAnKX_KTQxJeX5NzyRlEtEhuHdZS0_LletIDPkC8=.62cf3371-5963-4fa8-a70e-0db7f630b123@github.com>
References: <2zAxAnKX_KTQxJeX5NzyRlEtEhuHdZS0_LletIDPkC8=.62cf3371-5963-4fa8-a70e-0db7f630b123@github.com>
Message-ID: <1FPup7wwMFwDpcamaWKoKswXi5C6QBJz9nV46kKq4ws=.3d480ed1-1ac8-4db0-8e48-298eda8c2bc8@github.com>

On Tue, 27 Aug 2024 16:30:16 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Shenandoah: Fix up test output from ShenandoahNumberSeqTest
> 
> Trivial change: added percentile labels on distribution; slightly adjusted format for readability.
> 
> **Testing:**
> - [x] make test TEST="gtest:BasicShenandoahNumberSeqTest gtest:ShenandoahNumberSeqMergeTest" w/fastdebug & release

This pull request has now been integrated.

Changeset: f8273594
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/f8273594124a2b17fe855b8eb10458e0b9291bd6
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8339094: Shenandoah: Fix up test output from ShenandoahNumberSeqTest

Shenandoah: Fix up test output from ShenandoahNumberSeqTest

Trivial change: added percentile labels on distribution; slightly adjusted format for readability.

**Testing:**
- [ ] make test TEST="gtest:BasicShenandoahNumberSeqTest gtest:ShenandoahNumberSeqMergeTest" w/fastdebug & release

Reviewed-by: wkemper, kdnilsen

-------------

PR: https://git.openjdk.org/shenandoah/pull/487

From wkemper at openjdk.org  Wed Aug 28 00:33:08 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 28 Aug 2024 00:33:08 GMT
Subject: RFR: Merge openjdk/jdk:master [v6]
In-Reply-To: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
Message-ID: <qbBcHh1lf0lML_z1h9mPgkNo2maVIQkEvQYh1aNE2J4=.36148e6c-187d-4bcc-8fd2-5bb64098680f@github.com>

> Merges tag jdk-24+12

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Disable CDS support for Shenandoah

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/483/files
  - new: https://git.openjdk.org/shenandoah/pull/483/files/2f79cafe..7847a38d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=05
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/483.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/483/head:pull/483

PR: https://git.openjdk.org/shenandoah/pull/483

From dholmes at openjdk.org  Wed Aug 28 00:41:20 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 28 Aug 2024 00:41:20 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <xpLlMWjXbaSwPwOjKNB-_Xw-qV6Pyvx-FR2lZs8qi6M=.e4640b09-89ae-4b8b-9133-07af90e166a9@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

Hmmmm .... I like the structure of `NMT::MemType` but also prefer to keep "flag" in the name to avoid renaming parameters (or having oddly named parameters). Can I vote for `NMT::MemTypeFlag`? :) Otherwise:
- `MemTypeFlag` - 3 points
- `NMT::MemType` - 2 points
- `NMT_MemType` - 1 point (but maybe `NMTMemType`?)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2313858939

From stuefe at openjdk.org  Wed Aug 28 05:01:25 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 28 Aug 2024 05:01:25 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <7S3vfLFTqQ00fyeqqLQ0INQxAUpIktjo7XTnzlFSSY8=.6dd191e9-2ddf-426a-8da7-7983e1c12e47@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

NMTCat,  NMTGroup 3 points

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2314317309

From azafari at openjdk.org  Wed Aug 28 08:04:20 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 28 Aug 2024 08:04:20 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <nAs1NWVvopSzVYqGCyZ57NZjvKlmPmJLT4LJFe-9_7c=.3ddb3793-5b3c-4f3e-b399-5a27a384b3db@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

- `MemTypeFlag` : 3
- `NMT::MemType` : 2
IMHO, `MemType` without NMT is a global name and possibly will be source of confusion in the code or by the developers.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2314608812

From jsjolen at openjdk.org  Wed Aug 28 09:06:26 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 28 Aug 2024 09:06:26 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <EdpJpXGzdO8Mx0vNjb4bx9xK2_icA0D9PXUqCjjU4-U=.a60c5321-44bb-463b-b2a5-d92eea11d760@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

NMTGroup 3 points, NMTCat 2 points are my picks (NMTCategory is even better than NMTCat, imho).

No 1 point given, I want these to win :P. Thank you for the effort with this table, may the highest point taker win :-).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2314753974

From coleenp at openjdk.org  Wed Aug 28 12:37:20 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 28 Aug 2024 12:37:20 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <LHiGDyQ7-kKnFuk_MAl53io7_42-qdF0DMw2NSAFOas=.a0d2a5b3-37a0-450d-8cf8-836f34a2b0e8@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

I like NMT::MemType 3 points.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2315202137

From gziemski at openjdk.org  Wed Aug 28 16:41:22 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 28 Aug 2024 16:41:22 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <-NKUnExfzAqwhaGAtlJQD81b6wtoEnOhaXF4R779--s=.6d31a953-da4f-4875-8950-6971148ff639@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <-NKUnExfzAqwhaGAtlJQD81b6wtoEnOhaXF4R779--s=.6d31a953-da4f-4875-8950-6971148ff639@github.com>
Message-ID: <19VwWXE1ZczFuYtfnD2ioXSV-oh40JUlk67aMsNIGN8=.0783ce36-2668-4866-952a-94cbfcbf4ba4@github.com>

On Thu, 15 Aug 2024 07:59:21 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> The suggestion of "nmtGC" from @daholmes initially looked somewhat appealing
> to me. But that then suggests "NMTType" or (better?) "NMTGroup" or something
> like that. But I don't much like the look of or typing those acronyms. (Note
> that NMTGroup is HotSpot style, not NmtGroup.)
> 
> So I'm still preferring "MemType".

@kimbarrett @stefank Would you like to name your nominees? As last voters you have quite weight behind your choices...

|        | MemType | MemTypeFlag | NMTCat         | NMTGroup | NMT_MemType   | NMT::MemType |
| :---:  | :---:   | :---:       | :---:          | :---:    | :---:         | :---:        |
| gerard | 1       | 0           | 0              | 0        | 2             | 3            |
| David  | 0       | 3           | 0              | 0        | 1(NMTMemType) | 2            |
| Thomas | 0       | 0           | 2              | 3        | 0             | 0            |
| Johan  | 0       | 0           | 2(NMTCategory) | 3        | 0             | 0            |
| Afshin | 0       | 3           | 0              | 0        | 0             | 2            |
| Stefan | ?       | ?           | ?              | ?        | ?             | ?            |
| Kim    | ?       | ?           | ?              | ?        | ?             | ?            |
| Coleen | 0       | 0           | 0              | 0        | 0             | 3            |
|        | 1       | 6           | 4              | 6        | 3             | 10           |

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2315814746

From dcubed at openjdk.org  Wed Aug 28 17:13:21 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 28 Aug 2024 17:13:21 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <DDuFLsSljIlo3lcd40PFeqDaoV5fEbT0yDn4pA-8Luc=.5e321e42-5561-4113-9ca6-adcaa645ab5d@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

I think it must have `NMT` somewhere in the name. `NMTGroup` sounds like
there could more than one value set at one time, but that might be just me.
`NMTCat` (and `NMTGroup`) lose the idea that `Type` should be in there somewhere.

For ease of typing, I'm not fond of `NMT::MemType` but it has the appeal of being
in a namespace...

So I'm going with:
NMT::MemType - 3 points
NMT_MemType/NMTMemType(prefer for ease of typing) - 2 points

and I'm skipping a 1 point assignment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2315871575

From wkemper at openjdk.org  Wed Aug 28 17:32:22 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 28 Aug 2024 17:32:22 GMT
Subject: RFR: Merge openjdk/jdk:master [v7]
In-Reply-To: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
Message-ID: <G3mq4pLUd9CedkV3eXL2KGDPRSjhJlZDzKpgUY3yOmM=.6da9c958-b2e6-46da-8331-0890cef34b1f@github.com>

> Merges tag jdk-24+12

William Kemper has updated the pull request incrementally with one additional commit since the last revision:

  Disable CDS only for generational mode (need to fix card table)

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/483/files
  - new: https://git.openjdk.org/shenandoah/pull/483/files/7847a38d..61ef37a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=06
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/shenandoah/pull/483.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/483/head:pull/483

PR: https://git.openjdk.org/shenandoah/pull/483

From kdnilsen at openjdk.org  Wed Aug 28 17:42:42 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 28 Aug 2024 17:42:42 GMT
Subject: RFR: 8339127: GenShen: Restore completed mark context assertion
 during class unloading
In-Reply-To: <KfCq30cfijM3QG-LPv2D4lPKT4gtI9D-bF6Nx7mSonA=.a7eee744-5fd5-439f-b13c-ffb99477d925@github.com>
References: <KfCq30cfijM3QG-LPv2D4lPKT4gtI9D-bF6Nx7mSonA=.a7eee744-5fd5-439f-b13c-ffb99477d925@github.com>
Message-ID: <0KAxPLLOb46ro1ODLm5WoKoS8Qhgz90CPINLDLYCF6E=.f7e9af76-4999-4041-8014-2804ec8388fb@github.com>

On Tue, 27 Aug 2024 21:25:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We only unload classes during a global GC, so it is safe to assert that marking is complete at this point.
> 
> ### Testing
> GHA, internal pipelines

Marked as reviewed by kdnilsen (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/488#pullrequestreview-2266899992

From ysr at openjdk.org  Wed Aug 28 19:13:41 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 28 Aug 2024 19:13:41 GMT
Subject: RFR: 8339127: GenShen: Restore completed mark context assertion
 during class unloading
In-Reply-To: <KfCq30cfijM3QG-LPv2D4lPKT4gtI9D-bF6Nx7mSonA=.a7eee744-5fd5-439f-b13c-ffb99477d925@github.com>
References: <KfCq30cfijM3QG-LPv2D4lPKT4gtI9D-bF6Nx7mSonA=.a7eee744-5fd5-439f-b13c-ffb99477d925@github.com>
Message-ID: <ieVQlN1P2XJyEb9hGknzDPkJWvLRkh6QxDj-009DJV4=.f7b10971-27ea-4f91-9956-146a320c744a@github.com>

On Tue, 27 Aug 2024 21:25:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We only unload classes during a global GC, so it is safe to assert that marking is complete at this point.
> 
> ### Testing
> GHA, internal pipelines

Marked as reviewed by ysr (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/488#pullrequestreview-2267064553

From wkemper at openjdk.org  Wed Aug 28 20:56:44 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 28 Aug 2024 20:56:44 GMT
Subject: Integrated: 8339127: GenShen: Restore completed mark context assertion
 during class unloading
In-Reply-To: <KfCq30cfijM3QG-LPv2D4lPKT4gtI9D-bF6Nx7mSonA=.a7eee744-5fd5-439f-b13c-ffb99477d925@github.com>
References: <KfCq30cfijM3QG-LPv2D4lPKT4gtI9D-bF6Nx7mSonA=.a7eee744-5fd5-439f-b13c-ffb99477d925@github.com>
Message-ID: <b5ZhS3ZeedY6CNz5CpVxLalBu_D0877muD8pD84ZTWU=.a4a8716f-cccc-461e-8710-5c31b412b96e@github.com>

On Tue, 27 Aug 2024 21:25:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We only unload classes during a global GC, so it is safe to assert that marking is complete at this point.
> 
> ### Testing
> GHA, internal pipelines

This pull request has now been integrated.

Changeset: c7cfc7fa
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/c7cfc7fa32fbe90bed39456288c03d74aa2432b9
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8339127: GenShen: Restore completed mark context assertion during class unloading

Reviewed-by: kdnilsen, ysr

-------------

PR: https://git.openjdk.org/shenandoah/pull/488

From duke at openjdk.org  Wed Aug 28 22:57:59 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Wed, 28 Aug 2024 22:57:59 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation Information
 JFR Logging
Message-ID: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>

Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.

-------------

Commit messages:
 - Removing trailing whitespace
 - Removing comment
 - Merge branch 'openjdk:master' into JDK-8339197
 - Adding ShenandoahEvacInfo JFR Event
 - Adding gen event messages

Changes: https://git.openjdk.org/shenandoah/pull/489/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=489&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339197
  Stats: 241 lines in 8 files changed: 234 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah/pull/489.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/489/head:pull/489

PR: https://git.openjdk.org/shenandoah/pull/489

From kdnilsen at openjdk.org  Thu Aug 29 00:09:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 29 Aug 2024 00:09:35 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging
In-Reply-To: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
Message-ID: <sz6UjzTvmoK1u3W2E0bi1Iuo-QdMzXgWVUpuaNDwxa8=.fda64ffe-a75b-4c47-ac2b-ffb9f308463c@github.com>

On Wed, 28 Aug 2024 22:43:28 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 233:

> 231:     evacInfo.set_regions_freed(free_regions);
> 232: 
> 233:     ShenandoahTracer().report_evacuation_info(&evacInfo);

After we chatted, I thought of one other detail that would be nice to gather in this evacInfo event: regions to be promoted in place.  Associated with this detail, would be nice to know:
1. how many regions
2. how much garbage is known to exist within these regions
3. how much free memory is known to exist within these regions
Same for humongous regions promoted in place.

See humongous_regions_promoted, regular_regions_promoted_in_place, regular_regions_promoted_usage.   You might need to add another bookkeeping variable to count regular_regions_promoted_live, tracking regular_regions_promoted_usage.

src/hotspot/share/gc/shenandoah/shenandoahEvacInfo.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2013, 2021, Oracle and/or its affiliates. All rights reserved.

For these files introduced by us, we should put an Amazon copyright notice.  See, for example, shenandoahGenerationallHeuristics.cpp.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1735411075
PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1735412641

From kdnilsen at openjdk.org  Thu Aug 29 00:09:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 29 Aug 2024 00:09:35 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging
In-Reply-To: <sz6UjzTvmoK1u3W2E0bi1Iuo-QdMzXgWVUpuaNDwxa8=.fda64ffe-a75b-4c47-ac2b-ffb9f308463c@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <sz6UjzTvmoK1u3W2E0bi1Iuo-QdMzXgWVUpuaNDwxa8=.fda64ffe-a75b-4c47-ac2b-ffb9f308463c@github.com>
Message-ID: <fQeqfy3RuixAwq8_cZKc0_xH-_J7skFwUJYcuU7i_v8=.f02d27e7-453d-48ae-9a08-008df384dece@github.com>

On Thu, 29 Aug 2024 00:03:06 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 233:
> 
>> 231:     evacInfo.set_regions_freed(free_regions);
>> 232: 
>> 233:     ShenandoahTracer().report_evacuation_info(&evacInfo);
> 
> After we chatted, I thought of one other detail that would be nice to gather in this evacInfo event: regions to be promoted in place.  Associated with this detail, would be nice to know:
> 1. how many regions
> 2. how much garbage is known to exist within these regions
> 3. how much free memory is known to exist within these regions
> Same for humongous regions promoted in place.
> 
> See humongous_regions_promoted, regular_regions_promoted_in_place, regular_regions_promoted_usage.   You might need to add another bookkeeping variable to count regular_regions_promoted_live, tracking regular_regions_promoted_usage.

for humongous_regions_promoted, less important to distinguish used and free, because that memory is "off limits" to allocators.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1735411525

From stefank at openjdk.org  Thu Aug 29 09:31:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 29 Aug 2024 09:31:21 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <BVUpj-RjVqUVV4F9IJnR-lKhg0YywsLdBDXrY65Wch8=.17bf1d03-fbdf-4cf6-8968-10b6c98b031c@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/share/cds/archiveHeapWriter.cpp line 214:

> 212:       oopDesc::set_mark(mem, markWord::prototype());
> 213:       oopDesc::release_set_klass(mem, k);
> 214:     }

The `UseCompactObjectHeaders` path calls `get_requested_narrow_klass`, while the `else` part directly uses `k`. Is one of these paths incorrect?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1735881613

From stuefe at openjdk.org  Thu Aug 29 11:40:25 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 29 Aug 2024 11:40:25 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <D6FeNJzWSRs-UNHDF0ZVnjY3fcQlBINuIuAFZQs-Wzw=.7ad105c7-0da9-4a39-9bab-cffeee7ee8f4@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/share/cds/archiveHeapWriter.hpp line 261:

> 259:   //    at mapping start, these 4G are enough. Therefore, we don't need to shift at all (shift=0).
> 260:   static constexpr int precomputed_narrow_klass_shift = 0;
> 261: 

Reviewer Note: move to ArchiveBuilder

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1736042302

From wkemper at openjdk.org  Thu Aug 29 14:24:13 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 29 Aug 2024 14:24:13 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master
Message-ID: <XTxkLG7GBl0xncd5RWK7eEW8c5V-8XoXjisqBD__x7I=.befa6b4f-2bc3-4c66-b13e-b7d6e62046b8@github.com>

Merges tag jdk-21.0.6+0

-------------

Commit messages:
 - 8280120: [IR Framework] Add attribute to @IR to enable/disable IR matching based on the architecture
 - 8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665
 - 8338286: GHA: Demote x86_32 to hotspot build only
 - 8311306: Test com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed: out of expected range
 - 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp
 - 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment
 - 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743
 - 8309894: compiler/vectorapi/VectorLogicalOpIdentityTest.java fails on SVE system with UseSVE=0
 - 8316193: jdk/jfr/event/oldobject/TestListenerLeak.java java.lang.Exception: Could not find leak
 - 8335743: jhsdb jstack cannot print some information on the waiting thread
 - ... and 10 more: https://git.openjdk.org/shenandoah-jdk21u/compare/ed77abd4...33f4d805

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=75&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/75/files
  Stats: 769 lines in 38 files changed: 473 ins; 125 del; 171 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/75.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/75/head:pull/75

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/75

From gziemski at openjdk.org  Thu Aug 29 15:15:23 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 29 Aug 2024 15:15:23 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <8RG45GnRcXMdeZO6qFIo9KdRBk9KC0kdC-4WgjEM_To=.117f02ea-8eef-4492-bb72-24eef56ef219@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

Taking Dan's feedback into account we have:

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2318039929

From gziemski at openjdk.org  Thu Aug 29 15:22:26 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 29 Aug 2024 15:22:26 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <U8DR1YBmXyq7HJcUhsXYTy3OrXfm-1cHK1eC8H2gK7c=.d410f591-47d8-496c-8743-e9db16fbf016@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

Taking Dan's feedback into account we have:

|        | MemType | MemTypeFlag | NMTCat         | NMTGroup | NMT_MemType   | NMT::MemType |
| :---:  | :---:   | :---:       | :---:          | :---:    | :---:         | :---:        |
| gerard | 1       | 0           | 0              | 0        | 2             | 3            |
| David  | 0       | 3           | 0              | 0        | 1(NMTMemType) | 2            |
| Thomas | 0       | 0           | 2              | 3        | 0             | 0            |
| Johan  | 0       | 0           | 2(NMTCategory) | 3        | 0             | 0            |
| Afshin | 0       | 3           | 0              | 0        | 0             | 2            |
| Coleen | 0       | 0           | 0              | 0        | 0             | 3            |
| Dan    | 0       | 0           | 0              | 0        | 2(NMTMemType) | 3            |
|        | 1       | 6           | 4              | 6        | 5             | 13           |

`NMT::MemType` it is.

Sorry, if your choice hasn't made it. I am surprised how wide the spectrum of choices are, this took a while to find a consensus.

Thank you everyone, who participated!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2318083570

From thomas.stuefe at gmail.com  Thu Aug 29 15:25:43 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 29 Aug 2024 17:25:43 +0200
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <8RG45GnRcXMdeZO6qFIo9KdRBk9KC0kdC-4WgjEM_To=.117f02ea-8eef-4492-bb72-24eef56ef219@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <8RG45GnRcXMdeZO6qFIo9KdRBk9KC0kdC-4WgjEM_To=.117f02ea-8eef-4492-bb72-24eef56ef219@github.com>
Message-ID: <CAA-vtUya_coQ+1GrGtDtA8JDtLje90tEuqNjAWgWzRQUmvsmqQ@mail.gmail.com>

Note that ?NMT::MemType? may lead to many uses of just ?MemType?  since a
lot of the usage will happen inside a future NMT namespace and people will
just drop the namespace. Will make it a bit more difficult to grep for,
since you need to look for both variants.

Adding an NMT namespace also opens other questions. E.g. writing - all
lower case is the standard.



On Thu 29. Aug 2024 at 17:15, Gerard Ziemski <gziemski at openjdk.org> wrote:

> On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org>
> wrote:
>
> > Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> >
> > `MEMFLAGS` implies that we can use more than one at the same time, but
> those are exclusive values, so `MemType` is much more suitable name.
> >
> > There is a bunch of other related cleanup that we can do, but I will
> leave for follow up issues such as [NMT: rename NMTUtil::flag to
> NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> Taking Dan's feedback into account we have:
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2318039929
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20240829/2e6d22fa/attachment.htm>

From gziemski at openjdk.org  Thu Aug 29 15:27:19 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 29 Aug 2024 15:27:19 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <R8H6UcyqOagsWpaG4YO0UzO41q6DYCZbu2_yl5OGfZM=.39c7a0bc-d741-4fd9-8e7d-363244eedca3@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

I'm planning on doing only the renaming of MEMFLAGS to NMT::MemType in this fix.

The renaming of parameters and variables I will leave to a followup. I will start with NMT first and per Stefan's suggestion I am thinking of using `mt` for the variables/parameters names.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2318112256

From stefank at openjdk.org  Thu Aug 29 16:20:19 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 29 Aug 2024 16:20:19 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <xJRr8Qxu8MxOX0pRmCEpH3OgWBUL6sBificrF-v84DQ=.896de1a8-3b3a-4e70-b1ae-77884cc4bad5@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

I much prefer to see MemType, but I'm warming up to NMTCategory.

- MemType: Succinct - matches part of the code (E.g. the mt in mtGC)
- MemTypeFlag: Too many words for my preference.
- NMTCat: Meuw. :)
- NMTCategory: Parts of the code call these categories, so I'm not entirely against this.
- NMTGroup: "Group" is a new name for this that currently isn't reflected at all in the code.
- NMT_MemType: I think we should try get rid of names using this style.
- NMT::MemType: The `::` makes all function declarations noisier for very little benefit, IMO.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2318273393

From duke at openjdk.org  Thu Aug 29 18:56:24 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Thu, 29 Aug 2024 18:56:24 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v2]
In-Reply-To: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
Message-ID: <Ar_rCv_A8u3tdo-Y_rNgsZTN1K0lcDwpOhvrPIFSFQI=.c66b4024-6756-490d-aea4-92ec2760651c@github.com>

> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.

Satyen Subramaniam has updated the pull request incrementally with four additional commits since the last revision:

 - Adding additional fields to ShenandoahEvacInfo
 - Updating copyright message
 - Updating .jfc files to include ShenandoahEvacInfo
 - Updating regionsImmediate to use uint

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/489/files
  - new: https://git.openjdk.org/shenandoah/pull/489/files/7b7a8c1b..e434531c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=489&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=489&range=00-01

  Stats: 75 lines in 7 files changed: 70 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/shenandoah/pull/489.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/489/head:pull/489

PR: https://git.openjdk.org/shenandoah/pull/489

From kbarrett at openjdk.org  Thu Aug 29 19:43:19 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 29 Aug 2024 19:43:19 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <xJRr8Qxu8MxOX0pRmCEpH3OgWBUL6sBificrF-v84DQ=.896de1a8-3b3a-4e70-b1ae-77884cc4bad5@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <xJRr8Qxu8MxOX0pRmCEpH3OgWBUL6sBificrF-v84DQ=.896de1a8-3b3a-4e70-b1ae-77884cc4bad5@github.com>
Message-ID: <-V2cmdnKmAbRe1i7BPDT-Q5WoGRIRiLwDaRn1jEKYxs=.7dce5659-9a70-4986-a32d-e606d3d8304b@github.com>

On Thu, 29 Aug 2024 16:17:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> I much prefer to see MemType, but I'm warming up to NMTCategory.
> 
> - MemType: Succinct - matches part of the code (E.g. the mt in mtGC)
> - MemTypeFlag: Too many words for my preference.
> - NMTCat: Meuw. :)
> - NMTCategory: Parts of the code call these categories, so I'm not entirely against this.
> - NMTGroup: "Group" is a new name for this that currently isn't reflected at all in the code.
> - NMT_MemType: I think we should try get rid of names using this style.
> - NMT::MemType: The `::` makes all function declarations noisier for very little benefit, IMO.

I continue to mostly agree with @stefank.

I think this name shouldn't be considered in isolation. There are already a
bunch of "NMT_" prefixed names. That's the common idiom for things like this
(often (maybe even usually?) without the "_"). Why are we proposing to adopt a
new style. (For just this? That would be weird. Or more broadly? That
certainly needs more discussion.)

Implementation question: Where does the NMT "namespace" come from? Presumably
the enum definition is going to be wrapped up in an AllStatic class?

A similar effect can be achieved using a `namespace`, but HotSpot avoids using
those except in some specific cases that don't apply to this type in
isolation. But if we're going to consider the broader scope (as we should),
then a namespace might well be appropriate. I'd prefer namespaces (if we were
to start using them) use snake_case style naming myself, so "nmt::MemType".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2318768006

From wkemper at openjdk.org  Thu Aug 29 19:58:15 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 29 Aug 2024 19:58:15 GMT
Subject: RFR: Merge openjdk/jdk21u-dev:master [v2]
In-Reply-To: <XTxkLG7GBl0xncd5RWK7eEW8c5V-8XoXjisqBD__x7I=.befa6b4f-2bc3-4c66-b13e-b7d6e62046b8@github.com>
References: <XTxkLG7GBl0xncd5RWK7eEW8c5V-8XoXjisqBD__x7I=.befa6b4f-2bc3-4c66-b13e-b7d6e62046b8@github.com>
Message-ID: <FhKuGo7zCfX0fPI4DitjBf9i9BueHmVWqkX3ojemdc4=.16d5dd33-6e8c-46c2-aeeb-c43a558f89a4@github.com>

> Merges tag jdk-21.0.6+0

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge remote-tracking branch 'shenandoah-jdk21u/master' into merge-jdk-21.0.6+0
 - 8280120: [IR Framework] Add attribute to @IR to enable/disable IR matching based on the architecture
   
   Backport-of: a8549b63674be433617b986f392e4ff7afef5185
 - 8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665
   
   Reviewed-by: phh, stuefe
   Backport-of: 7ab96c74e2c39f430a5c2f65a981da7314a2385b
 - 8338286: GHA: Demote x86_32 to hotspot build only
   
   Backport-of: da7311bbe37c2b9632b117d52a77c659047820b7
 - 8311306: Test com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed: out of expected range
   
   Backport-of: e1fd663f224909c09f2f6fab7ad20f7b7864b62b
 - 8322881: java/nio/file/Files/CopyMoveVariations.java fails with AccessDeniedException due to permissions of files in /tmp
   
   Backport-of: bf13a4e2819fa5bcb3e4f2281121d4e0b5535403
 - 8335150: Test LogGeneratedClassesTest.java fails on rpmbuild mock enviroment
   
   Backport-of: 403fa3760f629873258447cc9aefa09f9a27e7a4
 - 8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743
   
   Backport-of: 1fe3ada001e188754df5de00bf6804f028ad274b
 - 8309894: compiler/vectorapi/VectorLogicalOpIdentityTest.java fails on SVE system with UseSVE=0
   
   Reviewed-by: phh
   Backport-of: 60544f9088c11e4718a9cd77f21792c6ba387440
 - 8316193: jdk/jfr/event/oldobject/TestListenerLeak.java java.lang.Exception: Could not find leak
   
   Backport-of: f6be922952642f40dcf0d27b7896c9a6acdd6378
 - ... and 11 more: https://git.openjdk.org/shenandoah-jdk21u/compare/d2bfbc4e...ea63edc8

-------------

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/75/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=75&range=01
  Stats: 769 lines in 38 files changed: 473 ins; 125 del; 171 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/75.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/75/head:pull/75

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/75

From duke at openjdk.org  Thu Aug 29 20:59:17 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Thu, 29 Aug 2024 20:59:17 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v3]
In-Reply-To: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
Message-ID: <CBX6WGgh1PBwdz74CwQEa6YskJRlHvQj5m0Etqv2hK4=.320a1d72-a865-4441-a934-5d43125983ff@github.com>

> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.

Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:

  Removing extra ShenandoahEvacInfo, using size_t instead of uint

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/489/files
  - new: https://git.openjdk.org/shenandoah/pull/489/files/e434531c..ad94b8fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=489&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=489&range=01-02

  Stats: 42 lines in 5 files changed: 0 ins; 20 del; 22 mod
  Patch: https://git.openjdk.org/shenandoah/pull/489.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/489/head:pull/489

PR: https://git.openjdk.org/shenandoah/pull/489

From iklam at openjdk.org  Thu Aug 29 22:35:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 29 Aug 2024 22:35:22 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BVUpj-RjVqUVV4F9IJnR-lKhg0YywsLdBDXrY65Wch8=.17bf1d03-fbdf-4cf6-8968-10b6c98b031c@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <BVUpj-RjVqUVV4F9IJnR-lKhg0YywsLdBDXrY65Wch8=.17bf1d03-fbdf-4cf6-8968-10b6c98b031c@github.com>
Message-ID: <3M4XT4BaiowyWjJhSoFBREh9e-Be2B6L4tHVAXKw5VQ=.7647e788-8d7d-4e05-91f3-509c6fbd0d3c@github.com>

On Thu, 29 Aug 2024 09:28:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> src/hotspot/share/cds/archiveHeapWriter.cpp line 214:
> 
>> 212:       oopDesc::set_mark(mem, markWord::prototype());
>> 213:       oopDesc::release_set_klass(mem, k);
>> 214:     }
> 
> The `UseCompactObjectHeaders` path calls `get_requested_narrow_klass`, while the `else` part directly uses `k`. Is one of these paths incorrect?

This seems odd. The original code sets `Universe::objectArrayKlass()` into the object header. This is the value of this class in the current JVM lifetime.

Later, `ArchiveHeapWriter::update_header_for_requested_obj()` would change the object's klass to the "requested" address. I.e., where this class will be loaded in a future JVM lifetime when the CDS archive is loaded into memory.

It seems the same logic should be used in the `UseCompactObjectHeaders==true` case.

BTW (unrelated to this PR) the comment a few lines up is outdated and wrong:


Klass* k = Universe::objectArrayKlass(); // already relocated to point to archived klass


`k` is the value of the *actual* location of this class in the current JVM lifetime. Please ignore this comment when trying to understand this function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1737294872

From gziemski at openjdk.org  Thu Aug 29 23:35:19 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 29 Aug 2024 23:35:19 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <GYwfHuZ3xmkUtS-LNoWsLKT2UtGtgh_96y-TPSyrRvU=.a4e93d53-3e6e-4ee8-b8a1-803070b4da2f@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

After some more internal discussion `MemTag`  and `NMT::MemTag` were suggested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2319445188

From gziemski at openjdk.org  Thu Aug 29 23:46:19 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 29 Aug 2024 23:46:19 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <xJRr8Qxu8MxOX0pRmCEpH3OgWBUL6sBificrF-v84DQ=.896de1a8-3b3a-4e70-b1ae-77884cc4bad5@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <xJRr8Qxu8MxOX0pRmCEpH3OgWBUL6sBificrF-v84DQ=.896de1a8-3b3a-4e70-b1ae-77884cc4bad5@github.com>
Message-ID: <dVwE4YdpAlILvC5d2lMjxBekTDe1qquRKvzcrKaG73s=.285ebbcb-2ec5-46bb-b18c-b01ecad40ed3@github.com>

On Thu, 29 Aug 2024 16:17:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> I much prefer to see MemType, but I'm warming up to NMTCategory.
> 
> - MemType: Succinct - matches part of the code (E.g. the mt in mtGC)
> - MemTypeFlag: Too many words for my preference.
> - NMTCat: Meuw. :)
> - NMTCategory: Parts of the code call these categories, so I'm not entirely against this.
> - NMTGroup: "Group" is a new name for this that currently isn't reflected at all in the code.
> - NMT_MemType: I think we should try get rid of names using this style.
> - NMT::MemType: The `::` makes all function declarations noisier for very little benefit, IMO.

> I continue to mostly agree with @stefank.
> 
> I think this name shouldn't be considered in isolation. There are already a bunch of "NMT_" prefixed names. That's the common idiom for things like this (often (maybe even usually?) without the "_"). Why are we proposing to adopt a new style. (For just this? That would be weird. Or more broadly? That certainly needs more discussion.)

It is precisely because we already are using `NMT_TrackingStackDepth` and `NMT_TrackingLevel` (and the fact that MemType by itself was too general) that I suggested we adopt `NMT::` Yes, it would be all static class.

Why not all lower letter `nmt::`? Again, because we already use `NMT_` elsewhere.

My plan was later to switch from `NMT_` to `NMT::` for all of them. We can do `nmt::` too.

So how about `MemTag`, `nmt::MemTag` or `NMT::MemTag`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2319470647

From stuefe at openjdk.org  Fri Aug 30 07:22:21 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Aug 2024 07:22:21 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <6W5PVxmEnnjOu0CQnJOBu81Bwm-bA7CzCnn0WrkWhu4=.8fcb5baf-02bb-438f-9f86-3450a5c35860@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

I am not against moving NMT into a namespace, but we should be sure that is what we want. Introducing a new namespace is a larger scope than just renaming a single type.

For example: should the whole of NMT, including its outside-facing interface, including the enum values itself, go into the new NMT namespace? So, do we do this now:


NMT::MemFlag flag = NMT::mtGC;
NMT::MemTracker::record_malloc(p, l, flag);
NMT::MemTracker::report();

? If yes, that affects more than just the type name. 

Do we omit the namespace qualifier when inside NMT? 
When outside NMT, do we sprinkle `using NMT` around to avoid getting RSI from typing "NMT::"? That is possible, but now we get:


MemFlag flag = mtGC;
MemTracker::record_malloc(p, l, flag);


so the "NMT" prefix is gone. And we have both NMT::MemFlag and MemFlag, so people grepping for stuff need to look for both variants.

Or do you plan to just put this single enum into the namespace? As in 


namespace NMT { enum MEMFLAGS ... };

?

But having a namespace and keeping 99% of associated code outside of that namespace would be a very weird choice. And the enum values would have to be in that namespace in any case, so we wont get around having to qualify all "mtXXX" flags NMT::mtXXX.

---

None of these are hard reasons to avoid namespaces. I used namespace "metaspace" back when doing Elastic Metaspace, and I have argued for their selective use in the past. But changes like these tend to fan out a bit more than one initially thinks.

I also really prefer namespaces to be lowercase, since that is the usual way they are written ("std", "boost" etc)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2320312099

From stefank at openjdk.org  Fri Aug 30 07:30:22 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 07:30:22 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
Message-ID: <eFA0oBxF9AwGNg6r016aErf6_DSRH0Ca-gCKyYudO2o=.5a535692-d46e-4891-b16b-6d2c6ae3f39f@github.com>

On Thu, 22 Aug 2024 17:30:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove hashcode leftovers from SA
>
> src/hotspot/share/gc/serial/serialArguments.cpp line 33:
> 
>> 31: void SerialArguments::initialize_heap_flags_and_sizes() {
>> 32:   GenArguments::initialize_heap_flags_and_sizes();
>> 33:   GCForwarding::initialize_flags(MaxNewSize + MaxOldSize);
> 
> Can one use `MaxHeapSize` here?

Good catch. This is actually a bug that is causing the CDS tests to fail. The used variables have not yet been initialized at this point. I tried making the suggested change and that fixed at least one of the CDS failures.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738101667

From stefank at openjdk.org  Fri Aug 30 07:30:23 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 07:30:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
 <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
Message-ID: <BarC_59LJpof-lBzklJ8Dm8liOxnh6jr9cbCn6-NCTI=.64c466f7-c527-44e0-9f5f-2c6928e6a436@github.com>

On Thu, 22 Aug 2024 19:36:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix hash shift for 32 bit builds
>
> src/hotspot/share/gc/shared/gcForwarding.cpp line 37:
> 
>> 35:   size_t max_narrow_heap_size = right_n_bits(NumLowBitsNarrow - Shift);
>> 36:   if (UseCompactObjectHeaders && max_heap_size > max_narrow_heap_size * HeapWordSize) {
>> 37:     FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);
> 
> Maybe a log-info/warning would be nice.

Yes. This silent setting of UseCompactObjectHeaders ended up hiding why we got CDS failures. I would also suggest that we change this to FLAG_SET_ERGO.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738104783

From stuefe at openjdk.org  Fri Aug 30 07:40:23 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Aug 2024 07:40:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <JEzJGLkDHhgNGFns5-xLFV1TGH2-EkzWd568IcAO1Rg=.b48dc38e-57a9-4e4f-b512-fc86efdb77c4@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
 <JEzJGLkDHhgNGFns5-xLFV1TGH2-EkzWd568IcAO1Rg=.b48dc38e-57a9-4e4f-b512-fc86efdb77c4@github.com>
Message-ID: <YlpC3YUY4jE9Qb4Et5SqUc3q16AkDrY3b9-mXSMKzSg=.dd4d0fd4-ffac-42b8-83f5-639f3a930f8c@github.com>

On Fri, 23 Aug 2024 16:23:19 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix bit counts in GCForwarding
>
> make/Images.gmk line 135:
> 
>> 133: #
>> 134: # Param1 - VM variant (e.g., server, client, zero, ...)
>> 135: # Param2 - _nocoops, _coh, _nocoops_coh, or empty
> 
> The -XX:+UseCompactObjectHeaders ssems to incompatible withe zero vm. The zero vm build start failing while generating shared archive with +UseCompactObjectHeaders. Generation should be disabled by default for zero to don't break the build.

No, zero works with +COH, but a small change is needed. I'll post a suggestion inline.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738119614

From stuefe at openjdk.org  Fri Aug 30 07:45:19 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Aug 2024 07:45:19 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <eFA0oBxF9AwGNg6r016aErf6_DSRH0Ca-gCKyYudO2o=.5a535692-d46e-4891-b16b-6d2c6ae3f39f@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
 <eFA0oBxF9AwGNg6r016aErf6_DSRH0Ca-gCKyYudO2o=.5a535692-d46e-4891-b16b-6d2c6ae3f39f@github.com>
Message-ID: <Jwh871WmMQFGiJuKUYzWPWPJprr9n0CZRz-eJUnxTp8=.23bd8a24-d5b4-476b-973f-bf5196b4f7a1@github.com>

On Fri, 30 Aug 2024 07:25:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/serialArguments.cpp line 33:
>> 
>>> 31: void SerialArguments::initialize_heap_flags_and_sizes() {
>>> 32:   GenArguments::initialize_heap_flags_and_sizes();
>>> 33:   GCForwarding::initialize_flags(MaxNewSize + MaxOldSize);
>> 
>> Can one use `MaxHeapSize` here?
>
> Good catch. This is actually a bug that is causing the CDS tests to fail. The used variables have not yet been initialized at this point. I tried making the suggested change and that fixed at least one of the CDS failures.

Yes, one must, since MaxNewSize and MaxOldSize are still on their initial values, so way too large to allow the GC forwarding, and therefore CompactObjectHeaders get automatically disabled for SerialGC. That explains a bunch of the problems @lmesnik saw.

This fixes SerialGC for me:
Suggestion:

  GCForwarding::initialize_flags(MaxHeapSize);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738123826

From stuefe at openjdk.org  Fri Aug 30 07:45:20 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 30 Aug 2024 07:45:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v5]
In-Reply-To: <BarC_59LJpof-lBzklJ8Dm8liOxnh6jr9cbCn6-NCTI=.64c466f7-c527-44e0-9f5f-2c6928e6a436@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <TzmQRM_6QAc9tdMzNYnzSPR_nENrokTzNx2q-TPuWpw=.cfcbe6f4-4397-4c31-be73-d5a456618090@github.com>
 <-G_gdaZBT2xhZFsdyEwIqiOHpbLpiL79N6NDsW8X2BY=.bc52bd8a-21c5-40e7-a921-a5f68675200f@github.com>
 <BarC_59LJpof-lBzklJ8Dm8liOxnh6jr9cbCn6-NCTI=.64c466f7-c527-44e0-9f5f-2c6928e6a436@github.com>
Message-ID: <3QGPH52NyrDPne5EgoGx2sx9OeGRu9K72onNNwzMr2M=.8a390b3d-2e8a-470e-8bb7-1ba975070c53@github.com>

On Fri, 30 Aug 2024 07:27:45 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gcForwarding.cpp line 37:
>> 
>>> 35:   size_t max_narrow_heap_size = right_n_bits(NumLowBitsNarrow - Shift);
>>> 36:   if (UseCompactObjectHeaders && max_heap_size > max_narrow_heap_size * HeapWordSize) {
>>> 37:     FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);
>> 
>> Maybe a log-info/warning would be nice.
>
> Yes. This silent setting of UseCompactObjectHeaders ended up hiding why we got CDS failures. I would also suggest that we change this to FLAG_SET_ERGO.

Seems we run all into the same thoughts :)

I added

Suggestion:

    FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);
    warning("Compact object headers require a java heap size smaller than %zu (given: %zu). "
                 "Disabling compact object headers.", max_narrow_heap_size * HeapWordSize, max_heap_size);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738127194

From stefank at openjdk.org  Fri Aug 30 08:10:21 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 08:10:21 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v6]
In-Reply-To: <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <BGmZ04yibLn_KtPyQrA3sQv5OtMonrcDy3aN0vAj8NA=.5de6cae3-3a05-4a74-a15c-aade4176bdeb@github.com>
Message-ID: <ppEMUrlGXfCRo9oZPRt0xf_FrD3-pv5SjJh8eBoe3TU=.92c19564-443c-41d0-b047-0a9a7c6dad10@github.com>

On Thu, 22 Aug 2024 20:08:43 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing.
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded.
>>  - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops).
>>  - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all).
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will now store their length at offset 8.
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co...
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bit counts in GCForwarding

src/hotspot/share/cds/filemap.cpp line 2507:

> 2505:   }
> 2506: 
> 2507:   if (compact_headers() != UseCompactObjectHeaders) {

(Commenting here, but the comment applies to code a bit above) While debugging CDS, it would have been useful to print the value of UseCompactObjectHeaders.

Could we change the code to be:

  log_info(cds)("Archive was created with UseCompressedOops = %d, UseCompressedClassPointers = %d, UseCompactObjectHeaders = %d",
                          compressed_oops(), compressed_class_pointers(), compact_headers());

src/hotspot/share/cds/filemap.cpp line 2508:

> 2506: 
> 2507:   if (compact_headers() != UseCompactObjectHeaders) {
> 2508:     log_info(cds)("The shared archive file's UseCompactObjectHeaders setting (%s)"

Printing on the `info` level mimics what we do when there's a mismatch for compressed classes (and oops), but I wonder if that one is intentional or if it is accidentally printing to 'info' instead of 'warning'.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738164792
PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738166832

From kbarrett at openjdk.org  Fri Aug 30 09:56:20 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 30 Aug 2024 09:56:20 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <6W5PVxmEnnjOu0CQnJOBu81Bwm-bA7CzCnn0WrkWhu4=.8fcb5baf-02bb-438f-9f86-3450a5c35860@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <6W5PVxmEnnjOu0CQnJOBu81Bwm-bA7CzCnn0WrkWhu4=.8fcb5baf-02bb-438f-9f86-3450a5c35860@github.com>
Message-ID: <gxiIz9lZ9fSavdJ302Cv4a8dh4MKzJqJ5kHJZr2xMfs=.47765820-0ef5-4833-a795-b17fad492ab1@github.com>

On Fri, 30 Aug 2024 07:18:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> [...] And the enum values would have to be in that namespace in any case, so we wont get around having to qualify all "mtXXX" flags NMT::mtXXX.

We already have to solve essentially that problem because its now a scoped enum.  We currently define synonym
constants at global scope.  (C++20 provides `using MEMFLAGS;`.) Otherwise, we'd currently be needing
MEMFLAGS::mtXXX.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2320702002

From kbarrett at openjdk.org  Fri Aug 30 10:06:20 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 30 Aug 2024 10:06:20 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <xJRr8Qxu8MxOX0pRmCEpH3OgWBUL6sBificrF-v84DQ=.896de1a8-3b3a-4e70-b1ae-77884cc4bad5@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
 <xJRr8Qxu8MxOX0pRmCEpH3OgWBUL6sBificrF-v84DQ=.896de1a8-3b3a-4e70-b1ae-77884cc4bad5@github.com>
Message-ID: <5Luyt3zjZ69guwvlJVTolw6bSIT3Cv0BLdHoyfMRBOs=.f63fb696-bf3c-4a0c-bd43-211602848c0b@github.com>

On Thu, 29 Aug 2024 16:17:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
>> 
>> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
>> 
>> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)
>
> I much prefer to see MemType, but I'm warming up to NMTCategory.
> 
> - MemType: Succinct - matches part of the code (E.g. the mt in mtGC)
> - MemTypeFlag: Too many words for my preference.
> - NMTCat: Meuw. :)
> - NMTCategory: Parts of the code call these categories, so I'm not entirely against this.
> - NMTGroup: "Group" is a new name for this that currently isn't reflected at all in the code.
> - NMT_MemType: I think we should try get rid of names using this style.
> - NMT::MemType: The `::` makes all function declarations noisier for very little benefit, IMO.

> > I continue to mostly agree with @stefank.
> > I think this name shouldn't be considered in isolation. There are already a bunch of "NMT_" prefixed names. That's the common idiom for things like this (often (maybe even usually?) without the "_"). Why are we proposing to adopt a new style. (For just this? That would be weird. Or more broadly? That certainly needs more discussion.)
> 
> It is precisely because we already are using `NMT_TrackingStackDepth` and `NMT_TrackingLevel` (and the fact that MemType by itself was too general) that I suggested we adopt `NMT::` Yes, it would be all static class.
> 
> Why not all lower letter `nmt::`? Again, because we already use `NMT_` elsewhere.
> 
> My plan was later to switch from `NMT_` to `NMT::` for all of them. We can do `nmt::` too.

An `NMT_` => `NMT::` change requires using a namespace.  An allstatic class is closed for extension, and some of these
definitions are in different files.  The only way to use an allstatic class instead of a namespace is to go the same route as
currently used by the "os" class (over my dead body, and probably @tstuefe too).

That previously unstated plan also supports my claim that we shouldn't be considering this one type's name in isolation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2320728486

From stefank at openjdk.org  Fri Aug 30 11:10:23 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 11:10:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
Message-ID: <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>

On Thu, 22 Aug 2024 17:12:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove hashcode leftovers from SA
>
> src/hotspot/share/gc/serial/defNewGeneration.cpp line 707:
> 
>> 705:       } else if (obj->is_forwarded()) {
>> 706:         // To restore the klass-bits in the header.
>> 707:         obj->forward_safe_init_mark();
> 
> I wonder if not modifying successful-forwarded objs is cleaner. Sth like:
> 
> 
> reset_self_forwarded_in_space(space) {
>   cur = space->bottom();
>   top = space->top();
> 
>   while (cur < top) {
>     obj = cast_to_oop(cur);
> 
>     if (obj->is_self_forwarded()) {
>       obj->unset_self_forwarded();
>       obj_size = obj->size();
>     } else {
>       assert(obj->is_forwarded(), "inv");
>       obj_size = obj->forwardee()->size();
>     }
> 
>     cur += obj_size;
>   }
> }
> 
> reset_self_forwarded_in_space(eden());
> reset_self_forwarded_in_space(from());

I was thinking the same, but there's a problem with that. If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. Then when the Full GC scans these regions with dead objects it will mistakenly think that they have been marked alive because `is_forwarded() == is_gc_marked()`. The code in `phase2_calculate_new_addr` will then break when it looks for `is_gc_marked` objects.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738433303

From stefank at openjdk.org  Fri Aug 30 11:18:20 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 30 Aug 2024 11:18:20 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
 <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>
Message-ID: <VGJOzveV1b0KxnQ_lSugtMP7boOK5TPmiYT7QXgcCoM=.780e110d-491c-4bbc-9ee7-a7db237ee9dc@github.com>

On Fri, 30 Aug 2024 11:07:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/defNewGeneration.cpp line 707:
>> 
>>> 705:       } else if (obj->is_forwarded()) {
>>> 706:         // To restore the klass-bits in the header.
>>> 707:         obj->forward_safe_init_mark();
>> 
>> I wonder if not modifying successful-forwarded objs is cleaner. Sth like:
>> 
>> 
>> reset_self_forwarded_in_space(space) {
>>   cur = space->bottom();
>>   top = space->top();
>> 
>>   while (cur < top) {
>>     obj = cast_to_oop(cur);
>> 
>>     if (obj->is_self_forwarded()) {
>>       obj->unset_self_forwarded();
>>       obj_size = obj->size();
>>     } else {
>>       assert(obj->is_forwarded(), "inv");
>>       obj_size = obj->forwardee()->size();
>>     }
>> 
>>     cur += obj_size;
>>   }
>> }
>> 
>> reset_self_forwarded_in_space(eden());
>> reset_self_forwarded_in_space(from());
>
> I was thinking the same, but there's a problem with that. If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. Then when the Full GC scans these regions with dead objects it will mistakenly think that they have been marked alive because `is_forwarded() == is_gc_marked()`. The code in `phase2_calculate_new_addr` will then break when it looks for `is_gc_marked` objects.

FWIW, the ParallelGC does something very similar to what you propose, except that it walks bitmaps instead of paring the space to find the self-forwarded objects. It then has a check inside object_iterate to make sure that it doesn't expose the dead objects (in eden and the from space) to heap dumpers and histogram printers.

Because of the the code above, the SerialGC clears away the information about what objects are dead in eden and the from space, so heap dumpers and histogram printers will include these dead objects. We might want to fix that as a future RFE.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1738444174

From wkemper at openjdk.org  Fri Aug 30 14:17:26 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 30 Aug 2024 14:17:26 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <W0fkZfcnC8xgwSQaX32_BqwQI3t59yZl-11eFz3oEag=.dcc1f577-fa85-4ba3-a2a9-ac70cb5adf20@github.com>

Merges tag jdk-24+13

-------------

Commit messages:
 - 8338678: Erroneous parameterized type represented as <any>
 - 8324859: Improve error recovery
 - 8327381: Refactor type-improving transformations in BoolNode::Ideal to BoolNode::Value
 - 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property
 - 8335120: assert(!target->can_be_statically_bound() || target == cha_monomorphic_target) failed
 - 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource
 - 8338888: SystemDictionary::class_name_symbol has incorrect length check
 - 8339126: JNI exception pending in Inflater.c
 - 8258483: [TESTBUG] gtest CollectorPolicy.young_scaled_initial_ergo_vm fails if heap is too small
 - 8339030: frame::print_value_on(outputStream* st, JavaThread *thread) doesn't need thread argument
 - ... and 128 more: https://git.openjdk.org/shenandoah/compare/4c344335...ff59532d

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah&pr=490&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah/pull/490/files
  Stats: 22019 lines in 669 files changed: 15139 ins; 4019 del; 2861 mod
  Patch: https://git.openjdk.org/shenandoah/pull/490.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/490/head:pull/490

PR: https://git.openjdk.org/shenandoah/pull/490

From kdnilsen at openjdk.org  Fri Aug 30 15:03:20 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 30 Aug 2024 15:03:20 GMT
Subject: RFR: 8338534: GenShen: Handle alloc failure differently when immediate
 garbage is pending
Message-ID: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>

Several changes are implemented here:

1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.

-------------

Commit messages:
 - Fix whitespace
 - Experiment with white space jcheck
 - Whitespace
 - Do not cancel GC on allocation failure if immediate garbage is adequate
 - Improve comments regarding when we can recycle trashed regions
 - Do not clear alloc-failure flag after cleanup early
 - Notify waiting allocators after cleanup of immediate garbage
 - Do not log_status() for free set after cleanup early
 - Reorder concurrent cleanup following final mark
 - Merge branch 'openjdk:master' into master
 - ... and 19 more: https://git.openjdk.org/shenandoah/compare/7cc63abc...f11a3c81

Changes: https://git.openjdk.org/shenandoah/pull/479/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338534
  Stats: 73 lines in 8 files changed: 48 ins; 6 del; 19 mod
  Patch: https://git.openjdk.org/shenandoah/pull/479.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/479/head:pull/479

PR: https://git.openjdk.org/shenandoah/pull/479

From kdnilsen at openjdk.org  Fri Aug 30 15:03:20 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 30 Aug 2024 15:03:20 GMT
Subject: RFR: 8338534: GenShen: Handle alloc failure differently when
 immediate garbage is pending
In-Reply-To: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
References: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
Message-ID: <MYG7vU4GT9XxbI0v7ej7H9jKdMA6V1J-gwZUPOWhyGw=.e38d708c-0192-478f-8369-15b3135550d1@github.com>

On Wed, 21 Aug 2024 14:48:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Several changes are implemented here:
> 
> 1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
> 2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
> 3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.

BTW, I can't figure out what jcheck whitespace is complaining about.  I think it is reporting the wrong line number.  jcheck on my local copy does not report a whitespace problem.

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/479#issuecomment-2302574316

From ysr at openjdk.org  Fri Aug 30 15:03:21 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 30 Aug 2024 15:03:21 GMT
Subject: RFR: 8338534: GenShen: Handle alloc failure differently when
 immediate garbage is pending
In-Reply-To: <MYG7vU4GT9XxbI0v7ej7H9jKdMA6V1J-gwZUPOWhyGw=.e38d708c-0192-478f-8369-15b3135550d1@github.com>
References: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
 <MYG7vU4GT9XxbI0v7ej7H9jKdMA6V1J-gwZUPOWhyGw=.e38d708c-0192-478f-8369-15b3135550d1@github.com>
Message-ID: <igb_xPgGxsJjeiZFEaN4oxuM-lIXngcwNloJU6aBQ4E=.c6d53ffa-eaa1-46c2-bd35-0b2191115205@github.com>

On Wed, 21 Aug 2024 17:07:53 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> BTW, I can't figure out what jcheck whitespace is complaining about. I think it is reporting the wrong line number. jcheck on my local copy does not report a whitespace problem.

Yes, for some reason `git jcheck -s` doesn't find it.

However, there is indeed whitespace (in fact, 2 as in the error message) in that file on an otherwise blank line. However, the line number is indeed incorrect as you stated. It should be line 2467.


diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
index cbcd22c053f..342c023d180 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
@@ -2464,7 +2464,7 @@ void ShenandoahHeap::rebuild_free_set(bool concurrent) {
   _free_set->prepare_to_rebuild(young_cset_regions, old_cset_regions, first_old_region, last_old_region, old_region_count);
   size_t anticipated_immediate_garbage = (old_cset_regions + young_cset_regions) * ShenandoahHeapRegion::region_size_words();
   control_thread()->anticipate_immediate_garbage(anticipated_immediate_garbage);
-  
+
   // If there are no old regions, first_old_region will be greater than last_old_region
   assert((first_old_region > last_old_region) ||
          ((last_old_region + 1 - first_old_region >= old_region_count) &&

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/479#issuecomment-2319141408

From ysr at openjdk.org  Fri Aug 30 15:03:21 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 30 Aug 2024 15:03:21 GMT
Subject: RFR: 8338534: GenShen: Handle alloc failure differently when
 immediate garbage is pending
In-Reply-To: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
References: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
Message-ID: <oeCrjtvCqPMy7de9yEtAkoTPbL-Nli3uPnCsuvyzuUg=.ce8eeed7-e09e-4070-9d64-32f78a3aad33@github.com>

On Wed, 21 Aug 2024 14:48:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Several changes are implemented here:
> 
> 1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
> 2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
> 3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.

% find . -type f -name "*pp" | xargs grep -n " $" 
./src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:2467:

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/479#issuecomment-2319161564

From gziemski at openjdk.org  Fri Aug 30 16:51:20 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 30 Aug 2024 16:51:20 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <3MBOQciBs-c6nqI3dWH7w-bWkqlPDdSH2ztkIu3Den0=.18a52372-c679-4137-a570-ea2fe4312699@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

Assuming for a second that we agree on the name of new type ( for now `MemTag`). Are we sure we want to combine that rename `MEMFLAGS` --> `MemTag` with changing the names of parameters and variables around this change at the same time?

This is exactly what I initially did, but after I took a 2nd look I got worried about how big it looked. Just for a reference these are my changes I am talking about, which I abandoned: https://openjdk.github.io/cr/?repo=jdk&pr=20472&range=00

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2321955298

From coleenp at openjdk.org  Fri Aug 30 17:01:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 30 Aug 2024 17:01:21 GMT
Subject: RFR: 8337563: NMT: rename MEMFLAGS to MemFlag
In-Reply-To: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
References: <XT8-0JId5lEtWVsceJGTY7lDet5gWNONy1A9rUigZ0g=.be0db307-977f-4bad-900c-1f21ee5257ab@github.com>
Message-ID: <76joSrzfa19YzNpoHpOkmBliI6HwsXz6uzWlk2hleXM=.773eac71-54ed-4aa4-a577-0b3f53717527@github.com>

On Wed, 7 Aug 2024 17:13:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Please review this cleanup, where we rename `MEMFLAGS` to `MemType`.
> 
> `MEMFLAGS` implies that we can use more than one at the same time, but those are exclusive values, so `MemType` is much more suitable name.
> 
> There is a bunch of other related cleanup that we can do, but I will leave for follow up issues such as [NMT: rename NMTUtil::flag to NMTUtil::type](https://bugs.openjdk.org/browse/JDK-8337836)

Yes, I think people want the name of the new type, and variables that are declared with this type changed in one PR.  Just looking through a bit of this webrev, this looks fine.  This isn't very hard to review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20497#issuecomment-2321978633

From kdnilsen at openjdk.org  Fri Aug 30 18:04:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 30 Aug 2024 18:04:39 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v3]
In-Reply-To: <CBX6WGgh1PBwdz74CwQEa6YskJRlHvQj5m0Etqv2hK4=.320a1d72-a865-4441-a934-5d43125983ff@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <CBX6WGgh1PBwdz74CwQEa6YskJRlHvQj5m0Etqv2hK4=.320a1d72-a865-4441-a934-5d43125983ff@github.com>
Message-ID: <hwupTINNgu2J-bNQpDoBIQRFRgDj34wTaSRMEM-4cQo=.b0ccf5de-3f1c-4db9-945c-349e65f80d6e@github.com>

On Thu, 29 Aug 2024 20:59:17 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

>> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.
>
> Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing extra ShenandoahEvacInfo, using size_t instead of uint

Thanks for this code.  Let's get at least one other review before we integrate.

-------------

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/489#pullrequestreview-2273203543

From kdnilsen at openjdk.org  Fri Aug 30 18:04:39 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 30 Aug 2024 18:04:39 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v3]
In-Reply-To: <fQeqfy3RuixAwq8_cZKc0_xH-_J7skFwUJYcuU7i_v8=.f02d27e7-453d-48ae-9a08-008df384dece@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <sz6UjzTvmoK1u3W2E0bi1Iuo-QdMzXgWVUpuaNDwxa8=.fda64ffe-a75b-4c47-ac2b-ffb9f308463c@github.com>
 <fQeqfy3RuixAwq8_cZKc0_xH-_J7skFwUJYcuU7i_v8=.f02d27e7-453d-48ae-9a08-008df384dece@github.com>
Message-ID: <NLy0pQVrYgmtJHMdVvpUASVhXf0GvEsDXdyVtPnDfRQ=.e4774758-c270-4788-b229-680287ecf181@github.com>

On Thu, 29 Aug 2024 00:03:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp line 233:
>> 
>>> 231:     evacInfo.set_regions_freed(free_regions);
>>> 232: 
>>> 233:     ShenandoahTracer().report_evacuation_info(&evacInfo);
>> 
>> After we chatted, I thought of one other detail that would be nice to gather in this evacInfo event: regions to be promoted in place.  Associated with this detail, would be nice to know:
>> 1. how many regions
>> 2. how much garbage is known to exist within these regions
>> 3. how much free memory is known to exist within these regions
>> Same for humongous regions promoted in place.
>> 
>> See humongous_regions_promoted, regular_regions_promoted_in_place, regular_regions_promoted_usage.   You might need to add another bookkeeping variable to count regular_regions_promoted_live, tracking regular_regions_promoted_usage.
>
> for humongous_regions_promoted, less important to distinguish used and free, because that memory is "off limits" to allocators.

Looks good.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1739210062

From kdnilsen at openjdk.org  Fri Aug 30 18:04:40 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 30 Aug 2024 18:04:40 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v3]
In-Reply-To: <sz6UjzTvmoK1u3W2E0bi1Iuo-QdMzXgWVUpuaNDwxa8=.fda64ffe-a75b-4c47-ac2b-ffb9f308463c@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <sz6UjzTvmoK1u3W2E0bi1Iuo-QdMzXgWVUpuaNDwxa8=.fda64ffe-a75b-4c47-ac2b-ffb9f308463c@github.com>
Message-ID: <zDcU6MjJw12EjdqQ5i6p-Whrn0MWPY6wNlnsTqsEcVE=.9417d40f-d98f-4a2a-873e-e1a47acd70bd@github.com>

On Thu, 29 Aug 2024 00:06:30 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing extra ShenandoahEvacInfo, using size_t instead of uint
>
> src/hotspot/share/gc/shenandoah/shenandoahEvacInfo.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2013, 2021, Oracle and/or its affiliates. All rights reserved.
> 
> For these files introduced by us, we should put an Amazon copyright notice.  See, for example, shenandoahGenerationallHeuristics.cpp.

Thanks for fixing this

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1739209988

From ayang at openjdk.org  Fri Aug 30 18:13:23 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 30 Aug 2024 18:13:23 GMT
Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers
 (Experimental) [v3]
In-Reply-To: <VGJOzveV1b0KxnQ_lSugtMP7boOK5TPmiYT7QXgcCoM=.780e110d-491c-4bbc-9ee7-a7db237ee9dc@github.com>
References: <TMFZyyalInj2UamEkFjV62vkXfP3zRF_fZq1NR4Msw4=.abb047d2-8eaa-447c-854e-ff5fe40a7169@github.com>
 <bKtmNAMLqRlWTG9MBcosxeh2rYNK_yx_gkh_qbNKt6s=.e23c8a75-0072-4c9f-8d8e-7db14826fded@github.com>
 <ySywujYrcJzmYZtj5oflhcQZbzxPv78dm29gJ5B1fqE=.31b98908-bc0f-48af-b67a-75e7351d1b74@github.com>
 <CjcHSbAikUEXe-wpmu-p2od4z6IN-QC54DCKL5hSaZY=.85532a31-e607-447b-8cea-80e97024f994@github.com>
 <VGJOzveV1b0KxnQ_lSugtMP7boOK5TPmiYT7QXgcCoM=.780e110d-491c-4bbc-9ee7-a7db237ee9dc@github.com>
Message-ID: <LwLTyRUwTUB8Kph7ngHJExHVwAdJSvimoXRsh6A2HcM=.1c03eb16-4e7a-42ac-bbe1-425f4f7fed75@github.com>

On Fri, 30 Aug 2024 11:15:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I was thinking the same, but there's a problem with that. If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. Then when the Full GC scans these regions with dead objects it will mistakenly think that they have been marked alive because `is_forwarded() == is_gc_marked()`. The code in `phase2_calculate_new_addr` will then break when it looks for `is_gc_marked` objects.
>
> FWIW, the ParallelGC does something very similar to what you propose, except that it walks bitmaps instead of paring the space to find the self-forwarded objects. It then has a check inside object_iterate to make sure that it doesn't expose the dead objects (in eden and the from space) to heap dumpers and histogram printers.
> 
> Because of the the code above, the SerialGC clears away the information about what objects are dead in eden and the from space, so heap dumpers and histogram printers will include these dead objects. We might want to fix that as a future RFE.

> If we get a promotion failure in the young gen, we are leaving the dead objects marked as forwarded. 

True; need to do sth like `obj->init_mark();` for the non-self-forwarded case. The postcondition is that no forwarded objs in eden/from.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1739218189

From wkemper at openjdk.org  Fri Aug 30 18:37:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 30 Aug 2024 18:37:35 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v3]
In-Reply-To: <CBX6WGgh1PBwdz74CwQEa6YskJRlHvQj5m0Etqv2hK4=.320a1d72-a865-4441-a934-5d43125983ff@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <CBX6WGgh1PBwdz74CwQEa6YskJRlHvQj5m0Etqv2hK4=.320a1d72-a865-4441-a934-5d43125983ff@github.com>
Message-ID: <jMZICzkDMa-ik8MfqcuHsefAOP2YmwmFATf_GLdlIHA=.1f1b4eff-aee9-4bc2-8ea4-4bffdcebeb85@github.com>

On Thu, 29 Aug 2024 20:59:17 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

>> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.
>
> Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing extra ShenandoahEvacInfo, using size_t instead of uint

Minor nits about missing newlines and suggest comment saying that all size values are words or bytes.

src/hotspot/share/gc/shenandoah/shenandoahEvacInfo.hpp line 30:

> 28: #include "memory/allocation.hpp"
> 29: 
> 30: class ShenandoahEvacInfo : public StackObj {

Should we have a comment here saying that all size values are bytes or words?

src/hotspot/share/gc/shenandoah/shenandoahTrace.cpp line 54:

> 52:     e.commit();
> 53:   }
> 54: }

Missing newline.

src/hotspot/share/gc/shenandoah/shenandoahTrace.hpp line 42:

> 40: };
> 41: 
> 42: #endif

Missing newline.

-------------

Changes requested by wkemper (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/489#pullrequestreview-2273259903
PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1739244805
PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1739236779
PR Review Comment: https://git.openjdk.org/shenandoah/pull/489#discussion_r1739240500

From duke at openjdk.org  Fri Aug 30 19:28:55 2024
From: duke at openjdk.org (Satyen Subramaniam)
Date: Fri, 30 Aug 2024 19:28:55 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v4]
In-Reply-To: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
Message-ID: <VfCS_Synl-Le8jmiaAqCJkTWIO9rZmBIlRAOMFrVdRw=.04b30d8a-398b-4a41-8457-d3aa26dbc004@github.com>

> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.

Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:

  Formatting and ShenandoahEvacInfo comment

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/489/files
  - new: https://git.openjdk.org/shenandoah/pull/489/files/ad94b8fd..1fc6ef01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=489&range=03
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=489&range=02-03

  Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah/pull/489.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/489/head:pull/489

PR: https://git.openjdk.org/shenandoah/pull/489

From wkemper at openjdk.org  Fri Aug 30 19:59:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 30 Aug 2024 19:59:38 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v4]
In-Reply-To: <VfCS_Synl-Le8jmiaAqCJkTWIO9rZmBIlRAOMFrVdRw=.04b30d8a-398b-4a41-8457-d3aa26dbc004@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <VfCS_Synl-Le8jmiaAqCJkTWIO9rZmBIlRAOMFrVdRw=.04b30d8a-398b-4a41-8457-d3aa26dbc004@github.com>
Message-ID: <ai4StX8FW4jm9DA6OS-yXfVwiDdUVK0QPwJDDAfOins=.43d4732a-eafe-485e-9041-3df7cd725971@github.com>

On Fri, 30 Aug 2024 19:28:55 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

>> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.
>
> Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting and ShenandoahEvacInfo comment

Thank you!

-------------

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/shenandoah/pull/489#pullrequestreview-2273410317

From wkemper at openjdk.org  Fri Aug 30 21:10:54 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 30 Aug 2024 21:10:54 GMT
Subject: Integrated: Merge openjdk/jdk21u-dev:master
In-Reply-To: <XTxkLG7GBl0xncd5RWK7eEW8c5V-8XoXjisqBD__x7I=.befa6b4f-2bc3-4c66-b13e-b7d6e62046b8@github.com>
References: <XTxkLG7GBl0xncd5RWK7eEW8c5V-8XoXjisqBD__x7I=.befa6b4f-2bc3-4c66-b13e-b7d6e62046b8@github.com>
Message-ID: <3HpKoCzAfR6vribe4V9rGN-K7pB8KtW0RE7HQ8tjx0A=.9bf566ec-28c1-4eda-9849-62ba94989860@github.com>

On Thu, 29 Aug 2024 14:19:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.6+0

This pull request has now been integrated.

Changeset: b769373e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/b769373edd1e4bc373c84a5151725ef41ee06eeb
Stats:     769 lines in 38 files changed: 473 ins; 125 del; 171 mod

Merge

-------------

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/75

From wkemper at openjdk.org  Fri Aug 30 21:11:43 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 30 Aug 2024 21:11:43 GMT
Subject: RFR: Merge openjdk/jdk:master
In-Reply-To: <W0fkZfcnC8xgwSQaX32_BqwQI3t59yZl-11eFz3oEag=.dcc1f577-fa85-4ba3-a2a9-ac70cb5adf20@github.com>
References: <W0fkZfcnC8xgwSQaX32_BqwQI3t59yZl-11eFz3oEag=.dcc1f577-fa85-4ba3-a2a9-ac70cb5adf20@github.com>
Message-ID: <X7k9gp8Q3JxRJ13k3g-82NHQLcnTbKRCfr2tPwH2FPs=.f65b1f59-7cd5-4bf9-8b07-b57e71fbff79@github.com>

On Fri, 30 Aug 2024 14:11:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+13

Superseded by https://github.com/openjdk/shenandoah/pull/483

-------------

PR Comment: https://git.openjdk.org/shenandoah/pull/490#issuecomment-2322339290

From wkemper at openjdk.org  Fri Aug 30 21:11:44 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 30 Aug 2024 21:11:44 GMT
Subject: Withdrawn: Merge openjdk/jdk:master
In-Reply-To: <W0fkZfcnC8xgwSQaX32_BqwQI3t59yZl-11eFz3oEag=.dcc1f577-fa85-4ba3-a2a9-ac70cb5adf20@github.com>
References: <W0fkZfcnC8xgwSQaX32_BqwQI3t59yZl-11eFz3oEag=.dcc1f577-fa85-4ba3-a2a9-ac70cb5adf20@github.com>
Message-ID: <spVV_LE_Sp_ThhyOILnFFHl1tvJlUlHbII9hbS0x9Wg=.6eb2eb80-ca25-4c67-818d-3a92cf419cc2@github.com>

On Fri, 30 Aug 2024 14:11:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+13

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/shenandoah/pull/490

From wkemper at openjdk.org  Fri Aug 30 22:30:27 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 30 Aug 2024 22:30:27 GMT
Subject: RFR: Merge openjdk/jdk:master [v8]
In-Reply-To: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
References: <SCP1LsF3csnYVFltdHsYkeTRFauWYtyziukewFh7bio=.f20164ac-6ecb-4a84-bfa4-45969db4145e@github.com>
Message-ID: <xI8kOvsvL7Zvb-za3-r-zxYHnzXc7fzSUftacr4t3qo=.7dbc2225-a00f-4bf4-852b-ed1999746813@github.com>

> Merges tag jdk-24+12

William Kemper has updated the pull request incrementally with 43 additional commits since the last revision:

 - Merge tag 'jdk-24+13' into merge-jdk-24+12
   
   Added tag jdk-24+13 for changeset ff59532d
 - 8338678: Erroneous parameterized type represented as <any>
   
   Reviewed-by: vromero
 - 8324859: Improve error recovery
   
   Reviewed-by: mcimadamore
 - 8327381: Refactor type-improving transformations in BoolNode::Ideal to BoolNode::Value
   
   Reviewed-by: chagedorn, thartmann, jkarthikeyan, epeter
 - 8336873: BasicSplitPaneDivider:oneTouchExpandableChanged() should mention that implementation depends on SplitPane.supportsOneTouchButtons property
   
   Reviewed-by: prr, abhiscxk
 - 8335120: assert(!target->can_be_statically_bound() || target == cha_monomorphic_target) failed
   
   Reviewed-by: kvn, vlivanov
 - 8338716: Re-visit "interrupt handling" in jdk.internal.loader.Resource
   
   Reviewed-by: alanb
 - 8338888: SystemDictionary::class_name_symbol has incorrect length check
   
   Reviewed-by: stuefe, kbarrett, coleenp
 - 8339126: JNI exception pending in Inflater.c
   
   Reviewed-by: lancea, vtewari, jpai, naoto
 - 8258483: [TESTBUG] gtest CollectorPolicy.young_scaled_initial_ergo_vm fails if heap is too small
   
   Reviewed-by: ayang
 - ... and 33 more: https://git.openjdk.org/shenandoah/compare/61ef37a5...2751b362

-------------

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/483/files
  - new: https://git.openjdk.org/shenandoah/pull/483/files/61ef37a5..2751b362

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=07
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=483&range=06-07

  Stats: 4456 lines in 117 files changed: 3466 ins; 488 del; 502 mod
  Patch: https://git.openjdk.org/shenandoah/pull/483.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/483/head:pull/483

PR: https://git.openjdk.org/shenandoah/pull/483

From ysr at openjdk.org  Fri Aug 30 22:57:42 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 30 Aug 2024 22:57:42 GMT
Subject: RFR: 8339197: GenShen: Adding Generation and Evacuation
 Information JFR Logging [v4]
In-Reply-To: <VfCS_Synl-Le8jmiaAqCJkTWIO9rZmBIlRAOMFrVdRw=.04b30d8a-398b-4a41-8457-d3aa26dbc004@github.com>
References: <BEJelx66YJmCPpWF74x7zX3l-Y9Xu4I4F5qRQptKbQU=.9b86ad21-794f-4fc6-911e-814b517db7a6@github.com>
 <VfCS_Synl-Le8jmiaAqCJkTWIO9rZmBIlRAOMFrVdRw=.04b30d8a-398b-4a41-8457-d3aa26dbc004@github.com>
Message-ID: <AJCMdjt0L_Ono2qyO3GMt0sLTFumVamtYGmnZZl-9nU=.a2d3f88f-7205-4eeb-b00e-685ef405b45e@github.com>

On Fri, 30 Aug 2024 19:28:55 GMT, Satyen Subramaniam <duke at openjdk.org> wrote:

>> Adding `ShenandoahEvacInfo` event and modifying existing logging for Concurrent Reset and Final Roots events to include generation for Generational Shenandoah GC.
>
> Satyen Subramaniam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting and ShenandoahEvacInfo comment

Marked as reviewed by ysr (Committer).

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/489#pullrequestreview-2273609191

From ysr at openjdk.org  Fri Aug 30 23:29:52 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 30 Aug 2024 23:29:52 GMT
Subject: RFR: 8338534: GenShen: Handle alloc failure differently when
 immediate garbage is pending
In-Reply-To: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
References: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
Message-ID: <LSilNZBAYWDmgIEsVJgzW0SpziGSwm-gikunMRuqFbc=.6ec89686-800f-4037-b296-2db7b7ac39a4@github.com>

On Wed, 21 Aug 2024 14:48:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Several changes are implemented here:
> 1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
> 2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
> 3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.

As you suggested offline, I agree that it might make sense to do (1) separately, and then do (2+3).

Left a few comments mainly on (2+3), but I'm still missing the solution to the problem described in the ticket. I'll chat with you offline to get clarity.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1071:

> 1069:   ShenandoahHeap* heap = ShenandoahHeap::heap();
> 1070:   if (heap->free_set()->recycle_trash()) {
> 1071:     heap->control_thread()->notify_alloc_failure_waiters(false);

Can you motivate this notification? As far as I can tell, all waiters will react to the notification by waking up, finding that the variables are still set, and consequently go back to wait.

I am sure I am missing something here, or you didn't make an intended change to allow waiters to retry allocation after waking up and go back to sleep if they didn't succeed?

A documentation comment would definitely help cross the t's and dot the i's for the reader.

src/hotspot/share/gc/shenandoah/shenandoahController.cpp line 56:

> 54: }
> 55: 
> 56: void ShenandoahController::anticipate_immediate_garbage(size_t anticipated_immediate_garbage) {

Suggested rename see further above. `set_<field>`.

src/hotspot/share/gc/shenandoah/shenandoahController.cpp line 104:

> 102:     _alloc_failure_gc.unset();
> 103:     _humongous_alloc_failure_gc.unset();
> 104:   }

For good hygiene, I'd move the variable value changes into the monitor which is held when waiting or notifying. I realize this doesn't matter for correctness, but makes debugging easier.

Further, if you protect the updates and reads of the variables with the lock, you don't need to do the extra atomic ops.

You'd need to examine all sets/gets and waits/notifys to make sure this works, but I am guessing it will, and it'll also improve performance.

However, that can be done in a separate effort, if you prefer, for which I'm happy to file a separate ticket for that investigation/change.

src/hotspot/share/gc/shenandoah/shenandoahController.hpp line 76:

> 74:   void handle_alloc_failure(ShenandoahAllocRequest& req, bool block);
> 75: 
> 76:   void anticipate_immediate_garbage(size_t anticipated_immediate_garbage_words);

a 1-line documentation comment on the role of the field (and that the method sets it -- why not simply call it `set_foo(value)` for field `_foo` ? I realize you want readers to get the most recently written value, hence the atomic store & load.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1243:

> 1241:   }
> 1242:   return true;
> 1243: }

If I understood your intent, I think this has a bug because it always returns true here. I believe you just wanted:


    if (r->is_trash()) {
      r->recycle();
      return true;
    }
   return false;

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1246:

> 1244: 
> 1245: bool ShenandoahFreeSet::recycle_trash() {
> 1246:   bool result = false;

I'd take the opportunity to do some counting verification here.


int n_trash_regions = 0;


Read on ...

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1267:

> 1265:     while (idx < count && os::javaTimeNanos() < deadline) {
> 1266:       if (try_recycle_trashed(_trash_regions[idx++])) {
> 1267:         result = true;

...

   n_trash_regions++;

...

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1272:

> 1270:   }
> 1271:   _heap->control_thread()->anticipate_immediate_garbage((size_t) 0);
> 1272:   return result;

...
``` 
clear_anticipated_immediate_garage(n_trash_regions*HeapRegionSize);
   return n_trash_regions > 0;

with

void ...::clear_anticipated_immediate_garbage(size_t aig) {
    assert(_anticipated_immediate_garbage == aig, "Mismatch?");
    _anticipated_immediate_garbage = 0;
}


Is this an intended invariant? I think it is, but don't understand enough of the details to be certain.

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 756:

> 754:     size_t first_old, last_old, num_old;
> 755:     heap->free_set()->prepare_to_rebuild(young_cset_regions, old_cset_regions, first_old, last_old, num_old);
> 756:     size_t anticipated_immediate_garbage = (old_cset_regions + young_cset_regions) * ShenandoahHeapRegion::region_size_words();

This makes it sound like old_cset_regions & young_cset_regions hold all regions that will be part of `immediate garbage` -- which indeed is the case. The name `prepare_to_rebuild()` does not give one much clue as to the fact that that's happening when we return from the call, and the API spec of the method does not explicitly specify it. One needs to read into the code of the method `find_regions_with_alloc_capacity()` to realize that this is what is happening.

In summary, firstly, I feel some of these methods are in need of tighter header file documentation of post-conditions that callers are relying on and, secondly, I feel given the extremely fat APIs (lots of reference variables that are modified by these methods) that some amount of refactoring is needed in the longer term. The refactoring should be a separate effort, but in the shorter term I think the API/spec documentation of `prepare_to_rebuild` and `find_regions_with_alloc_capacity` could be improved.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 2467:

> 2465:   size_t anticipated_immediate_garbage = (old_cset_regions + young_cset_regions) * ShenandoahHeapRegion::region_size_words();
> 2466:   control_thread()->anticipate_immediate_garbage(anticipated_immediate_garbage);
> 2467:   

This is the line that has two whitespaces, vide the jcheck whitespace error above.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 478:

> 476:     heap->free_set()->prepare_to_rebuild(cset_young_regions, cset_old_regions, first_old, last_old, num_old);
> 477:     size_t anticipated_immediate_garbage = (cset_young_regions + cset_old_regions) * ShenandoahHeapRegion::region_size_words();
> 478:     heap->control_thread()->anticipate_immediate_garbage(anticipated_immediate_garbage);

suggest `set_<foo>` for changing field value `<foo>`.

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/479#pullrequestreview-2270677989
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737591476
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737612723
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737584419
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737559164
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737618171
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737602478
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737603682
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737609657
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1739499541
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737601762
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1739511544

From ysr at openjdk.org  Fri Aug 30 23:29:52 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 30 Aug 2024 23:29:52 GMT
Subject: RFR: 8338534: GenShen: Handle alloc failure differently when
 immediate garbage is pending
In-Reply-To: <LSilNZBAYWDmgIEsVJgzW0SpziGSwm-gikunMRuqFbc=.6ec89686-800f-4037-b296-2db7b7ac39a4@github.com>
References: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
 <LSilNZBAYWDmgIEsVJgzW0SpziGSwm-gikunMRuqFbc=.6ec89686-800f-4037-b296-2db7b7ac39a4@github.com>
Message-ID: <EfR1Kjb3Cb9uyxH-KTw4hPlvOLq29guYWo-odIzE_iE=.2b10784e-148c-416b-a53a-249582775531@github.com>

On Fri, 30 Aug 2024 01:03:32 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Several changes are implemented here:
>> 
>> 1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
>> 2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
>> 3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.
>
> src/hotspot/share/gc/shenandoah/shenandoahController.cpp line 104:
> 
>> 102:     _alloc_failure_gc.unset();
>> 103:     _humongous_alloc_failure_gc.unset();
>> 104:   }
> 
> For good hygiene, I'd move the variable value changes into the monitor which is held when waiting or notifying. I realize this doesn't matter for correctness, but makes debugging easier.
> 
> Further, if you protect the updates and reads of the variables with the lock, you don't need to do the extra atomic ops.
> 
> You'd need to examine all sets/gets and waits/notifys to make sure this works, but I am guessing it will, and it'll also improve performance.
> 
> However, that can be done in a separate effort, if you prefer, for which I'm happy to file a separate ticket for that investigation/change.

I realize now that this idiom is quite pervasive in Shenandoah code, so just fixing this instance of it doesn't accomplish much at this time. I am not convinced it's a good idiom. I'll investigate this separately. I vaguely recall a discussion along these lines in an older PR.

I'll file a separate ticket for this; you can ignore this remark for the purposes of this PR.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1737594870

From wkemper at openjdk.org  Sat Aug 31 00:10:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 31 Aug 2024 00:10:34 GMT
Subject: RFR: 8338534: GenShen: Handle alloc failure differently when
 immediate garbage is pending
In-Reply-To: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
References: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
Message-ID: <8ZKBvGmJMs7NC8wwMc2qodNwwM1F_PrUK3UcBUat6qE=.23bbf43c-245d-435e-a10a-716cdd6aa3df@github.com>

On Wed, 21 Aug 2024 14:48:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Several changes are implemented here:
> 
> 1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
> 2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
> 3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/shenandoahController.cpp line 72:

> 70:                  byte_size_in_proper_unit(req.size() * HeapWordSize), proper_unit_for_byte_size(req.size() * HeapWordSize));
> 71: 
> 72:     if (Atomic::load(&_anticipated_immediate_garbage) < req.size()) {

To make sure I understand... here we are saying that if final mark anticipates this much immediate garbage (computed when it rebuilt the freeset after choosing the collection set), then we aren't going to cancel the GC if this particular request could be satisfied. Instead we will block as though the gc has already been cancelled. This thread will be notified when concurrent cleanup completes.

src/hotspot/share/gc/shenandoah/shenandoahController.cpp line 101:

> 99: 
> 100: void ShenandoahController::notify_alloc_failure_waiters(bool clear_alloc_failure) {
> 101:   if (clear_alloc_failure) {

Why would we not clear the alloc failure? This seems like it would confuse the control thread. Isn't this going to have the control thread attempt to notify alloc failure waiters again when the cycle is finished?

-------------

PR Review: https://git.openjdk.org/shenandoah/pull/479#pullrequestreview-2273675393
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1739549118
PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1739551197

From wkemper at openjdk.org  Sat Aug 31 00:10:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 31 Aug 2024 00:10:34 GMT
Subject: RFR: 8338534: GenShen: Handle alloc failure differently when
 immediate garbage is pending
In-Reply-To: <LSilNZBAYWDmgIEsVJgzW0SpziGSwm-gikunMRuqFbc=.6ec89686-800f-4037-b296-2db7b7ac39a4@github.com>
References: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
 <LSilNZBAYWDmgIEsVJgzW0SpziGSwm-gikunMRuqFbc=.6ec89686-800f-4037-b296-2db7b7ac39a4@github.com>
Message-ID: <W0_3mf03GeWpyotRhyRiDM2rohsEmdLMY-CzwwA9P8Q=.85955cc6-5e45-4e0c-95ce-e66c4e0a876f@github.com>

On Fri, 30 Aug 2024 23:03:10 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Several changes are implemented here:
>> 
>> 1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
>> 2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
>> 3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 756:
> 
>> 754:     size_t first_old, last_old, num_old;
>> 755:     heap->free_set()->prepare_to_rebuild(young_cset_regions, old_cset_regions, first_old, last_old, num_old);
>> 756:     size_t anticipated_immediate_garbage = (old_cset_regions + young_cset_regions) * ShenandoahHeapRegion::region_size_words();
> 
> This makes it sound like old_cset_regions & young_cset_regions hold all regions that will be part of `immediate garbage` -- which indeed is the case. The name `prepare_to_rebuild()` does not give one much clue as to the fact that that's happening when we return from the call, and the API spec of the method does not explicitly specify it. One needs to read into the code of the method `find_regions_with_alloc_capacity()` to realize that this is what is happening.
> 
> In summary, firstly, I feel some of these methods are in need of tighter header file documentation of post-conditions that callers are relying on and, secondly, I feel given the extremely fat APIs (lots of reference variables that are modified by these methods) that some amount of refactoring is needed in the longer term. The refactoring should be a separate effort, but in the shorter term I think the API/spec documentation of `prepare_to_rebuild` and `find_regions_with_alloc_capacity` could be improved.

The names `old_cset_regions` and `young_cset_regions` is very confusing as well. These regions are already trash _before_ the collection set is chosen during final mark (and so, will not themselves be part of the collection set). Suggest calling them `old_trashed_regions` and `young_trashed_regions` here.

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/479#discussion_r1739541915