Memory Segment efficient array handling

[Uwe Schindler]

Hi,

I can say from the perspective of the Apache Lucene developers, that the issues with how to copy to/from Java arrays to memory segments needs some improvement.

As leerho describes, there should really be some overloads (maybe static ones like System.arraycopy) to excahnge data between a memory segment and a plain java array. We have some draft pull request for Apache Lucene here: https://github.com/apache/lucene-solr/pull/2176

If you look at the methods to copy contents from a memory segment to a byte[], long[] or float[], you see tons of wrapping.

In our investigations, we also see some slowdown in contrast to our ByteBuffer implementation. It is not yet clear if it comes from loops over long instead of ints or if it is caused by the number of object allocations.

Here are our implementations: https://s.apache.org/uhim4 (please don't wonder about the Exception handling: Lucene catches IndexOutOfBoundsExceptions to detect if you have cross-boundary reads - starting in one memory segment; this is done to prevent multiple offset/bounds checks, because ByteBuffer/MemorySegment/arrays do it already; IllegalStateExceptions to detect if the IndexInput was closed by another thread using the shared memory segments)

In short, there should be some way like:
MemoryAccess.copyToArray(MemorySegment src, long srcOffset, int size, array[] target, int targetOffset)
MemoryAccess.copyFromArray(array[] src, int srcOffset, int size, MemorySegment target, long targetOffset)

Additionally, maybe the copyFrom methods should be overloaded to allow offset and size.

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/

> -----Original Message-----
> From: panama-dev <panama-dev-retn at openjdk.java.net> On Behalf Of leerho
> Sent: Thursday, April 1, 2021 2:42 AM
> To: panama-dev at openjdk.java.net
> Subject: Memory Segment efficient array handling
> 
> Folks,
> 
> I am in the process of refactoring our code to use FMA (from JDK16) in our
> application.  But what I find missing is the ability to do efficient
> getting and putting of arrays with MemorySegments.
> 
> What I need to do often is to place part of an existing array into a
> segment at a specific offset and the reverse; getting an array of elements
> from a segment at a specific offset and placing it into an existing array
> at a specific offset.  I have looked closely at MemoryAccess and the latest
> ByteBuffer, but I have not found anything quite as flexible as the
> following.
> 
> What I have ended up doing is creating an entire class of array methods
> like the following:
> 
> public class MemoryArrays {
> >
> >   public static void putIntArray(int[] srcArr, long srcIndex, long
> > numInts,
> >       MemorySegment dstSeg, long dstOffsetBytes) {
> >     MemorySegment srcSeg = MemorySegment.ofArray(srcArr);
> >     MemorySegment srcSegSlice = srcSeg.asSlice(srcIndex << 2, numInts <<
> > 2);
> >     MemorySegment dstSegSlice = dstSeg.asSlice(dstOffsetBytes, numInts <<
> > 2);
> >     dstSegSlice.copyFrom(srcSegSlice);
> >   }
> >
> >   /* ...Same as above for all primitive types... */
> >
> >   public static void getIntArray(MemorySegment srcSeg, long
> > srcOffsetBytes,
> >       int[] dstArr, long dstIndex, long numInts) {
> >     MemorySegment srcSegSlice = srcSeg.asSlice(srcOffsetBytes, numInts <<
> > 2);
> >     MemorySegment dstSeg = MemorySegment.ofArray(dstArr);
> >     MemorySegment dstSegSlice = dstSeg.asSlice(dstIndex << 2, numInts <<
> > 2);
> >     dstSegSlice.copyFrom(srcSegSlice);
> >   }
> >
> >   /* ...Same as above for all primitive types... */
> > }
> >
> 
> I would think that if these methods were built-in to FMA either as a
> separate class or included in MemoryAccess, it would be so much more
> efficient.  All of these separate
> calls to MemorySegment could be eliminated and the entire method inlined
> with a few lines of C++ code.
> 
> If Panama is interested I would be happy to contribute such a class.
> 
> Lee.