RFR: 8320697: RISC-V: Small refactoring for runtime calls [v4]

Robbin Ehn rehn at openjdk.org
Mon Dec 4 08:21:45 UTC 2023


On Fri, 1 Dec 2023 11:03:28 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Hi, please review this refactoring for runtime calls.
>> Major changes:
>> 1. Unified the runtime calls with the existing MacroAssembler::rt_call. This will remove the duplicate code like `relocate(target.rspec() [&] {...}` to emit uncompressed instructions.
>> 2. Removed MacroAssembler::far_branches and made the call sites default to far branches. `branch_range` is 1MB for riscv, and `ReservedCodeCacheSize` will always bigger than `branch_range` in practice. We should remove this unnecessary check and simplify the code logic.
>> 3. Renamed MacroAssembler::la_patchable with MacroAssembler::la making it less confusing.
>> 4. `far_call` in `rt_call` should use `tmp` instead of the default temporary register `t0`
>> 5. Removed some unused codes in `g1BarrierSetAssembler_riscv.cpp`
>> 
>> 
>> Testing:
>> - [x] Tier1-3 tested on hifive unmatched board (release)
>> - [x] Run non-trivial benchmark workloads (fastdebug)
>
> Feilong Jiang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8320697
>  - adjust format
>  - remove unnecessary relocate
>  - Rename la_patchable with la
>  - RISC-V: Small refactoring for external and runtime calls

Hey!

I notice this:

  static int far_branch_size() {   
    if (far_branches()) {                                          
      return 2 * 4;  // auipc + jalr, see far_call() & far_jump()


Which is used to determine deopt handler size.

I don't understand how we ever may use movptr here instead with knowing who is calling?

I think we want two methods here one with fixed size ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16816#issuecomment-1838043824


More information about the hotspot-compiler-dev mailing list