New candidate JEP: 412: Foreign Function & Memory API (Incubator)

[Maurizio Cimadamore]

Hi,
as other have replied in this thread, while it is tempting to try to 
compress the information more (we surely have tried many times!), down 
to a single vector of types - in reality there are truly two things 
which needs to be described:

* which Java signatures will Java clients use to interact with the 
method handle (this is not dissimilar to the method type specified in a 
MethodHandle.Lookup call)
* which C signature will the downcall method handle target

A single Java type (e.g. MemorySegment) can correspond to many different 
C types (e.g. all structs and union types).

While in the reverse direction the freedom is not that dramatic, there 
is some freedom - for instance on 64 bit systems, a C_SHORT can be 
mapped back to a Java short, or into a Java char type (as they are both 
16 bits). Additional degrees of freedom might arise at a later point: we 
might have additional Java carrier types for vectors (see vector API), 
half floats, long doubles, etc. (especially with the help of Valhalla), 
so e.g. it is a legitimate for a user to decide whether to map a C "long 
double" back to a Java double (with some loss), or to use a more 
lossless carrier. So, in the general case, the relationship between Java 
types and C descriptors is N:N, and, because of that, inference doesn't 
seem like a good way to go.

That said, the presence of the method type is, I think, also beneficial, 
as Java types are laid out explicitly; if things are inferred from the 
function descriptor, some of the failures that are now detected at 
downcall method handle creation will only be detected when the method 
handle is first invoked (that is, when the user expectation about what 
the inference process happens to be incorrect).

Cheers
Maurizio


On 22/04/2021 22:42, Gerard Ziemski wrote:
> hi,
>
> I read this JEP only once so far, but one thing that I immediately noticed was whether MethodType is really necessary when constructing a MethodHandle, or whether that info can be inferred from FunctionDescriptor as in this given example:
>
>
> MethodHandle qsort = CLinker.getInstance().downcallHandle(
>          LibraryLookup.ofDefault().lookup("qsort").get(),
>          MethodType.methodType(void.class, MemoryAddress.class, long.class,
>                                long.class, MemoryAddress.class),
>          FunctionDescriptor.ofVoid(C_POINTER, C_LONG, C_LONG, C_POINTER)
> );
>
> Seems to me that FunctionDescriptor and MethodType describe the same layout?
>
>
> cheers
>
>> On Apr 22, 2021, at 1:27 PM, mark.reinhold at oracle.com wrote:
>>
>> https://openjdk.java.net/jeps/412
>>
>>   Summary: Introduce an API by which Java programs can interoperate with
>>   code and data outside of the Java runtime. By efficiently invoking
>>   foreign functions (i.e., code outside the JVM), and by safely accessing
>>   foreign memory (i.e., memory not managed by the JVM), the API enables
>>   Java programs to call native libraries and process native data without
>>   the brittleness and danger of JNI.
>>
>> - Mark