RFR: Mixed evacuation [v6]

[Kelvin Nilsen]

On Tue, 20 Apr 2021 00:10:04 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change definition of CollectionThresholdGarbagePercent
>   
>   This is now defined to equal ShenandoahGarbageThreshold, which seems to have
>   a default value of 25.  The effect on running workloads is to choose more
>   regions for the collection set than was observed with the previous
>   configuration.
>   
>   Also addressed several improvements in white space and comments.
>   
>   The code now runs tier1 and hotspot_gc_shenandoah without regressions.  It
>   also succsessfully runs an Extremem stress test up until the point of
>   failure due to triggering of full GC (after 113 completed GC passes, including
>   two old-gen GC passes).

Thanks much for the quick feedback.  I believe I can get through all of these later today.

Regarding the question of whether it makes sense to duplicate the heuristics, I believe the answer is yes.  Here is some of the rationale:

1. In general, we expect old-gen to behave very differently than young-gen.  If all is properly configured, young-gen will experience high allocation rates and very high infant mortality.  While old-gen will experience relatively low allocation (promotion) rates and no infant mortality.  If properly configured, we do not promote to old-gen until we have confirmed that an object is no more likely to die in infancy than to die in old age.

2. The old-gen heuristics need to maintain additional information that is not required by the young-gen heuristics, so all of the old-gen subclass heuristics need to derive from a different base class.  Among information required by old-gen is the candidate collection set, the coalesce-and-fill set, and awareness of whether previously selected old-gen candidate collection set has been fully processed.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29