[foreign-memaccess] RFR: 8248487: Add static helpers to access segments

[Maurizio Cimadamore]

On 29/06/2020 23:03, Paul Sandoz wrote:
> So many choices…
>
> Would we do this different If not incubating? Should they be lumped together to spread out into the primitive box types?

That's a thought I had. And I think it would also help for things like 
MemoryAddress (e.g. have static getters/setters in memory address).

In general I think there are two strong attractors:

1) keep API organization as is, where things like copy/allocation etc. 
are defined inside MemorySegment; then, since there's loads of 
accessors, find some other place for them (either MemoryHandles, or 
split accessors in the various carriers)

2) drop some of the instance methods we've recently added to 
MemorySegment (copyFrom, mismatch, fill) and re-add them into a sidecar 
class like MemorySegmentS. Then drop all the accessors there.

I find both to be fine choices but with some differences - (1) says that 
MemorySegments is about the primitives, and that static accessors are 
just usability boost - non-primitive methods defined somewhere else. 
With (2) I find it more difficult to draw a line; is MemorySegmentS 
about accessors and some helper methods like fille/mismatch/fill? What 
about creating new segments? What about mapping segments back to arrays? 
It feels like these could live either in MemorySegment or MemorySegmentS 
but we don't have a great answer as to separate between the two.

So, this patch, I guess, attempts at doing something more in sync with 
(1) - leaving all the instance methods where they are, and making the 
API symmetric with respect to:

MemorySegment.ofArray(new int[] { 1 , 2, 3 }).toIntArray();

Which I think is kind of nice.

Maurizio

>
> When/if MemorySegment becomes Addressable should the primitive accessors live on MemorySegment?
>
> I expect it's useful to copyInto a preexisting Java array, since it could be common going to/from native.
>
> It’s tempting to place all the primitive accessors and the array to/from methods to static methods of an MemoryAccess class (which can be imported statically). Then that class becomes busy, leaving the others more focused.
>
>
>
>
>> On Jun 29, 2020, at 1:45 PM, Maurizio Cimadamore <mcimadamore at openjdk.java.net> wrote:
>>
>> On Mon, 29 Jun 2020 16:40:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>>
>>> This patch addresses some usability issues in the foreign memory API. First, it adds several static accessors for all
>>> carrier types in MemoryLayouts (I'm thorn whether to add this in MemoryLayouts or MemoryHandles, suggestions welcome).
>>> These accessors provide an access API that is similar to unsafe - all accessors expect a base address plus a byte
>>> offset. In most cases the accessors can be used and direct VH usage can be dropped, which might make approaching this
>>> API a bit easier.  Secondly, I've added a bunch of helpers to map a segment into _any_ array (as opposed to just
>>> `byte[]`). This makes the API more symmetric, given that, after all we _were_ able to create a segment from _any_ array
>>> (not just `byte[]`).
>> Ideally, we could use varargs notation here, but one problem with that is that, if we ever add ability to allocate
>> "empty" array - as in:
>>
>> MemoryAddress allocateArray(MemoryLayout elemLayout, long size)
>>
> You lost me on this bit.
>
> Paul.
>
>
>> Then we risk ambiguities.
>>
>> If we are ok to never add a method like the one above - after all, one can allocate an empty array as follows:
>>
>> allocateArray(MemoryLayout.ofSequence(size, elemLayout))
>> then this is less of a problem.
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/panama-foreign/pull/221