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

[Richard Reingruber]

On Wed, 27 Sep 2023 14:13:23 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Richard Reingruber has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Eliminate special case for scanning the large array end
>>  - First card of large array should be cleared if dirty
>>  - Do all large array scanning in separate method
>>  - Limit stripe size to 1m with at least 8 threads
>>  - Small clean-ups
>
> Hi,
> 
>> > I experimented with the aforementioned read-only card table idea a bit and here is the draft:
>> > https://github.com/openjdk/jdk/compare/master...albertnetymk:jdk:pgc-precise-obj-arr?expand=1
>> 
>> This looks very nice! The code is a lot easier to follow than the baseline and this pr.
>> 
>> With your draft I found out too that the regressions with just 2 threads come from the remaining `object_start` calls. Larger stripes mean fewer of them. The caching used in your draft is surly better.
>> 
>> So by default 1 card table byte per 512b card is needed. The shadow card table will require 2M per gigabyte used old generation. I guess that's affordable.
>> 
>> Would you think that your solution can be backported?
> 
> I had a brief look at @albertnetymk's suggestion, a few comments:
> 
> * it uses another card table - while "just" another 0.2% of the heap, we should try to avoid such regressions. G1 also does not need another card table... maybe some more effort should be put into optimizing that one away.
> * obviously allocating and freeing during the pause is suboptimal wrt to pause time so the prototype should be improved in that regard :)
> * the copying will stay (if there is a second card table), I would be interested in pause time changes for more throughput'y applications (jbb2005, timefold/optaplanner https://timefold.ai/blog/2023/java-21-performance)
> * anything can be backported, but the question is whether the individual maintainers of these versions are going to. It does have a good case though which may make it easier to convince maintainers.
> 
> Hth,
>   Thomas

Thanks a lot @tschatzl for reviewing. I hope I've covered all of your feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/14846#issuecomment-1772842725