JDK-8264199 : [macos_aarch64] Support macOS Aarch64 packed ABI for compiled wrappers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: os_x
  • CPU: aarch64
  • Submitted: 2021-03-25
  • Updated: 2022-03-21
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.
Other
tbdUnresolved
Related Reports
Blocks :  
JDK-8283462 - VMReg should encode stack locations as byte offsets instead of slots
Relates :  
JDK-8253818 - Support macOS Aarch64 ABI for compiled wrappers
Relates :  
JDK-8251280 - JEP 391: macOS/AArch64 Port
Description
This is RFE after JEP-391.
We have marked JDK-8253818 as resolved by JEP-391 but in fact only the workaround (to bailout to interp in problematic cases) was implemented.
Macos_aarch64 uses packed types when they are passed on stack. 
For example uint32 will use only 4 bytes on stack, not 8. Byte will only use 1 byte on stack. Natural type  allignment still in place.
More on the macos_aarch64 abi ( matches ios_aarch64 abi) - https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms#//apple_ref/doc/uid/TP40009020-SW1
Comments
I've suggested a tentative RFE that could help fix this issues. Added as a blocker.
21-03-2022
Just want to get some attention here. This is the only major "flaw" of macos-aarch64 on jdk17/18. Too late for 17, but can be backported to updates later. Not critical tho.
09-08-2021