On Fri, 21 Mar 2025 20:25:51 GMT, Andrew Dinn <ad...@openjdk.org> wrote:
>>> In all these cases there is a fast path: e.g. when we know we have already >>> warned for enable native access, or for Unsafe. In the SV API, the fast >>> path is when we know that the SV is set already. In my experience, the >>> volatile access in this fast path costs nothing: whenever I looked at the >>> generated C2 code for hot paths of FFM code using enable-native-access, it >>> seems that, once the stable field is set, the fact that it is volatile no >>> longer matters. There's no barrier generated by C2 -- access is as fast as >>> plain access. >> >> An acquire load is allowed to be reordered with a preceding volatile store >> and I believe this is the only case where it makes a difference. E.g:: >> >> x = load_acquire(p); >> store_volatile(p, v); >> y = load_acquire(p); >> >> can be transformed into: >> >> x = load_acquire(p); >> y = x; >> store_volatile(p, v); >> >> Furthermore, on Aarch64, volatile load is implemented with `ldar` while >> acquire load can be implemented with `ldapr`. > > @merykitty >> Furthermore, on Aarch64, volatile load is implemented with ldar while >> acquire load can be implemented with ldr. > > I'm not sure exactly what you mean here but I don't think that sounds right? @adinn Oh yes silly me, what I meant was that acquire load can be implemented using **LDAPR**. Edited in the original comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2744913159
