RFR: 8310031: Parallel: Implement better work distribution for large object arrays in old gen [v3]

[Richard Reingruber]

On Thu, 27 Jul 2023 06:36:45 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> The guiding principle of `PSCardTable::scavenge_contents_parallel` is to scan only objects that start in the current stripe. There is a special case for the last stripe ending at `space_top` if `space_top` is not card-aligned and an object starts there. With https://github.com/openjdk/jdk/pull/14846/commits/0eb924e1d4dfa1f751a55038063af4f6092be8c2 this is handled explicitly and more clearly to make sure stripes without object starts are skipped right away. This is important for correct handling of large object arrays. IMHO also helpful aside from large arrays.
>
>> The guiding principle of PSCardTable::scavenge_contents_parallel is to scan only objects that start in the current stripe
> 
> And with this pr also large array chunks. When we found that the last stripe before `space_top` has no object start then we know there is no array chunk to scan either. There might be the end of a large array but this is scanned together with the chunk in the previous stripe (see https://github.com/openjdk/jdk/pull/14846/files#diff-fc75bbdc27c5b981a8b66f77cbd83e6d86d8f7d3e313701207d880b7036c8b92R238-R239).

I didn't like the last commit (https://github.com/openjdk/jdk/commit/0eb924e1d4dfa1f751a55038063af4f6092be8c2): it introduced a condition that is only needed for large array handling adding another hunk to the patch.

Instead I've expanded the constraints

```c++
    // 4. range of large array elements to be scanned: [first_obj_addr, cur_stripe_end_addr)
    //    limited to dirty regions


It is enforced where large arrays are handled. Comments explain the assumptions and assertions check them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14846#discussion_r1276540097