The usage of fence.i in openjdk

[Palmer Dabbelt]

On Fri, 29 Jul 2022 10:41:18 PDT (-0700), vladimir.kempik at gmail.com wrote:
>
>
>> 29 июля 2022 г., в 18:12, wangyadong (E) <yadonn.wang at huawei.com <mailto:yadonn.wang at huawei.com>> написал(а):
>> 
>> Hi, Vladimir,
>> 
>>> I believe Java’s threads can migrate to different hart at any moment, hence the use of fence.i is dangerous.
>> Could you describe in detail why the use of fence.i is dangerous? I think it may be just inefficient but not dangerous.
>> To a certain extent, this code is hangover from the aarch64 port and we use fence.i to mimic isb.
>> 
> Basically, fence.i executed on a hart, it is only doing anything to the current hart. And your thread can be rescheduled to another hart soon after fence.i
>
> Lets say you have a thread A running on hart 1.
> You've changed some code in region 0x11223300 and need fence.i before executing that code.
> you execute fence.i in your thread A running on hart 1. 
> right after that your thread ( for some reason) got rescheduled ( by kernel) to hart 2.
> if hart 2 had something in l1i corresponding to region 0x11223300, then you gonna have a problem: l1i on hart 2 has old code, it wasn’t refreshed, because fence.i was executed on hart 1 ( and never on hart 2). And you thread gonna execute old code, or mix of old and new code.

Sorry for forking the thread, I saw this come in right after I sent my 
message.  This is correct, the performance-related reasons we're not 
doing a fence.i when scheduling are discribed in that message: 
<https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000570.html>

>
> Regards, Vladimir.
>
>>> Maybe there is a need to add __asm__ volatile ("fence":::"memory") at the beginning of this method.
>> You're right. It'd better place a full data fence before the syscall, because we cannot guarantee here the syscall leave a data fence there before IPI remote fence.i to other harts
>> 
>> Yadong
>>