Hi David

On 27/11/2019 14:04, David Lloyd wrote:
On Mon, Nov 25, 2019 at 11:28 AM <mark.reinh...@oracle.com> wrote:
https://openjdk.java.net/jeps/370
One more question!  Well, two I guess.

First, in the interim before Panama or something like it comes to the
main project, will it be possible to pass MemoryAddress kinds of
things to JNI methods (to replace the current "pattern" of sticking
pointer values into `long` fields)?  Could the JNI API be extended for
this purpose?

Fair point. The second step of the Panama effort will allow you to create 'native' MethodHandles - which you can then call as any other method handle. For an example on how to use them, look here [1]. In other words, a native library accepting a pointer will be modeled as a MethodHandle accepting a MemoryAddress. This step is actually not that far away (we are mostly working on the implementation internals at this point), so I don't think there's enough of a reason to provide an interim solution.



Second, what about an API to allocate memory from the stack?  This is
really useful in GraalVM (granted they have a sort-of-Panama-ish way
of calling C functions already, and they're really quite "loose" when
it comes to safety in some regards) and could simplify some things
already, particularly if the pointer could then be passed to a JNI
method.  Given the sensitive nature of stack allocation you'd probably
have to add some extra checks (like checking that the thread matches
on each access and that it is in scope, and you'd probably have to do
the latter via callback like StackWalker does) but it would be pretty
useful nonetheless.

I guess it depends on what the goal is here - if the goal is to 'speed up allocation', there are other ways to skin that cat (and we're actually working on what seems like a very promising direction which we should be able to communicate more publicly soon). But, another related goal would be to be able to express stack allocation in Java directly, so that some of the work for e.g. writing bridge code which goes from Java to native can be expressed in Java directly. While something like this would probably be useful, as an implementation tool (e.g. to implement our own programmable invoker [2]), I don't see that being a priority from a public API perspective (assuming we can make allocation fast enough - that is!).

Cheers
Maurizio

[1] - hg.openjdk.java.net/panama/dev/file/foreign-abi/test/jdk/java/foreign/StdLibTest.java [2] - hg.openjdk.java.net/panama/dev/file/foreign-abi/src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/ProgrammableInvoker.java

Reply via email to