RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v12]

[Kelvin Nilsen]

On Mon, 13 Oct 2025 22:18:38 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions, where the amount of live data determines whether a region should be added to the collection set during the final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
>  - remove _mixed_candidate_garbage_words from ShenandoahHeapRegion
>  - reviewer feedback to reduce code duplication
>  - Fix compilation errors after merge
>  - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
>  - Fix uninitialized variable
>  - Remove deprecation conditional compiles
>  - Adjust candidate live memory for each mixed evac
>  - Refactor for better abstraction
>  - Fix set_live() after full gc
>  - ... and 35 more: https://git.openjdk.org/jdk/compare/92f2ab2e...24322e75

I'm going to place this in draft while I experiment with the code to diagnose apparent regressions with traditional shenandoah mode.

I have placed instrumentation into the code to confirm that the live_data reported by ShenandoahHeapRegion is the same before and after this PR for traditional Shenandoah mode.  So the regressions are either "signal noise", or perhaps inefficiencies introduced regarding how we compute the live_data.

After refactoring the code to perform better in the "tight" rebuild free-set and build-collection set loops, the Shenandoah results show very slight improvement (rather than regression) on specjbb2015.  Here is the performance regression that we saw before commit https://github.com/openjdk/jdk/pull/24319/commits/ecdec6363ee9e0a27f4207350cf0b51f8c99bab5

<img width="1574" height="436" alt="image" src="https://github.com/user-attachments/assets/7e5d2134-082f-42c2-9017-c70368afb11a" />

Here are comparisons (in a slightly different environment) after that same commit:

<img width="1570" height="698" alt="image" src="https://github.com/user-attachments/assets/98b5933a-86ce-430d-bef9-3c7cf1ee5122" />

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

PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3401760959
PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3416424293
PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3453055680