[foreign-memaccess+abi] RFR: 8264933: Improve stream support in memory segments

[Maurizio Cimadamore]

On Fri, 9 Apr 2021 16:43:41 GMT, Rémi Forax <github.com+828220+forax at openjdk.org> wrote:

> I don't see the point of slicing a segment into slice of one element.
> Can we have a second argument with the maximum size of a sub-segment ?

I have shown already real use cases for it - so there is a point :-)
Most of the times memory segments will be flat arrays of "stuff" - and it will be common, for user, to iterate over that "stuff" and element-wise convert it back to something Java-ish.

So, I'd suggest to stop second guessing use cases - as that's not helping the discussion too much; we already have had a spliterator of segment slices for the past 2 years - this change was a little usability boost to simplify what code was already doing. I think we are turning it into more than it is, really.

The definition of "element" here is fluid - it's whatever layout you pass - can be 4 bytes, or 1K. I also don't get the "maximum size of subsegment". The subsegment has a definite size, that of the layout provided by the user.

But really, at the bottom of it - assuming I have my array of string pointers, w/o this capability I have to do:

String[] strings = new String[n];
for (int i = 0; i < n ; i++) {
    MemoryAddress addr = MemoryAccess.getAddressAtIndex(segment, n);
    strings[i] = CLinker.toJavaString(addr);
}

If somebody wants to write higher level code, why not allowing users to do this:

segment.slices(C_POINTER)
    .map(MemoryAccess::getAddress)
    .map(CLinker::toJavaString)
    .toArray(String[]::new)

If you don't want to use it, because you are afraid of slice creation (or something else), then don't use it - but I'm really struggling here to see why such an API point is considered "bad"/"harmful" which your comments seem to imply.

Could we please be more explicit about what the real concern is here, rather than just expressing subjective opinions like "I don't see the point in doing XYZ" (since clearly if there was no point we wouldn't be filing this PR).

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

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