The usage of fence.i in openjdk

[Vladimir Kempik]

> 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.

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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/riscv-port-dev/attachments/20220729/8392e43b/attachment-0001.htm>