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

[Y. Srinivas Ramakrishna]

On Mon, 10 Nov 2025 14:39:09 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 58 commits:
> 
>  - 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
>  - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java
>  - fix two indexing bugs
>  - add an assert to detect suspected bug
>  - Remove debug scaffolding
>  - ... and 48 more: https://git.openjdk.org/jdk/compare/c272aca8...16cd6f8a

What if one used "garbage" as the sorting metric for efficiency (under assumption that I stated earlier of considering only retired, fully allocated regions -- the alternative makes the metric a bit more nuanced), and compute garbage as `[regionSize(or used assuming all of region allocated) - markedLive]`. This makes the metric invariant after final marking for any region considered in the target evacuation set, and you don't deal with trying to determine the amount allocated above TAMS, keeping the calculations simple and the selection and sorting criteria clean and easy to reason about.

I also noticed that choosing selection set etc. takes the heap lock. Why?

I'll leave more specific comments in the code later today.

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

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