RFR: 8319777: Zero: Support 8-byte cmpxchg

[Aleksey Shipilev]

On Mon, 13 Nov 2023 12:29:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> See related discussion in [JDK-8318776](https://bugs.openjdk.org/browse/JDK-8318776) that targets to require `supports_cx8()` unconditionally.
>> 
>> I think we can claim Zero is `supports_cx8() == true`, because we have enough fallbacks for 8-byte CASes to work. Note that some code already reaches for these without checking for `supports_cx8()`, so the proverbial horses have already left the barn.
>> 
>> I ran tests with [JDK-8319883](https://bugs.openjdk.org/browse/JDK-8319883) applied to fix known problems with x86_32 Zero.
>> 
>> Additional testing:
>>  - [x] Linux x86_32 Zero release; jcstress
>>  - [x] Linux x86_32 Zero fastdebug, `compiler/unsafe java/lang/invoke/VarHandles`
>>  - [x] Linux x86_32 Zero fastdebug, bootcycle-images
>
> src/hotspot/cpu/zero/globalDefinitions_zero.hpp line 30:
> 
>> 28: 
>> 29: // Unconditionally supports 8-byte cmpxchg either with
>> 30: // compiler intrinsics or with library/kernel helpers.
> 
> That's not what "native support for cx8" was meant to mean though - e.g. see the ARM header - it only sets this when building for ARMv7.
> 
> You can just leave this file alone and simply set `_supports_cx8` below to achieve the same goal. And that will fit in cleaner with the changes I am making.

Well, yes, we can just do `_supports_cx8 = true`.

But I am confused by the meaning of `SUPPORTS_NATIVE_CX8`. What is it? I read it as "we know statically, at compile time, that the target platform supports CX8". Otherwise, we poll it at runtime and let the runtime code decide by checking `VMVersion::supports_cx8()`. Defining `SUPPORTS_NATIVE_CX8` compiles out access backend locking paths completely, for example, without resorting to runtime checks.

What I am missing? Is the wording for the comment misleading?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16614#discussion_r1391185118