On Thu, Nov 28, 2019 at 11:24 AM Vladimir Ivanov <vladimir.x.iva...@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
