RFR: 8314599: [GenShen] Couple adaptive tenuring and generation size budgeting [v3]

[William Kemper]

On Tue, 14 Oct 2025 16:55:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The _tenure_ here refers to the regions the objects reside in, not the objects themselves. `get_live_bytes_in_tenurable_regions` is the sum of live bytes in all regions with an age above the tenuring threshold (we expect to promote _all_ of these, though some promotions may fail). It's complement `get_live_bytes_in_untenurable_regions` is the sum of live bytes in all regions with an age less than the tenuring threshold (we expect to promote _some_ of these, but we don't really know how many). This was part of the reason I wanted to rename these methods. They  represent the provenance of the objects in the collection set, not necessarily the regions they will be evacuated to.
>
>> get_live_bytes_in_untenurable_regions is the sum of live bytes in all regions with an age less than the tenuring 
>> threshold (we expect to promote some of these, but we don't really know how many)
> 
> Given that the promotion potential is determined by mark-time age census, I was thinking we do know how many of the bytes in untenurable_regions we "expect to promote".  Isn't this just total_promotable_bytes - get_live_bytes_in_tenurable_regions()?

The age census doesn't give us the level of detail to break down promotable bytes per region. The collection set has a subset of the tenurable and untenurable regions. Of those, we still don't really _know_ how much of the live data in the tenurable regions will be promoted. The changes here try to plan for the worst case by reserving as much of old as possible for promotions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27632#discussion_r2433595356