RFR: 8331126: [s390x] secondary_super_cache does not scale well [v13]

[Andrew Haley]

On Sun, 30 Jun 2024 15:56:48 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> s390x Port for [JDK-8180450](https://bugs.openjdk.org/browse/JDK-8180450)
>> 
>> I ran `tier1` test with  `-XX:+UseSecondarySupersTable -XX:+VerifySecondarySupers -XX:+StressSecondarySupers` in fastdebug vm and didn't see any new failure appearing; Except one I have mentioned [here](https://github.com/openjdk/jdk/pull/19368#issuecomment-2154983693); But this is reproducible on every other architecture with these flags. 
>> 
>> 
>> Without Patch: 
>> 
>> SecondarySuperCacheHits.test  avgt   15  0.929 ± 0.010  ns/op
>> 
>> SecondarySuperCacheInterContention.test     avgt   15  1.413 ± 0.007  ns/op
>> SecondarySuperCacheInterContention.test:t1  avgt   15  1.415 ± 0.016  ns/op
>> SecondarySuperCacheInterContention.test:t2  avgt   15  1.410 ± 0.017  ns/op
>> 
>> Benchmark                             Mode  Cnt   Score   Error  Units
>> SecondarySupersLookup.testNegative00  avgt   15   1.806 ± 0.325  ns/op
>> SecondarySupersLookup.testNegative01  avgt   15   2.364 ± 0.236  ns/op
>> SecondarySupersLookup.testNegative02  avgt   15   2.903 ± 0.215  ns/op
>> SecondarySupersLookup.testNegative03  avgt   15   3.417 ± 0.199  ns/op
>> SecondarySupersLookup.testNegative04  avgt   15   3.758 ± 0.102  ns/op
>> SecondarySupersLookup.testNegative05  avgt   15   4.352 ± 0.123  ns/op
>> SecondarySupersLookup.testNegative06  avgt   15   4.800 ± 0.099  ns/op
>> SecondarySupersLookup.testNegative07  avgt   15   5.365 ± 0.060  ns/op
>> SecondarySupersLookup.testNegative08  avgt   15   6.316 ± 0.092  ns/op
>> SecondarySupersLookup.testNegative09  avgt   15   6.669 ± 0.164  ns/op
>> SecondarySupersLookup.testNegative10  avgt   15   7.041 ± 0.164  ns/op
>> SecondarySupersLookup.testNegative16  avgt   15   9.336 ± 0.185  ns/op
>> SecondarySupersLookup.testNegative20  avgt   15  11.373 ± 0.029  ns/op
>> SecondarySupersLookup.testNegative30  avgt   15  15.236 ± 0.051  ns/op
>> SecondarySupersLookup.testNegative32  avgt   15  16.031 ± 0.091  ns/op
>> SecondarySupersLookup.testNegative40  avgt   15  19.197 ± 0.279  ns/op
>> SecondarySupersLookup.testNegative50  avgt   15  23.804 ± 2.387  ns/op
>> SecondarySupersLookup.testNegative55  avgt   15  25.610 ± 1.155  ns/op
>> SecondarySupersLookup.testNegative56  avgt   15  26.128 ± 2.203  ns/op
>> SecondarySupersLookup.testNegative57  avgt   15  26.126 ± 0.881  ns/op
>> SecondarySupersLookup.testNegative58  avgt   15  26.314 ± 0.521  ns/op
>> SecondarySupersLookup.testNegative59  avgt   15  26.750 ± 0.837  ns/op
>> SecondarySupersLookup.testNegative60  avgt   15  27.118 ± 0.557 ...
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unnecessary checks

src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3228:

> 3226: 
> 3227:   // load 0 in r_result by default. In case search fails, r_result will be loaded
> 3228:   // with value 1 (failure) at the end of this method.

Suggestion:

  // Initialize r_result with 0 (indicating success). If searching fails, r_result will be loaded
  // with 1 (failure) at the end of this method.

src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3331:

> 3329:   // wrapped around the end of the array.
> 3330: 
> 3331:   { // This is conventional linear probing, but instead of terminating,

Suggestion:

  { // This is conventional linear probing, but instead of terminating

src/hotspot/cpu/s390/macroAssembler_s390.cpp line 3344:

> 3342: 
> 3343:     // We should only reach here after having found a bit in the bitmap.
> 3344:     // Invariant: array_length == popcount(bitmap)

It turns out this invariant isn't true. When `array_length` is >= 63 we set `SECONDARY_SUPERS_BITMAP_FULL`, for performance reasons.

Suggestion:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19544#discussion_r1660697339
PR Review Comment: https://git.openjdk.org/jdk/pull/19544#discussion_r1660699570
PR Review Comment: https://git.openjdk.org/jdk/pull/19544#discussion_r1660702697