RFR: 8366688: G1: Rename G1HeapRegionRemSet::is_added_to_cset_group() to has_cset_group()

Thomas Schatzl tschatzl at openjdk.org
Tue Sep 2 15:25:43 UTC 2025


On Tue, 2 Sep 2025 13:06:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> I can sort of understand why it's named "added_to", because conceptually, the api answers whether the per-region remset belongs to a cset group, instead of a unique one.

I think there is some confusion about the naming of cset groups. Cset groups are nothing but a card set covering the cards of a set of regions.

Previously the card set has been part of the HRRS ("all the information to evacuate a region", i.e. the region's remset), the change has been that the card set part of the HRRS is shared.

[Unfortunately it would be a bit awkward to have the HRRS itself be shared across regions right now - the problem is the code root set. If g1 shared the code root set, and drop the HRRS, then g1 could never evacuate that region any more as we never rebuild that one. Could be added though.]

> 
> The name "has_cset_group" is odd, IMO, since it implies ownership, which is wrong. The new name makes more sense on a heap-region -- a region possesses a cset group, shared with other regions potentially.
> 

I see your point - what if the cset group would be called something like "cardset group" (I have no good name, maybe shared-cardset, but otoh it also contains some information related to evacuation like gc-efficiency of the group of regions, so it is related to collection set candidates), would that make understanding the reason for this name? Then it makes sense that one can ask the question whether the heap region's remset (the hrrs) "has" a card based remembered set (attached).

Maybe there is a better term here, like the suggested `has_cset_group_attached/assigned()` or so? I think the shorthand suggested in this PR is acceptable.

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/27048#issuecomment-3245803826


More information about the hotspot-gc-dev mailing list