[foreign-memaccess+abi] RFR: 8308293: A linker should expose the layouts it supports

[Maurizio Cimadamore]

On Thu, 15 Jun 2023 14:10:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This is another stab at https://github.com/openjdk/jdk/pull/14037
>> 
>> I believe, after some offline discussion, that we have found a more satisfying solution to the problem of JAVA_CHAR being exposed. Jorn suggested that linkers should also provide mappings for JNI types such as `jint`, `jshort` and such (which are aliases for our layout constants anyway). I think that's a great way to bring `JAVA_CHAR` back into the fold.
>> 
>> For now, I decided not to specify support for JNI canonical layouts (but I could do so, if that's preferred). I think the highest priority is to provide some stable mappings for C builtin types (+ `size_t`) as that's what 99% of developers will be struggling with.
>> 
>> API-wise, we just expose a map. In the preovious PR there were questions as to whether the map should be split into two methods. In general I see the following options:
>> 
>> 1. Just expose a map (that's the primitive, other things can derived from it)
>> 2. Expose a map, plus a method to get a canonical layout from a type name (that's the `Charset` approach, which has both `availableCharsets` *and* `forName`)
>> 3. Expose a method to get canonical layout from name, plus a method that returns the set of supported canonical layout names
>> 
>> My (not so strong) preference would be for either (1) or (2).
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 288:
> 
>> 286:             Map.entry("int", ValueLayout.JAVA_INT),
>> 287:             Map.entry("float", ValueLayout.JAVA_FLOAT),
>> 288:             Map.entry("long", CABI.current() == CABI.WIN_64 ? ValueLayout.JAVA_INT : ValueLayout.JAVA_LONG),
> 
> This also needs to cover Windows/AArch64.
> 
> Also, I don't think this will work for the fallback linker. In that case I think we need to get the native types from libffi, and then look at the size and alignment to determine the corresponding layout.

Now that you speak of fallback linker, I'm reminded of Zero, and the fact that it does not support JNI. As such, I believe we're right in not including jint and friends in the javadoc (as some linkers can't support these).

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

PR Review Comment: https://git.openjdk.org/panama-foreign/pull/839#discussion_r1231149663