RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]

[Quan Anh Mai]

On Fri, 21 Mar 2025 20:25:51 GMT, Andrew Dinn <adinn at 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