RFR: 8316961: Fallback implementations for 64-bit Atomic::{add,xchg} on 32-bit platforms [v4]
David Holmes
dholmes at openjdk.org
Tue Oct 24 09:54:31 UTC 2023
On Mon, 23 Oct 2023 14:17:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> See the bug for rationale. Looks like there is enough infrastructure to achieve what we want without significant fan-out. I checked all `atomic_*.hpp` headers for unimplemented `PlatformAdd<8>` and `PlatformXchg<8>`, and only these seem to be affected.
>>
>> Unfortunately, we cannot test these apart from the existing gtest.
>>
>> Additional testing:
>> - [x] linux-x86-server-fastdebug, atomic tests pass
>> - [x] linux-arm-server-fastdebug, atomic tests pass (with #16269 applied)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>
> Use public methods instead of Platform*
Note you cannot just provide a lock-based implementation of cmpxchg8 and think all is well with the world. All accesses to variables that could be updated by such a cmpxchg8 would have to be accessed in a way that is consistent/safe with the use of the lock (e.g. a raw read could see a partial update if done concurrently with a locked-cmpxchg8). Even on the Java side (via Unsafe) this is not fully in place but that issue is recognized and documented.
I'm tempted to say the VM should simply fail to start if `supports_cx8` is not true - the kernel helper has been around for many years for ARMv6 so I can't imagine there would be platforms in use now that don't support it.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/16252#issuecomment-1776884012
PR Comment: https://git.openjdk.org/jdk/pull/16252#issuecomment-1776887812
More information about the hotspot-dev
mailing list