RFR: 8298647: GenShen require heap size 2MB granularity [v3]

[Stuart Monteith]

On Mon, 23 Jan 2023 11:24:13 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

>> Generational Shenandoah requires 2MB granularity in order for card tables to cover the allocated heap. Each byte in a page of card table represents 512 heap bytes. As card tables are allocated 4KB at a time, 4KB * 512 = 2MB.
>> 
>> There is a circular dependency between the region calculations and the heap size calculations. This unconditionally rounds up the heap size to 2MB. It might be preferable to do this only when generational mode is enabled.
>> 
>> Running with:
>>   java -Xlog:gc*=trace -XX:+UseShenandoahGC -mx495m \
>>        -XX:ShenandoahGCMode=generational -version
>> 
>> on a debug build is sufficient to reproduce this problem.
>
> Stuart Monteith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check shenandoah generational is enabled.
>   
>   Only round up for the card table alignment when generational mode is
>   enabled.

I included with the patch the statistics for the new patterns, here they are:

Adds new patterns to match a memory address and a constant, which are
emitted as two loads. C2 expects that constants INTs will always be
manifested by immediate loads. However, as these intrinsics are avoiding
loading into GPRs and moving them into the vector registers, there is an
addition to allow integers to be loaded as a constant.

There isn't a pattern to match two LoadI nodes - C2 doesn't handle nodes
with two memory nodes for calculating anti-dependencies.


Benchmark                  Result  Units  % against non-SVE2
Integers.compress          2.009   µs/op
Integers.compress-SVE      1.435   µs/op  71.43%
Integers.compress-SVE+mem  1.263   µs/op  62.87%
Integers.expand            2.129   µs/op
Integers.expand-SVE        1.433   µs/op  67.31%
Integers.expand-SVE+mem    1.32    µs/op  62.00%
Longs.compress             2.504   µs/op
Longs.compress-SVE         1.445   µs/op  57.71%
Longs.compress-SVE+mem     1.269   µs/op  50.68%
Longs.expand               2.614   µs/op
Longs.expand-SVE           1.489   µs/op  56.96%
Longs.expand-SVE+mem       1.272   µs/op  48.66%

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

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