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

[Uwe Schindler]

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 don't want to post too much in this issue as it is not fully related, but it looks this is also affected by the same garbage problem described in https://bugs.openjdk.java.net/browse/JDK-8268743:


PROFILE SUMMARY from 14119950 events (total: 4897631M)
  tests.profile.mode=heap
  tests.profile.count=30
  tests.profile.stacksize=1
  tests.profile.linenumbers=false
PERCENT       HEAP SAMPLES  STACK
49.63%        2430891M      jdk.internal.foreign.MappedMemorySegmentImpl#dup()
28.37%        1389691M      jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#fromArray()
21.43%        1049362M      jdk.internal.foreign.HeapMemorySegmentImpl$OfByte#dup()
0.09%         4624M         org.apache.lucene.util.FixedBitSet#<init>()


See the number of heap samples, this cannot be! The only difference to the JFR heap profile in https://bugs.openjdk.java.net/browse/JDK-8268743 is the order (here we have more dups of the MappedMemorySegment (source from where it is copied).

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

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