[foreign-memaccess+abi] RFR: 8268743: Require a better way for copying data between MemorySegments and on-heap arrays

[Uwe Schindler]

On Tue, 15 Jun 2021 12:48:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > But we have no solution for larger sizes like float[] or long[] arrays?
> 
> Not for now - the real solution is to fix the performance woes which makes the implementation do all these workarounds for longs vs. ints. That said, I'd be curious, once this is integrated, if you could do a quick validation and re-run that benchmark where you were seeing lots of byte segment wrappers in the heap and make sure at least that behaves as expected.

For sure.

@rmuir and I already discussed about that. From what we understand: `readLong(long[], offset, count)` in our case is never reading more than 64 longs because of the limitations of PFOR algorithm inside Lucene. So we would remove the specialization in MemorySegmentIndexinput and the superclass will use a loop of readLong() instead. This also goes in line with your hint to copyMemory liveness check overhead. The readFloat variant we have is reading a maximum of 1024 float dimensions for our vector suppotr, I will do some quick investigations later, but I tend to remove the specialization, too. In future we will use FloatVector from vector API and that should possibly be wrapped over the memory segment (see also https://github.com/apache/lucene/pull/18 for some quick investigations). For the longs and the PFOR algorithm we may also use a vectorized approach in future, so readFloat() and readLongs() will go away and be replaced to return a FloatVector/LongVector view on the memory segmen
 t (using ByteBuffer view or directly once panama and vector can share APIs).

The biggest problem on our side is our implementation of `readBytes(byte[], offset, count)` which is fixed here.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/560