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

Maurizio Cimadamore mcimadamore at openjdk.java.net
Fri May 15 10:41:57 UTC 2020

On Wed, 18 Mar 2020 15:11:24 GMT, Maurizio Cimadamore <mcimadamore 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.

This pull request has been closed without being integrated.


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

More information about the panama-dev mailing list