RFR: 8317545: AIX PPC64: Implementation of Foreign Function & Memory API [v3]

[Maurizio Cimadamore]

On Mon, 16 Oct 2023 13:57:11 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Err, actually using `member.equals(C_DOUBLE)` in the above doesn't work since it still checks alignment. What you have with checking for `ValueLayout` and `carrier() == double.class` is better, but the byte order should also be checked at some point.
>
> Please take a look at commit number 4. I think we need to support both, 4-byte and 8-byte aligned doubles in structures. IBM recommends to use "#pragma align (natural)": "The power suboption is the default to ensure compatibility with existing objects. If compatibility with earlier versions is not necessary, you should consider using natural alignment to improve potential application performance." https://www.ibm.com/docs/en/openxl-c-and-cpp-aix/17.1.1?topic=pragmas-pragma-align
> We could also recommend to use "#pragma align (natural)" for the FFI (and possibly for tests). That would reduce incompatibility with other platforms. I can file a subtask for test adaptation if needed.

Hi @TheRealMDoerr - yes, last weekend I read some bits from the AIX ABI, and it does seem that the more optimized variant is the "natural" variant, as that respects data alignment. As you write "power" seems to be the default, out of some compatibility constraints. But I think the main point that Jorn and I are trying to make is that the fact that "power" behaves in the way it does (e.g. it aligns all double fields after the first one at 4 bytes, rather than 8) has nothing to do with the intrinsic alignment of a double in AIX. E.g. the `double` type in AIX has alignment 8 (and you can check that using `alignof`). Then, it seems like all structs in AIX are compiled as if by using a pack pragma - and _that_ is what causes some double fields to feature a more packed alignment constraints.

Where does this leave us? There are few options:

* As you say, one option would be to just say that on AIX we only support the "natural" variant. This is similar to what we do on other platforms, where we do not support passing packed structs to functions (and what the javadoc of Linker says).
* Another option is to relax the Linker javadoc so that struct layouts are completely Linker specific. This would allow the AIX linker to support whatever alignment is requested.

I have very little experience with AIX, so I'm not in a position to say how much the first option would be perceived as a restriction or not. The nice thing about the first option is that clients of FFM do not have to worry about structs in AIX having special rules. But, perhaps that's an unrealistic goal anyway, and I can imagine other ABIs also going down the path of specifying various packed representations which are not supported by the current javadoc text.

Perhaps, from a logistical point of view, starting off with "natural" for now, and then relaxing the documentation later, and add support for packed structs, would be better, as the changes would be more localized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16179#discussion_r1360770647