RFR: 8371649: ZGC: AArch64: redundant OrderAccess::fence in ZBarrierSetAssembler::patch_barrier_relocation

[Andrew Haley]

On Thu, 13 Nov 2025 19:35:53 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>>> Hi Erik (@fisk),
>>> 
>>> Could you also please take a look, just in case the fence was intentionally put there?
>> 
>> The way I look at it, the fence was there for hardware that is unsophisticated enough to require manual cache flushing instead of having cache coherency that understands instruction edits, and at the same time has unsophisticated enough fences that are not speculated across such that the buffered store hits the cache before invalidating the cache, and not after, which would be awkward.
>> 
>> It is certainly possible that in practice the cache invalidation facilities also do the right level of fencing. So this is mostly just defensive programming.
>> 
>> If I flip the question around - how confident do you feel on a scale from 1 to 10 that the cache invalidation mechanism guarantees across all implementations, that the preceding store is flushed out to the caches before the cache is flushed? This is an area of the code where I don't want to take chances and slip unless we feel a high level of confidence.
>
>> @fisk , I'm assuming that no other thread is executing the target instructions while were patching them.
> 
> Indeed; no concurrent thread is executing the instructions being modified.

> > > @fisk , I'm assuming that no other thread is executing the target instructions while were patching them.
> > 
> > 
> > Indeed; no concurrent thread is executing the instructions being modified.
> 
> So, this confirms the redundancy of the `fence`, doesn't it?

Not really, no, I was just checking. I'm pretty sure that the fence is redundant, though.

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

PR Comment: https://git.openjdk.org/jdk/pull/28244#issuecomment-3546270587