RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants

[Robbin Ehn]

On Sun, 8 Dec 2024 03:00:03 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 479:
> 
>> 477:   ttg.doit();
>> 478:   ttg.join();
>> 479:   ASSERT_EQ(data, (TESTSIZE)(num_threads*10000));
> 
> Seems there is an integer overflow issue for the narrow tests? `num_threads*10000` is 40000 here which is much larger than allowed for `int8_t` and `int16_t` types.

Strictly speaking the first overflow happens here:
`TESTSIZE newvalue = oldvalue + 1;`
As '1' is an integer, oldvalue is promoted to an integer and as 128 is not in range of int8_t.
This is implementation defined, but de facto we know this will wrap around.

The casting of 40000 to TESTIZE the same thing happens, but first the higher bits are truncated and then it may wrap around depending on the MSB.

AFIACT it always produces the same result.

If we don't trust the wrap around as it's outside the spec both cases should be handled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1875546653