RFR: 8314949: linux PPC64 Big Endian: Implementation of Foreign Function & Memory API

[Maurizio Cimadamore]

On Fri, 25 Aug 2023 07:36:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/ABIv1CallArranger.java line 33:
>> 
>>> 31:  * PPC64 CallArranger specialized for ABI v1.
>>> 32:  */
>>> 33: public class ABIv1CallArranger extends CallArranger {
>> 
>> Wouldn't it be more natural for CallArranger to have an abstract method (or even a kind() accessor for the different kinds of ABI supported) and then have these specialized subclasses return the correct kind? It seems to me that setting the `useXYZAbi` flag using an instanceof test is a little dirty.
>
> I had something like that, but another reviewer didn't like it, either. Originally, I had thought that the v1 and v2 CallArrangers would get more content, but they're still empty. Would it be better to remove these special CallArrangers and distinguish in the base class?

It seems to me that what you are doing is similar to what was done for aarch64, which was dealt with using very simple subclasses:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64CallArranger.java
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64CallArranger.java
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/windows/WindowsAArch64CallArranger.java

In your case there's less difference, but I think we should follow the same idiom for both.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15417#discussion_r1305396592