[riscv-port] RFR: 8278994: riscv: RVC support [v10]

[Xiaolin Zheng]

On Mon, 10 Jan 2022 01:20:58 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Move RVC code to the proper location after rebasing (#42)
>>  - Rename misc functions and change the positions of some comments
>>  - Remove remaining macros as discussions
>>  - Remain an 'minimum_alignment' unchanged
>>  - Manually inline all macros into functions as discussions
>>  - Remove assembler_riscv_c.hpp as discussions
>>  - Remove COMPRESSIBLE & NOT_COMPRESSIBLE macros by adding one layer as discussions
>>  - Fix remaining CEXT -> RVC
>>  - Remove Alignment-related changes as discussions
>>  - Update licenses to the new year
>>  - ... and 4 more: https://git.openjdk.java.net/riscv-port/compare/c7944edf...2a6ff151
>
> src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 245:
> 
>> 243:   // RVC: RISCV's amoswap instructions need an alignment for the memory address it swaps
>> 244:   //   when we reach here we may get a 2-byte alignment so need to align it
>> 245:   __ align(4, nmethod_barrier_guard_offset());
> 
> Is it necessary to pass nmethod_barrier_guard_offset() as the "extra_offset" parameter here since this function will return (12 * instruction_size) which is multiple of 4 ?

Yes - it seems a little obscure though.

1. The background is that:

about the `nmethod_entry_barrier`:

nmethod_entry_barrier (begin) {   <-  when we reach here, we may get a 2-byte alignment because of RVC's existence.
   ... 
   amoswap                            
   <the swapped address in the code segment>    <-  though the size of the whole stub is a multiple of 4 currently, 
                                                    here we may also get a 2-byte alignment because of the above issue.
} nmethod_entry_barrier (end)


and about the trampoline:

trampoline (begin) {  <-  when we reach here, we may get a 2-byte alignment because of RVC's existence.
   auipc
   ld
   jalr
   <the real jump target in the code segment>  <-  same as the above explanation.
} trampline (end)


2. The reason to pass another argument is that: 

we might consider just keeping the start address of the code slices (nmethod_entry_barrier and trampoline) aligned to 4-byte to solve this issue, but this assumption is based on 'the size of the code slices (nmethod_entry_barrier and trampoline themselves) are a multiple of 4', and we don't know if they will change in the future by RVC. So I explicitly pass the real target address to the `align` function as a new argument to make sure the code is always right in the future.

I am pleased with other suggestions for this part.

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

PR: https://git.openjdk.java.net/riscv-port/pull/34