[aarch64-port-dev ] RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot)

[David Holmes]

Hi Aleksey,

On 1/04/2019 7:35 am, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8221725
> 
> Fix:
> 
> diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad
> --- a/src/hotspot/cpu/aarch64/aarch64.ad        Sat Mar 30 21:29:37 2019 +0100
> +++ b/src/hotspot/cpu/aarch64/aarch64.ad        Sun Mar 31 23:30:41 2019 +0200
> @@ -3443,11 +3443,11 @@
>       // Check if the owner is self by comparing the value in the
>       // markOop of object (disp_hdr) with the stack pointer.
>       __ mov(rscratch1, sp);
>       __ sub(disp_hdr, disp_hdr, rscratch1);
> -    __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place));
> +    __ mov(tmp, (address) (~(os::vm_page_size()-1) | (uintptr_t)markOopDesc::lock_mask_in_place));
>       // If condition is true we are cont and hence we can store 0 as the
>       // displaced header in the box, which indicates that it is a recursive lock.
>       __ ands(tmp/*==0?*/, disp_hdr, tmp);   // Sets flags for result
> 
> The offending change pulled some enum constants out, which apparently made enum representation much
> smaller. Not sure if putting the constants back does not break Win32 build again. So, instead, fix
> it up in one place that blows up with build warning-as-error. The fix has some level of ewwness, but
> it seems to be the same as what bytecodeInterpreter.cpp is doing. The alternative is to cast to
> uintx, as macroAssembler_arm.cpp is doing.

The fix seems quite reasonable (and again trivial - but I'm not an 
Aarch64 expert ...)

Thanks,
David

> Testing: Linux aarch64 fastdebug build, ad-hoc tests
>