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

[Uwe Schindler]

On Wed, 16 Jun 2021 10:02:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > To call the new static MemorySegment.copy() method, I still need to wrap the byte[] array, so I should merge in THIS pull request? From looking at your repository it does not seem to have the HeapMemorySegment SMALL change.
> 
> Leave alone this pull request, and just work off the branch I pointed out, which contains the static method. The static method just takes two segments, two offsets (in bytes) and a length, it's like System.arrayCopy.

I will just check both branches separately. First this pull request, if it makes the allocations go away (which looks like it won't). Then the other one.

Give me a few days, will work on this after the conference.

> But let's first verify that this is indeed what's causing the degradation for Lucene. You mentioned that the copy method were called "millions of times" which makes it unlikely for them to be completely "cold" and unoptimized.

That was meant "symbolic". Not sure how often it is called in reality. But from the number of allocations on heap, it seems often. We found similar issues in the past, too: Sometimes Hotspot refuses to optimize a method for unknown reasons. It seems to have to do with how it is called. Sometimes the complexity of code inside Lucene is dramatic. Internals are looking very "C like". Huge methods with complex spaghetti-like logic, randomly calling methods from MemorySegmentIndexInput (previously ByteBufferIndexInput). Most of the logic uses the "iterator/enum" aproach. Search thread gets new document hits by consuming some enum, which itsself calls IndexInput.

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

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