RFR: 8308293: A linker should expose the layouts it supports [v3]

[Maurizio Cimadamore]

On Fri, 19 May 2023 23:08:00 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> This look much better. Can we strengthen the specification of `canonicalLayouts` in accordance with the class specification
>> 
>> We can't do more in that method javadoc,  think, as that has to be general enough for all linkers. I think the rules set up in that method javadoc are good - e.g. the set of layouts should be stable (both in terms of names and layout types).
>> 
>> What we can do is to sprinkle some wording in the `nativeLinker` factory - e.g. `the native linker is guaranteed to provide canonical layouts for basic C types <link to the class section>`.
>
>> > This look much better. Can we strengthen the specification of `canonicalLayouts` in accordance with the class specification
>> 
>> We can't do more in that method javadoc, think, as that has to be general enough for all linkers. I think the rules set up in that method javadoc are good - e.g. the set of layouts should be stable (both in terms of names and layout types).
>> 
>> What we can do is to sprinkle some wording in the `nativeLinker` factory - e.g. `the native linker is guaranteed to provide canonical layouts for basic C types <link to the class section>`.
> 
> Yes, that's better.

@PaulSandoz after thinking some more, it seems a bit ad-hoc to guarantee a canonical for "unsigned short", but not for other unsigned types? Possible alternatives (beside keeping what we have in this PR):

* guarantee also all the other unsigned types (e.g. char, int, long and long long)
* do not guarantee unsigned short - but provide a mapping for it anyways
* do not guarantee unsigned short, and do not provide a mapping for it - this means that JAVA_CHAR will not be usable when linking

What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1558110434