On Sat, 28 Sep 2024 06:55:11 GMT, Vladimir Kozelkov <d...@openjdk.org> wrote:
> Sorry for being late, but I came with a new batch of weird layouts Nice examples, thanks. Your examples seem to work under the assumption that e.g. a sequence of padding, or a struct that contains only padding can make sense when used only as a way to provide padding. E.g. if I need a padding of 3 bytes (e.g. because you need `char` followed by `int`), your expectation seems to be all the cases below should work: 1. paddingLayout(3) 2. paddingLayout(1) + paddingLayout(2) 3. paddingLayout(2) + paddingLayout(1) 4. struct layout whose element layouts are either 1, 2 or 3 5. sequence layout of size 1, whose element layout is either 1, 2 or 3 6. union layout with field (1) etc. All the above are possible ways to say "only 3 bytes" of padding. That said, if we accept all these, then we'd have to specify what the rules to make sense of these layouts actually are, by coming up with abstract "reduction" rules to compute a final padding layout given some more complex layout that contains only padding. While this is possible, it strikes me as too convoluted an approach, and I'm more at ease with stricter rules on what the Linker accepts. IMHO, the rules should ban: * sequence layout with padding element (just use padding) * struct/union layout with only-padding fields (again, just use padding) * consecutive padding fields (client should merge them) When writing this, I realize the last bullet above might be problematic for jextract: jextract models unsupported types (e.g. `long double` in x64) as padding. So I wonder what happens if two fields of unsupported types are found next to each other... > // valid (why?) > var struct = MemoryLayout.structLayout(JAVA_BYTE, padding1, padding2, > JAVA_INT); This strikes me as odd, and I'd expect the current PR to reject that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383201305 PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2383207847
