[foreign-memaccess+abi] RFR: Add support for high-level functions to copy to and from Java arrays [v2]

Uwe Schindler uschindler at openjdk.java.net
Mon Jun 21 22:43:37 UTC 2021


On Mon, 21 Jun 2021 15:38:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch includes some of the changes from Lee to support a set of static functions to allow bulk copy from Java arrays to segments (and viceversa) in a more succint fashion (so that the user doesn't have to create a temporary heap segment to do the copy).
>> 
>> I've added a new public method to `MemorySegment` which performs an *element-wise* bulk copy; it takes a source segment and a couple of element layouts: the source element layout and the destination element layout. The two layouts must have same size, but can have different alignments (which will be checked against the corresponding segments) and byte orders. If the byte order differs, a bulk copy with swap will be performed. As such, this method generalizes the previous `copyFrom` - as follows:
>> 
>> 
>> copyFrom(srcSegment) -> copyFrom(JAVA_BYTE, srcSegment, JAVA_BYTE)
>> 
>> I've added support for argument type profiling for MemoryCopy static methods to avoid type pollution in cases where same metod is called with different memory segment types.
>> 
>> I've done a pass over the javadoc, and make it more consistent with the rest of the API. I've also reworked the test a bit to use the data provider functionality of TestNG, since all the test cases were similar, except for the carrier type.
>> 
>> There are other cosmetic changes as well, compared to original code from Lee, such as naming of static fields which is now capitalized. Everything else is the same.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove alignment constraints from MemoryCopy layouts

I ran the benchmark on this pull request again (non-tiered batch compilation). Here is the output of PrintCompilation, grepped on `MemorySegmentIndexInput`, our impl. As you see our `readBytes()` and `readLongs()` (both calling `MemoryCopy#copyToArray()`) appears:

thetaphi at serv1:~/benchmark/util$ fgrep MemorySegmentIndexInput ../logs/baseline_vs_patch.my_modified_version.0.stdout
   3010  824   !b        org.apache.lucene.store.MemorySegmentIndexInput::readByte (130 bytes)
   3035  845    b        org.apache.lucene.store.MemorySegmentIndexInput::length (5 bytes)
   6117 1414   !b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::readByte (28 bytes)
   6182 1453   !b        org.apache.lucene.store.MemorySegmentIndexInput::readBytes (50 bytes)
   6281 1489   !b        org.apache.lucene.store.MemorySegmentIndexInput::readLongs (57 bytes)
   6596 1570   !b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::readShort (28 bytes)
   6694 1588    b        org.apache.lucene.store.MemorySegmentIndexInput::ensureOpen (13 bytes)
   6966 1622   !b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::seek (31 bytes)
   6975 1627    b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::getFilePointer (9 bytes)
  11819 2091    b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::<init> (26 bytes)
  11823 2092    b        org.apache.lucene.store.MemorySegmentIndexInput::<init> (103 bytes)
  11883 2095    b        org.apache.lucene.store.MemorySegmentIndexInput::buildSlice (154 bytes)
  12122 2120   !b        org.apache.lucene.store.MemorySegmentIndexInput::readLong (42 bytes)
  15710 2204    b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::slice (9 bytes)
  15711 2205    b        org.apache.lucene.store.MemorySegmentIndexInput::slice (56 bytes)
  15731 2219   !b        org.apache.lucene.store.MemorySegmentIndexInput::clone (37 bytes)
  16198 2242    b        org.apache.lucene.store.MemorySegmentIndexInput$SingleSegmentImpl::clone (5 bytes)


MemoryCopy is also compiled:


thetaphi at serv1:~/benchmark/util$ fgrep MemoryCopy ../logs/baseline_vs_patch.my_modified_version.0.stdout
   6187 1454    b        jdk.incubator.foreign.MemoryCopy::copyToArray (44 bytes)
   6286 1490    b        jdk.incubator.foreign.MemoryCopy::copyToArray (76 bytes)


Not sure why escape analysis does not work. Seems to be a bug or it is again the SMALL segments.

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

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


More information about the panama-dev mailing list