AW: Using MemoryAccess with structured MemoryLayout
youngty1997 at gmail.com
Thu Feb 25 23:51:38 UTC 2021
What specifically makes a higher-level Panama API slow beside handles
not being static-final? Is something like this:
NativeIntegerArray array = new NativeIntegerArray(5);
for(int i = 0; i < array.getSize(); i++)
with setPrimitive defined as:
public void setPrimitive(long index, int value)
super.handle.set(this.getSegment(), index *
and getObject as:
public Integer getObject(long index)
return (Integer)super.handle.get(this.getSegment(), index *
(getSegment() and getElementSIze() are just simple returns)
Not as fast as MemoryAccess, assuming the handle is static-final(which
it is)? Or are you saying that a super concise Pointer API specifically
could never be fast? You mention casting, can you go into more detail on
what you mean?
On 2/25/21 12:12 PM, Maurizio Cimadamore wrote:
> Second, if a notion of layout is always associated with a segment, you
> end up in a place where, in order to slice a segment, you probably have
> to follow that operation with some kind of "cast" (e.g. where you set
> the layout of the slice to something else). We've been there with a
> past incarnation of the Panama API, and, while an API like the one you
> describe is probably more suited to closely model a C pointer type,
> that API is not very "primitive" - meaning that it is quite useless if
> you start using a memory segment in a more buffer-like way.
> Note that not _all_ the users of the Memory Access API are interested
> in native interop - many just want to be able to allocate slabs of
> native memory, and free deterministically. So, the more baggage we add,
> the more those non-linker use cases become bloated with unnecessary
> The fine line we're walking in this project is to expose the tools and
> the knob which allow clients to perform memory access/foreign function
> access in the fastest possible way we know of/is possible within the
> JVM. To do that, sometimes (not always) we have to "look the other way"
> when it comes to usability - simply because it would be impossible to
> have an API that is both 100% efficient and 100% usable.
> Even at the jextract level, we are aware that some people would expect
> an API that is closer to the C world (e.g. a `Pointer` type? Struct
> wrappers?) - but again here our approach is to enable people to write
> code which targets the library they wanna use quickly (e.g. way faster
> than using JNI), but w/o introducing unnecessary translation steps in
> the middle - which would make the bindings too slow for some advanced
> use cases.
> I apologize for the (too) big reply - I hope you find it helpful to
> understand the "why not" part of your earlier question.
More information about the panama-dev