New candidate JEP: 370: Foreign-Memory Access API

[Maurizio Cimadamore]

Hi David

On 27/11/2019 14:04, David Lloyd wrote:
> On Mon, Nov 25, 2019 at 11:28 AM <mark.reinhold at 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