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

Martin Doerr mdoerr at openjdk.org
Fri Oct 13 14:31:47 UTC 2023


On Fri, 13 Oct 2023 13:39:11 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Just to clarify, is the ABI equal to what is described in this table: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes ?
>> 
>> This shows `double` having 8-byte alignment, but being 4-byte aligned when not the first member of an aggregate.
>
>> Okay, so it sounds like Java double on AIX is still 8-byte aligned, but the native double is 4-byte aligned?
> 
> Correct within structures. I believe they are always 8-byte aligned except in structures which are packed more densely.
> 
>> In that case, I'd say that passing `JAVA_DOUBLE` as an argument resulting in an exception, is expected behavior. 
> 
> Hmm... Should we disallow to pass 8-byte aligned double values? Fixing the tests is a good thing. But, I have a different concern: I guess many developers may use them without testing on AIX. This would cause problems which we could avoid by supporting 8-byte aligned doubles in addition.
> 
> What about adding
> 
> layouts.put("jdouble", ValueLayout.JAVA_DOUBLE.withByteAlignment(4));
> layouts.put("aligneddouble", ValueLayout.JAVA_DOUBLE); // allowed for usage outside of structures
> 
> ?

> Just to clarify, is the ABI equal to what is described in this table: https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=data-using-alignment-modes ?
> 
> This shows `double` having 8-byte alignment, but being 4-byte aligned when not the first member of an aggregate.

Interesting! This matches my understanding. I can see that doubles are 4-byte aligned within structures. The 8-byte alignment of the first member is already established by the allocation alignment.

I have only read the ABI documentation for linux. IBM will have to cover AIX specific details if there are more questions.

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

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


More information about the hotspot-compiler-dev mailing list