[foreign-memaccess] RFR: JDK-8241154: Clarify the role of MemorySegments

[Maurizio Cimadamore]

On Thu, 19 Mar 2020 17:45:41 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This patch proposes a restacking of the memory access API. Currently, memory segments are playing a dual role: they are
>> both view of a resource, and they impersonate the resource itself. This creates confusion when thinking about
>> operationssuch as close() and acquire().  The idea put forward by this patch is to put all segments on equal footing;
>> e.g. remove the distinction between normal segments and *acquired* segments. Now *all* segments are, in a sense,
>> acquired from some memory *source*. A memory source, in other words, model the actual memory that the segment is a view
>> of.  Memory sources are unconfined, which makes them ideal to support operation such as registration with cleaners (to
>> allow for automatic cleanup, where needed). Moreover, since we can support many kinds of memory sources, this patch
>> also adds a MappedMemorySource which is specific to mapped segments; such memory source contains methods for syncing
>> contents of memory against the mapped file (e.g. force()).   This split between memory segment and memory source allows
>> us to keep the memory segment API sane, while at the same time providing us room to expand the API in the future to add
>> more memory sources. And it makes the API cleaner too, as we can put methods where they belong (e.g. see difference
>> between MemorySegment::isAlive vs. MemorySource::isReleased).  A javadoc for this refactoring is available here:
>> http://cr.openjdk.java.net/~mcimadamore/panama/8241154_javadoc/javadoc/jdk/incubator/foreign/package-summary.html  Many
>> thanks to Brian, John, Jorn, Paul and Stuart for the feedback which led to this iteration.
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 145:
> 
>> 144:     /**
>> 145:      * Obtains a new memory segment backed by the same memory source as this segment which can be used to access
>> memory associated 146:      * with this segment from the current thread.
> 
> Consider later perhaps: now we have `MemorySource` we could name this method `share` since we have the ability to talk
> about what is shared.

Not 100% sold on `share`. I don't like `acquire` that much, but I think `acquire` suggest some act performed by the
current thread on the underlying memory source (at least that's how my brain parses it). For some reason, `share` seems
to imply that some state change happens in the segment on which the method is called (e.g. we go from confined to
shared mode, which is not really what happens) ?

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

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