JDK-8221725 : AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: openjdk8u292,11
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • CPU: aarch64
  • Submitted: 2019-03-31
  • Updated: 2021-02-04
  • Resolved: 2019-04-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 8 Other
11.0.5Fixed 13 b15Fixed 8u281Fixed openjdk8u292Fixed
Related Reports
Relates :  
JDK-8221408 - Windows 32bit build build errors/warnings in hotspot
Relates :  
JDK-8257192 - Integrate AArch64 JIT port into 8u
Description
AArch64:

* For target hotspot_variant-server_libjvm_objs_ad_aarch64.o:
/home/buildbot/worker/jdkX-linux/build/src/hotspot/cpu/aarch64/aarch64.ad: In member function 'virtual void cmpFastLockNode::emit(CodeBuffer&, PhaseRegAlloc*) const':
/home/buildbot/worker/jdkX-linux/build/src/hotspot/cpu/aarch64/aarch64.ad:3448:85: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
     __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place));

CI history points to JDK-8221408 as the suspect. Reverting that patch makes the AArch64 build pass.

I think moving the two constants from the enum made its values denser than the address width, which blows up the warning now.
Comments
This seems fragile in general. Maybe we should make all those enum values static constants with real types, to remove reliance on enum width?
24-08-2019
Fix Request I want to downport 8221408, so I need this, too. Applies clean, no risk as only a cast.
06-08-2019
RFR: http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-March/037534.html
31-03-2019
This makes the build pass: 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:21:05 2019 +0200 @@ -3445,7 +3445,7 @@ // 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
31-03-2019