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

[Fei Yang]

On Thu, 19 Sep 2024 07:23:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Yes. The comment is a bit misleading.
>> A fence wr, wr is just for locally, on a hart, order instructions.
>> A fence wr wr do not flush a store from the store buffer, it just means that the hart must act such that the store appears to have happened before the syscall. Meaning the store can not happen after the syscall.
>> 
>> As we are not using the syscall:
>> Instead the other threads/harts must emit the fence.i them self, either by leaving a safepoint, hitting the patch_epoch_barrier and if they are moved to another hart.
>> 
>> Which means the store must happen before we leave the safepoint and disarming the nmethod barrier.
>> These already have store fences as we have a bunch of other stores which must be ordered.
>> For the nmethod barrier disarming is a full fence as the new epoch must happen before the disarm:
>> 
>> 
>> 0: (nmethod barriers armed, implies storestore)
>> 1: stores to instruction stream
>> 2: store new patching epoch
>> 3: storestore // the store to instruction and patching epoch must happen before disarm
>> 4: disarm
>> 
>> 
>> If the stores to instruction stream and storing the new patching epoch happens in another order that is fine, as the critical thing is the disarm.
>
> Code would in BarrierSetNMethod::set_guard_value(...)

I see. Seems deserve a code comment. Also, does that mean the `OrderAccess::fence()` you added in `ZBarrierSetAssembler::patch_barrier_relocation()` unnecessary?

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

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