RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v25]

Tue May 2 14:51:29 UTC 2023

On Tue, 2 May 2023 14:35:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Do you have for more changes to wait for or would you prefer to have this PR integrated soon?

I don't have anything else in the pipeline at the moment.

> Off topic: I have read parts of the Big Endian ABI and we will need a solution for "An aggregate or union smaller than one doubleword in size is padded so that it appears in the least significant bits of the doubleword. All others are padded, if necessary, at their tail." The tail padding seems to be tricky for Big Endian as we currently access the wrong bytes. I think it could be solved by dirty hacks (shifting) in the backend, but that doesn't sound like a good solution. Do you have a good idea for that? Maybe shift or pad in Java?

In general the assumption of the linker is that any layouts it is given are correct for the given platform/ABI. i.e. it is up to the user to specify the correct padding (and this is where jextract can help out a lot). We do also check that layouts are 'canonical' now (see https://github.com/openjdk/jdk/pull/13164 & [1]). I think this already guarantees that the necessary trailing padding is present (constraint 3)? Did you see the discussion at [2] ? I think we already have Big Endian covered?

[1]: https://github.com/openjdk/jdk/blob/a8bf2acb7db63b508ef169e42a27b9c99178cbb1/src/java.base/share/classes/java/lang/foreign/Linker.java#L200-L209)
[2]: https://github.com/openjdk/panama-foreign/pull/806#discussion_r1122138401

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

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1531615390