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

[Fei Yang]

On Thu, 5 Dec 2024 11:49:47 GMT, Robbin Ehn <rehn 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.

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

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