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

[Thomas Stüfe]

Hi Alexey,

Sorry for breaking aarch64.

Kim and me had discussions about this particular fix, see original rfr
thread for 8221408.

A better solution than adding the cast like you did might be to pull the
offending enum  value out and make it a uintx constant too. Or, I could
revert my change and make it windows only. Or add a dummy value to the enum
and cast that to uintptr, to force its size up.

I think a good solution would be one that prevents such errors for other
enum values and for other platforms as well.

Your patch is fine, if you just want to fix your build now.

..thomas

On Sun 31. Mar 2019 at 23:36, Aleksey Shipilev <shade at redhat.com> 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.
>
> Testing: Linux aarch64 fastdebug build, ad-hoc tests
>
> --
> Thanks,
> -Aleksey
>
>
>