[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