AW: Using MemoryAccess with structured MemoryLayout

[Ty Young]

What specifically makes a higher-level Panama API slow beside handles 
not being static-final? Is something like this:


NativeIntegerArray array = new NativeIntegerArray(5);

         array.setPrimitive(0, 1);
         array.setPrimitive(1, 2);
         array.setPrimitive(2, 3);
         array.setPrimitive(3, 4);
         array.setPrimitive(4, 5);

         for(int i = 0; i < array.getSize(); i++)
             System.out.println(array.getObject(i));


with setPrimitive defined as:


public void setPrimitive(long index, int value)
{
         super.handle.set(this.getSegment(), index * 
this.getElementSize(), value);
}


and getObject as:


public Integer getObject(long index)
{
         return (Integer)super.handle.get(this.getSegment(), index * 
this.getElementSize());
}


(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
> overhead.
>
> ...
>
> 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.
>
> Cheers
> Maurizio