RFR: 8293007: riscv: optimize nmethod entry barrier

[Aleksey Shipilev]

On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier.
> Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. 
> 
> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.

Looks okay with minor comments.

src/hotspot/cpu/riscv/gc/g1/g1BarrierSetAssembler_riscv.cpp line 161:

> 159:   __ bind(runtime);
> 160: 
> 161:   __ push_call_clobbered_registers();

So this looks like a bugfix? https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000601.html

The issue and PR should probably reflect that then.

src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 192:

> 190: 
> 191: void BarrierSetAssembler::clear_patching_epoch() {
> 192:   _patching_epoch = 0;

Don't we want `Atomic::store(&_patching_epoch, 0)` here?

src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 224:

> 222:         // which means there isn't really any need for any fencing for neither
> 223:         // data nor instruction modification happening concurrently. The
> 224:         // instruction patching is synchronized with glocal icache_flush() by

"global"?

src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp line 204:

> 202:     // are read in the opposite order, such that the load of the nmethod guard
> 203:     // acquires the patching epoch. This way, the guard is guaranteed to block
> 204:     // entries to the nmethod, util it has safely published the requirement for

"until"?

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10056