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

[Kelvin Nilsen]

On Thu, 10 Apr 2025 22:33:28 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove deprecation conditional compiles
>>  - Adjust candidate live memory for each mixed evac
>
> Haven't started looking at these changes, but I do wonder if it might be worthwhile to also consider (and implement under a tunable flag) the alternative policy of never adding to the collection set any regions that are still "active" at the point when the collection set for a marking cycle is first assembled at the end of the final marking. That way we don't have to do any re-computing, and the criterion for evacuation is garbage-first (or liveness-least) both of which remain invariant (and complements of each other) throughout the duration of evacuation and obviating entirely the need for recomputing the goodness/choice metric afresh.
> 
> The downside is that we may leave some garbage on the table in the active regions, but this is probably a minor price for most workloads and heap configurations, and doesn't unnecessarily complicate or overengineer the solution.
> 
> One question to consider is how G1 does this. May be regions placed in the collection set are retired (i.e. made inactive?) -- I prefer not to forcibly retire active regions as this wastes space that may have been usable.
> 
> Thoughts? (Can add this comment and discuss on the ticket if that is logistically preferable.)

@ysramakrishna : Interesting idea.  Definitely worthy of an experiment.  On the upside, this can make GC more "efficient" by procrastinating until the GC effort maximizes the returns of allocatable memory.  On the downside, this can allow garbage to hide out for arbitrarily long times in regions that are not "fully used".  I'd be in favor of proposing these experiments and possible feature enhancements in the context of a separate JBS ticket.

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

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