RFR: Handle old, pinned regions [v7]

[Kelvin Nilsen]

On Wed, 3 Aug 2022 01:10:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
>> 
>> * Before adding old regions to the collection set, their pinned status is synchronized.
>> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
>> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Do not drop abbreviated argument when recording success concurrent cycle
>  - Fix whitespace
>  - Prepare for review
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Validate old gen state transitions
>  - Make use of old generation without down casting
>  - Make verifier aware of changes to old generation state machine
>  - Make rset scan aware of changes to old generation state machine
>  - Fix use of index as count and over-counting of garbage
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6

Lot of code here.  Thanks for working through it.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 349:

> 347:   // Cannot start a new old-gen GC until previous one has finished.
> 348:   //
> 349:   // Future refinement: under certain circumstances, we might be more sophisticated about this choice.

This comment is stale, with the new implementation.  My thought when I wrote the comment was that we cannot "abandon" the identified set of old-gen collection candidates in order to start up a new old-gen collection until the mixed evacuations have completely processed all old-gen collection candidates.  That's because we would have to introduce a "new" phase to coalesce and fill these regions if we choose not to collect them.  But in the new design, it seems like we have the flexibility to decide for more reasons than just pinning that certain candidate regions will not be collected.  For example, if we have some reason to believe that a lot of old-gen memory has newly become garbage, then it might be "best" to abandon the collection set candidates as is and start a new old-gen marking effort.  Not asking for a lot of change here - maybe just a mention in the comment that we have new freedoms that we didn't use to have.

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

Marked as reviewed by kdnilsen (Committer).

PR: https://git.openjdk.org/shenandoah/pull/149