Part 1 Proposal for JDK-8264594

[leerho]

Maurizio,

This is great.  You have opened up several new possibilities and I'd like
to explore some of them.

1. The use of *Object*, a la *System.arrayCopy(Object src, int srcPos,
Object dest, int destPos, int length).*
There are several interesting ideas (and concerns) that spin off of this
idea.

   1. First, is that System.arrayCopy() is a native method so all the work
   is under the covers, which I cannot see (I don't know how to find the C++
   code that implements this method.)
      - Advantage: This would greatly reduce the number of methods needed
      (as you pointed out).
      - Concern: Performance.  I would think we would be moving work that
      could be done at compile time (e.g., what type of array is it?) to run
      time.   Or would Hotspot figure this out ?
      - Advantage: Potentially this could allow boxed array types as the
      native code could just figure this out and do the right thing.
      - Concern: because of its similarity to *System.arrayCopy()*, the
      user might be tempted to use it for array types that are completely
      inappropriate.  (Just throw an exception.)
   2. This *Object* idea also led me to: What if we extended the C++ code
   underneath arrayCopy() to allow one or both of the Objects to be a
   MemorySegment?
      - Make it clear that both Pos arguments and the length argument would
      have to be in bytes and these arguments would have to become longs.  This
      fact alone will kill this idea as it raises all kinds of issues. Terrible
      idea, forget this one!
   3. What about this idea. Two *static void arrayCopy-type* methods in
   MemorySegment: (or 4 if we overload with ByteOrder):
      - *copyToArray(MemorySegment srcSegment, long srcOffsetBytes, Object
      dstArray, int dstIndex, int dstElements)*;
      - *copyFromArray(Object srcArray, int srcIndex, int srcElements,
      MemorySegment dstSegment, long dstOffsetBytes)*;
      - If these are implemented as native methods AND if there is not a
      runtime performance burden, THIS would be elegant!

2. "split" the overloads between copyFrom and toXYZ arrays.

   - Is this what you had in mind? (7 or 14 of these pairs)
      - *int[] dstArray = srcSegment.asSlice(long offsetBytes, long
      lengthBytes).toIntArray(int[] dstArray, int dstIndex, int dstElements)*
      ;
      Because toIntArray returns an array, this changes the behavior
      whereby the array is provided and returned. Clunky.
      This requires specifying the length twice, once in bytes, the other
      in elements. :-(
      - *dstSegment.asSlice(long offsetBytes, long
      lengthBytes).copyFrom(int[] srcArray, int srcIndex, int srcElements)*
      ;
      This also requires specifying the length twice, once in bytes, the
      other in elements.  :-(
   - Perhaps you meant this? (7 or 14 of these pairs)
      - *int[] dstArray = srcSegment.toIntArray(long srcOffsetBytes, int[]
      dstArray, int dstIndex, int dstElements)*;
      This still has a clunky return of the dstArray that isn't really
      needed. Perhaps this variant would be a void return?
      - *dstSegment.copyFrom(int[] srcArray, int srcIndex, int srcElements,
      long dstOffsetBytes)*;

I think I like 1.3 the best.

   - Only 2 or 4 new methods (let's assume 4)
   - But it may require the most under-the-covers work, which would be in
   C++.  I'm hoping some of the code from System.arrayCopy() could be
   leveraged.

*Note*: I think there is a good reason why MemoryAccess overloads all the
methods with ByteOffset set to the default: and that is because 90% of the
use-cases and users want the default and don't really want to always be
specifying ByteOrder, even if it is only a static method and quite fast; it
would still be viewed as unnecessary!  If we are choosing between only 2 or
4 added methods, overloading with the default ByteOrder should not be a big
deal.

Cheers,

Lee.




On Tue, Apr 27, 2021 at 2:13 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 27/04/2021 21:50, Maurizio Cimadamore wrote:
> > is just one native call away, after all.
>
> Whoops - I meant "static" not, "native", of course :-)
>
> Maurizio
>
>