[foreign-memaccess+abi] RFR: 8295290: Add Windows ARM64 ABI support to the Foreign Function & Memory API [v3]

[Saint Wesonga]

On Tue, 10 Jan 2023 17:42:16 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> There are 2 primary differences between the Windows ARM64 ABI and the macOS/Linux ARM64 ABI: variadic floating point arguments are passed in general purpose registers on Windows (instead of the vector registers). In addition to this, up to 64 bytes of a struct being passed to a variadic function can be placed in general purpose registers. This happens regardless of the type of struct (HFA or other generic struct). This means that a struct can be split across registers and the stack when invoking a variadic function.
>> 
>> This change introduces tests that compute the sum of the fields of structs containing 1-4 ints, floats, and doubles to verify that each field is correctly assigned a register or stack location when invoking a variadic function (both when the struct can be passed entirely in registers as well as when the struct spills onto the stack).
>> 
>> For details about the Foreign Function & Memory API, see JEP 434 defined at https://openjdk.org/jeps/434
>> 
>> The Windows ARM64 ABI conventions are documented at https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions
>> 
>> This work builds on @lewurm / Bernhard's branch at https://github.com/lewurm/openjdk/commits/foreign-windows-aarch64
>
> Saint Wesonga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Remove redundant check
>  - Delete VaList
>  - Merge branch 'foreign-memaccess+abi' into WindowsAArch64ABI
>  - Merge branch 'foreign-memaccess+abi' into WindowsAArch64ABI
>  - Update Windows FFM implementation to match latest Preview API
>  - Merge branch 'foreign-memaccess+abi' into WindowsAArch64ABI
>  - Simplify newly added tests in TestVarArgs
>  - Move storage decisions into StorageCalculator
>  - Remove toSessionImpl method
>  - Remove unnecessary null check
>  - ... and 2 more: https://git.openjdk.org/panama-foreign/compare/5427e47b...ccae2d80

> Few more comments inline.
> 
> FWIW, I think CallArranger can be cleaned up further, and I've been playing with a patch [1](https://github.com/openjdk/panama-foreign/compare/pull/754/head...JornVernee:panama-foreign:Refector_CallArranger). But I'll file a followup PR for that.

@JornVernee just to clarify, do you expect more refactoring of the CallArranger in this PR or will that be subsumed by your patch?

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

PR: https://git.openjdk.org/panama-foreign/pull/754