[8u] RFR: JDK-8253036: Support building the Zero assembler port on AArch64

Aleksey Shipilev shade at redhat.com
Thu Sep 17 10:49:16 UTC 2020


On 9/17/20 12:20 PM, Aleksey Shipilev wrote:
> On 9/17/20 11:39 AM, Andrew Haley wrote:
>> On 16/09/2020 16:24, Aleksey Shipilev wrote:
>>    > On 9/16/20 5:10 PM, Andrew Hughes wrote:
>>    >> On 12:22 Wed 16 Sep     , Aleksey Shipilev wrote:
>>    >>> On 9/16/20 8:27 AM, Andrew Hughes wrote:
>>    >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8253036
>>    >>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8253036/webrev.01/
>>    >>>
>>    >>> That's it, no more changes required for Zero?
>>    >>
>>    >> I was surprised too. It seems some required configure/JDK changes got
>>    >> integrated into 8u already.
>>    >
>>    > Okay, looks fine for me then!
>>    >
>>    > I have also ran bootcycle-images with this patch on AArch64 without problems.
>>
>> I wouldn't bet on the atomics being correct. It'd be nice to have a
>> jcstress run. Not that we expect anyone to actually use zero on
>> AArch64, but it'd be a very useful sanity check.
> 
> Oh. A few tests have failed:
> 
>     [FAILED] o.o.j.t.atomics.longs.AtomicLongPairwiseTests.IncAndGet_CAS
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_boolean_double
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_byte_double
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_byte_long
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_double
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_long
>     [FAILED] o.o.j.t.memeffects.basic.volatiles.volatile_short_long

...and I wonder if that is because src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp misses 
any mention of AArch64. Which (AFAICS) means OrderAccess barriers are reduced to compiler barriers.

But hey, those definitions are missing even in the head JDK!

-- 
Thanks,
-Aleksey



More information about the jdk8u-dev mailing list