RFR: 8262901: [macos_aarch64] NativeCallTest expected:<-3.8194101E18> but was:<3.02668882E10>

[Olga Mikhaltsova]

On Mon, 12 Sep 2022 16:54:38 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This PR is opened as a follow-up for [1] and included the "must-done" fixes pointed by @teshull.
>> 
>> This patch for JVMCI includes the following fixes related to the macOS AArch64 calling convention:
>> 1. arguments may consume slots on the stack that are not multiples of 8 bytes [2]
>> 2. natural alignment of stack arguments [2]
>> 3. stack must remain 16-byte aligned [3][4]
>> 
>> Tested with tier1 on macOS AArch64 and Linux AArch64.
>> 
>> [1] https://github.com/openjdk/jdk/pull/6641
>> [2] https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
>> [3] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack
>> [4] https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-170
>
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot.aarch64/src/jdk/vm/ci/hotspot/aarch64/AArch64HotSpotRegisterConfig.java line 291:
> 
>> 289:                     currentStackOffset += Math.max(valueKind.getPlatformKind().getSizeInBytes(), target.wordSize);
>> 290:                 }
>> 291:             }
> 
> So I'm curious: why not subclass `AArch64HotSpotRegisterConfig` here, or maybe even use an interface, rather than the boolean?

I tried to be closer to the original review https://github.com/openjdk/jdk/pull/6641 that requires only 2 fixes and tried to do only this in order to continue easily.

Could you clarify please what boolean you talk about? `private final boolean macOS;` that was pushed into `class AArch64HotSpotRegisterConfig`, right? I'm hesitating a bit because of the highlighted code.

-------------

PR: https://git.openjdk.org/jdk/pull/10238