New candidate JEP: 370: Foreign-Memory Access API

[David Lloyd]

On Thu, Nov 28, 2019 at 11:24 AM Vladimir Ivanov
<vladimir.x.ivanov at oracle.com> wrote:
>
>
> >> 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!).
>
> Yes, stack allocation looks attractive, but in practice its usability is
> quite limited. (IMO thread-local arena-style memory allocator is more
> practical.) And it makes some assumptions about how threads and stacks
> work which are aren't specified by JVMS, but are implementation details.
> For example, how will it interact with Project Loom?
>
> Leaving high-level considerations aside, there's already a way to build
> stack allocator without any JVM assistance on top of JNI (though
> definitely not the most efficient and performant one):
>
>    - do a native call;
>    - allocate memory on stack inside native frame;
>    - do an upcall to user-provided callback and pass a pointer to
> allocated memory;
>
> On Java level it can be exposed as:
>
>     <R> native R allocateOnStack(long size, LongFunction<R> task);
>
> What Memory Access API can add to it is safety: instead of passing raw
> pointer to stack memory with all safety concerns associated with it, it
> can be wrapped into a MemorySegment before returning it to the user and
> on a way back closed, thus effectively forbidding any illegal accesses
> (both temporal and spatial) and in completely transparent way:
>
>     <R> R withSegmentOnStack(long size, Function<MemorySegment,R> task);
>
> As a performance optimization, JIT can then intrinsify the native method
> and directly allocate memory on stack without the need for auxiliary
> native frame. It'll provide alloca-like behavior while considerably
> simplifying JVM support.

That's exactly what I'm looking for: safety plus speed, for the
primary purpose of native invocation.  As a bonus, having the memory
access API provide this capability could mean that it could, on the
back end, do something other than strictly stack-based allocation
(e.g. allocating from a TLAB for larger objects).

> It definitely looks very interesting in the context of low-level ABI and
> native invokers, but IMO stack allocation is not a prerequisite for
> Memory Access API and the API shouldn't wait for it to be released.
>
> After there's more data available from ABI experiments, we'll be in a
> better position to decide how to proceed (either add it to Memory Access
> API, build a separate API on top, or even drop it).

Makes sense, it's still early.  But now the seed is planted. :)
-- 
- DML