RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot)
Aleksey Shipilev
shade at redhat.com
Sun Mar 31 21:35:38 UTC 2019
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
More information about the hotspot-dev
mailing list