RFR: Handle old, pinned regions [v7]

[Y. Srinivas Ramakrishna]

On Fri, 5 Aug 2022 07:22:37 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> 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
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 207:
> 
>> 205:     }
>> 206: 
>> 207:     size_t garbage = region->garbage();
> 
> Is `_region_data` above basically a statically allocated scratchpad array that can be used for temporary storage and calculations, and guarantees that it's at least as big as the number of regions in the heap? Typically you use a subset of that array, e.g. in this case you use a prefix for storing collection set candidates.
> 
> Is there any sanity checking to ensure that different uses of it do not inadvertently stomp on each others' data? Perhaps there is some state checking somewhere for this in debug/assert mode? Otherwise, it would seem a bit fragile and might pose maintenance headaches down the line.

Also, may be this mode of use should be documented clearly (along with extending, as necessary, with sufficient state to detect and report stomping -- say in debug / assert mode).

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

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