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

Fei Yang fyang at openjdk.java.net
Mon Jan 10 06:49:44 UTC 2022


On Mon, 10 Jan 2022 03:32:43 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> 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.

For the nmethod_entry_barrier case, I would omit the extra_offset parameter (and also the nmethod_barrier_guard_offset funtion). I think your newly-added assertion at line 265 is enough.

But looks like it's different in the trampoline case where I see we need a wordSize (8bytes) alignment. So we may keep the change for this case.

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

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


More information about the riscv-port-dev mailing list