RFR: 8340205: Native linker allows MemoryLayout consisting of only PaddingLayout [v5]

[Maurizio Cimadamore]

On Mon, 7 Oct 2024 15:08:05 GMT, Vladimir Kozelkov <duke at openjdk.org> wrote:

> > 4. {@code G} contains at least a non-padding member layout
> 
> I reread all the points again, now the fourth one confuses me. Does it mean that now linker will not support empty structures at all?
> 
> Previously you said this:
> 
> > So they should be allowed I think. (We don't currently reject them at least)

The rules are currently quite convoluted as we're trying, as stated above, to define a set of "minimally supported layouts" across linker implementations. That doesn't mean that if a layout doesn't adhere to the rules, it's rejected - it's dealt with in a linker-specific way.

In a discussion offline with @JornVernee we are considering to simplify this section of the linker specification by having *less* rules. The rules are used to state which layouts are well-formed. Think of well-formedness as a sort of check whether a layout is in canonical form. All layouts passed to the linker should adhere to these rules. The Linker can optionally reject more stuff it doesn't support (and that's alluded to, but not covered by the javadoc).

So, we could go about it this way:


A native linker only supports function descriptors whose argument/return layouts are *well-formed* layouts. More formally, a layout `L`is well-formed if:

* `L` is a value layout and `L` is derived from a canonical layout `C` such that  `L.byteAlignment() <= C.byteAlignment()`

* `L` is a sequence layout and all the following conditions hold:
   1. `L.byteAlignment()` is equal to the sequence layout's *natural alignment*, and
   2. `S.elementLayout()` is a well-defined layout

 * `L` is a group layout `G` and all the following conditions hold:
   1. `G.byteAlignment()` is equal to the group layout's *natural alignment*
   2. `G.byteSize()` is a multiple of `G.byteAlignment()`
   3. Each member layout in `G.memberLayouts()` is either a padding layout or a well-defined layout
   4. Each non-padding member layout in `G` follows an optional padding member layout, whose size is the minimum size required to align `E`
   5. `G` contains an optional trailing padding member layout, whose size is the minimum size that satisfies (2)


Note how these new rules are more liberal. But they constraint somehow the set of acceptable layouts, by making ruling out hyper-aligned layouts, or layouts with a non-minimal amount of padding. If a layout fails to adhere to any of the rules above, the `Linker` will fail (this is different from today). It is possible that a linker might come with its own restrictions - e.g. a `Linker` might not support empty structs or packed struct layouts, and so extra checks will be enforced (but it's outside the scope of the javadoc to define precise rules on a per-platform basis).

Does this restacking make things clearer?

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2397260962