New candidate JEP: 412: Foreign Function & Memory API (Incubator)
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Fri Apr 23 01:05:09 UTC 2021
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
More information about the jdk-dev
mailing list