RFR: 8339771: RISC-V: Reduce icache flushes [v2]

[Fei Yang]

On Tue, 10 Sep 2024 12:53:18 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hey, please consider,
>> 
>> All code which is offline (behind a barrier) do not need global icache flushes.
>> As we can instead in slow path locally (thread and hart) emit fence.i.
>> But if we were to be context switch do a hart which have not had fence.i emitted we can still fetch stale instructions.
>> To handle this case new now have kernel support:
>> https://docs.kernel.org/arch/riscv/cmodx.html
>> 
>> It's not perfect as we will be emitting fence.i on any context switch for any thread with this patch, even if that thread do not execute on code heap (non attached native thread), and even if there was no changes to code heap.
>> But this is in many cases much faster as the icache flush global IPI is very intrusive.
>> Particular cases are running a concurrent gc with small head room.
>> In such scenario I measured 15% increased throughput on VF2.
>> A large CPU or less head room (faster GC cycles) will yield even more performance boost.
>> 
>> Note that this requires 6.10 kernel.
>> 
>> I'm running VF2 with 6.11-rc3 kernel and this passed tier1-3. (With setting on)
>> 
>> Later we probably want this default on, but as it's hard to test I'll leave default off.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment, moved init after feature enabling

src/hotspot/cpu/riscv/relocInfo_riscv.cpp line 61:

> 59:   if (!UseCtxFencei) {
> 60:     ICache::invalidate_range(addr(), bytes);
> 61:   }

One more question: Do we need a full fence (`OrderAccess::fence()`) here with `UseCtxFencei` after the patching? Like you do in `ZBarrierSetAssembler::patch_barrier_relocation()`:

  if (!UseCtxFencei) {
    // A full fence is generated before icache_flush by default in invalidate_word
    ICache::invalidate_range(addr, bytes);
  } else {
    OrderAccess::fence();
  }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20913#discussion_r1766233124