On Tue, 18 Apr 2023 22:26:03 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/foreign/Linker.java line 202: >> >>> 200: * Due to limited ABI specification coverage, all the native linker >>> implementations limit the function >>> 201: * descriptors that they support to those that contain only so-called >>> <em>canonical</em> layouts. These layouts >>> 202: * have the following restrictions: >> >> I think it's better to phrase this more or less as: >> >> A canonical layout has the following characteristics: >> * Its alignment constraint is equal to its natural alignment >> * If the layout is a value layout (linkplain), its byte order matches that >> of the platform in which the JVM is executing (link to nativeOrder()) >> * If the layout is a group layout (linkplain), it must not contain more >> padding layout (linkplain) elements than those strictly necessary to satisfy >> the alignment constraints of the non-padding elements of the group layout. > > Also, isn't it the case that, for structs, we want the size of the layout to > be a multiple of its alignment constraint? The third item in the list is for group size needing to be a multiple of the alignment constraint, the forth item refers to that, so I'll keep the ordered list. WRT byte order: I think it's fine to just say "native byte order". Keep it simple. Or do you think there might be confusion about the meaning of "native"? (It looks like not even ByteOrder::nativeOrder explains that term: https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/nio/ByteOrder.html#nativeOrder()) "padding layout elements" is not quite right I think, since they also have to be the right size. I think saying just "padding" is more accurate (and simpler). I'll switch to using plain links instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13164#discussion_r1171971387
