[foreign-memaccess] [Rev 02] RFR: JDK-8241772: MemorySegment should offer a spliterator

[Paul Sandoz]

On Fri, 27 Mar 2020 22:19:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch rethinks how shared memory segment work; up to now, our story for sharing a segment across multiple threads
>> has been to support a ref-counting strategy (see MemorySegment::acquire). While this mechanism is very general, and can
>> be used to support different idioms, it also significantly increases the complexity surface of the memory access API;
>> also, the constrained nature of the acquire() mechanism is, in some occasions, still not general enough to support all
>> the use cases - the cases which cannot workaround the confinement guarantees.  Because of this, I believe it is a
>> better course of action to restrict the memory segment sharing capabilities to those use cases that are well-behaved
>> enough: parallel processing of a segment via divide-and-conquer. This can be achieved rather succintly by having a
>> segment offering a spliterator, which can then be used to create e.g. a parallel stream (see example in the test), or
>> to create a fork/join recursive action (again, see test for some examples).  Of course we will need some kind of escape
>> hatch for when a "true" shared segment is required - this could be provided by either offering a way to register a
>> segment against a Cleaner, and giving up the deterministic deallocation guarantees in that case; the need for such
>> GC-managed segment has already arisen when dealing with native interop use cases (e.g. a binding might need to create
>> long-lived constants which are basically never closed).  Alternatively, the escape hatch could be an unsafe segment
>> which is not thread confined, and can be closed from any thread (this is a solution that, I'm sure, some of the people
>> I've chatted with will appreciate).  Either way, it is important to realize that the long-lived, shared segment is
>> pretty far from the design center of the memory access API - whose goal is, after all, to improve over some of the
>> things that direct buffers aren't so great at. If you are after a big, long-lived slab of shared memory, chances are
>> that the ByteBuffer is already good enough at handling those.  Where the pressure comes from, is, we believe, in those
>> allocation-intensive scenarios, where the cleaner mechanism (which is the only choice for direct buffers) is simply not
>> enough to guarantee a reasonable throughput. These are also the cases that are crucial to achieve an efficient native
>> interop support.  So, let's focus on what this API does best - which is managing confined memory segments - and let's
>> build on that to cover the divide and conquer use cases (through the spliterator machinery).  Sidebar: for those of you
>> worried that the lack of acquire() will make native interop harder, we are planning to _remove_ confinement
>> restrictions from addresses obtained from native libraries - meaning that if you get a MemoryAddress from a native
>> library, you will be able to share it with any thread you want, and such threads will be able to dereference the
>> address w/o any need to workaround the confinement guarantees.  Moving forward, there are other things we need to do
>> after this patch is done - as mentioned, providing a GC-backed escape hatch would probably be a good addition; but we
>> also have to add more ways to share a segment with other threads in serial-confinement mode (e.g. one thread at a
>> time); the main operation we're looking at is an 'handoff' operation which replaces the owner thread with a different
>> one (useful in producer/consumer use cases) and, possibly, also a detach/attach pair of operations which can be used to
>> temporarily remove ownership from a segment, and then have it picked up by a second thread - this is is effectively
>> similar to handoff, but where the two threads don't know each other.  In addition to that, I'm planning to add a bunch
>> of helper methods to SequenceLayout to help with reshaping and flattening sequence layouts; this operation is very
>> useful when a client needs/want to define a splitearator which works on multiple elements at a time (see the
>> ParallelSum benchmark for an example). I'll be filing a PR for this separately.  Cheers Maurizio
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed a review comment

Marked as reviewed by psandoz (Committer).

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

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