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

[John Rose]

On Apr 10, 2021, at 2:17 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com<mailto:maurizio.cimadamore at oracle.com>> wrote:

I like the previous spliterator proposal better for parallel
streams, because I think it interacts better with parallel
decomposition.

Please clarify meaning of "previous proposal".

I meant the status quo of what’s in the incubation release,
as modified by your PR.  That’s as opposed to the idea
(which I thought I saw) of a stream which immediately
divides its input MemorySegment into a large number
of small segments, without subdividing them first into
a medium number of medium segments.  That’s what
I think Remi meant by a “sequential stream”.  And
sometimes you want to avoid the overhead of parallel
decomposition, but in the case of large bulk memory
I suppose parallel decomposition is probably the tool
of choice.

Isn’t it true that spliterators will tend to cut the bulk data
in half (or other large chunk) recursively until the cores
are busy, and then iterate?  In that case, you only get enough
sub-segments to (safely!) manage the parallel decomposition.
If you stream over small slices, then you are slicing all the
time.  Where would the per-core vectorized loops get to
work?

Is this a critique against MemorySegment::stream/slices in general, or?

Not a critique.  I think MS streams, including parallel-sliced
ones, are great.

— John

P.S. It would be nice, someday, if we could also have some sort
of bounds check, specific to each worker thread, that enforced
the worker thread staying in its own chunk.  I think we don’t
have that yet because we require parallel decomposed MS’s
to be shared.