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

[Kelvin Nilsen]

On Thu, 8 Jan 2026 22:53:43 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 62 commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
>  - touch file to force retest
>  - Finish merge
>  - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
>  - Fix mistaken merge resolution
>  - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
>    
>    The resulting fastdebug build has 64 failures.  I need to debug these.
>    Probably introduced by improper resolution of merge conflicts
>  - fix error in merge conflict resolution
>  - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
>  - rework CompressedClassSpaceSizeinJmapHeap.java
>  - fix errors in CompressedClassSpaceSizeInJmapHeap.java
>  - ... and 52 more: https://git.openjdk.org/jdk/compare/385c4f81...6d10ae5a

We have decided to reject this implementation as an alternative approach offers better performance.

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

PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-3775372622