Comparing the performance of Panama with JNI, JNA, and JNR - based on Java 21

[Maurizio Cimadamore]

On 24/03/2023 19:07, Glavo wrote:

> 2. StructLayout must manually specify all padding
>
>     Can we provide a convenient method for automatically padding
>     between fields based on alignment?
>     The current structLayout method is annoying for situations where
>     you need to manually simulate the layout of a C struct.
>
>
I'd like to return to this topic, since we have spent some more time 
thinking about it.

First, we have added extra eager checks (as also suggested by Michael) 
so that non-sensical layouts are ruled out at creation:

https://git.openjdk.org/panama-foreign/pull/824

On the topic of adding a more user-friendly struct factory, I am less 
convinced that such an API really belongs in MemoryLayout. First, memory 
layouts are fairly general, and can be used to model things that are 
*not* C structs. Consider this:

|structLayout(JAVA_LONG, JAVA_INT) |

This layout is valid, and you can dereference both struct fields w/o 
issues using var handles. That said, the size of this layout (12) is not 
a multiple of its alignment (8), so if you nest this layout inside a 
sequence layout, you would get an IllegalArgumentException. But you 
might never need to create an array of these things, in which case a 
memory layout such as the one above is perfectly sensible. The C 
language, on the other hand, enforce specific constraints on its structs 
- one such constraint is that all struct layouts must have a size that 
is a multiple of their alignment. Which means that the above struct 
layout does not correspond to any C struct declaration. /And that’s ok/.

On top of that, even if C structs and FFM struct layouts agreed 100%, it 
would still make sense for memory layouts to expose a “raw” struct 
layout factory, for clients (maybe tools?) wanting to validate the 
correctness of their assumptions.

So, for the time being, I think it would be better to keep the FFM API 
the way it is, and have all the various layout factories act 
transparently in a “what you see is what you get” manner. The existing 
factories are meant to be primitive building blocks, and their primary 
goal is to be predictable, general and easy to understand. (After all, 
any non-primitive factory we might add in the future /needs/ to be 
explained in terms of some simpler factory).

Does this mean that there will never be higher-level functionalities? 
Not necessarily, even though such functionalities might well end up 
falling outside the scope of JEP 442 (and its predecessor JEPs). Some 
work Per did in this area [1, 2] shows that there are functionalities 
that are useful when working with layouts, even though we might not 
necessarily have found the best place where to put them. Also, I believe 
at some point there will be some story for /transforming/ a layout into 
another, so again there’s a question of where to put some canned 
transforms (e.g. to swap endianness of all value layouts in a layout). I 
think a “higher-level” factory for creating C-like layouts belong in the 
same place as these functionalities. They are nice-to-have, but not 
“primitive” enough, I think, to deserve a spot in the MemoryLayout class 
(evidence of that is that it is fairly easy to build such a factory 
externally [3]).

Maurizio

[1] - https://git.openjdk.org/panama-foreign/pull/715
[2] - https://github.com/openjdk/panama-foreign/pull/695
[3] - 
https://github.com/openjdk/panama-foreign/blob/foreign-memaccess%2Babi/src/java.base/share/classes/jdk/internal/foreign/Utils.java#L223

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230329/36b30ed8/attachment.htm>