RFR: 8332587: RISC-V: secondary_super_cache does not scale well [v8]

[Andrew Haley]

On Wed, 19 Jun 2024 07:56:08 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 210:
>> 
>>> 208:       if (!FLAG_IS_DEFAULT(UseSecondarySupersTable)) {
>>> 209:         warning("UseSecondarySupersTable is not supported on this CPU");
>>> 210:       }
>> 
>> Disabling `UseSecondarySupersTable` is probably not a good idea. https://github.com/openjdk/jdk/blob/48621ae193ef70b2fae4dcb7ddc524f349beb131/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L4743 is a better and easier way to handle this situation.
>
>> Disabling `UseSecondarySupersTable` is probably not a good idea.
>> 
>> https://github.com/openjdk/jdk/blob/48621ae193ef70b2fae4dcb7ddc524f349beb131/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L4743
>> 
>> is a better and easier way to handle this situation.
> 
> Hi, The same question has been raised before. Here is the implementation and test data using scalar registers. https://github.com/openjdk/jdk/pull/19320#issuecomment-2144900070
> With the jmh test data, we see that there is a performance decrease from testNegative55 to testNegative64 when zbb is not available. This is because a loop is needed to count the number of 1 when Zbb is not available. Therefore, the current patch is only optimized when Zbb is available. What do you think?

> > Disabling `UseSecondarySupersTable` is probably not a good idea.
> > https://github.com/openjdk/jdk/blob/48621ae193ef70b2fae4dcb7ddc524f349beb131/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L4743
> > 
> > is a better and easier way to handle this situation.
> 
> Hi, The same question has been raised before. Here is the implementation and test data using scalar registers. [#19320 (comment)](https://github.com/openjdk/jdk/pull/19320#issuecomment-2144900070) With the jmh test data, we see that there is a performance decrease from testNegative55 to testNegative64

Such huge numbers of secondary supers don't occur in real-world code.

> when zbb is not available. This is because a loop is needed to count the number of 1 when Zbb is not available. Therefore, the current patch is only optimized when Zbb is available. What do you think?

Please do that test again with -XX:-UseSecondarySupersCache. There is a problem I don't quite understand which causes the benchmark to use the existing secondary_super_cache, and this gives results that are misleading.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19320#discussion_r1645665331