JEP proposed to target JDK 14: 352: Non-Volatile Mapped Byte Buffers

[Andrew Dinn]

Hi Maurizio,

On 11/07/2019 21:41, Maurizio Cimadamore wrote:
> this looks like solid work - and I wanted to take the opportunity to
> link it to some other work that's going on in the area of allowing
> access to foreign memory from Java programs, which is happening under
> Project Panama, and known there as 'foreign memory access API' [1, 2]. I
> think there are many useful overlaps between what's in JEP 352 and what
> we're doing in the Panama memory access API, and it would be nice at
> some point to explore some options to add support for 'mapped'
> MemorySegment to the Panama memory API. That would be a great way to
> free developers from some of the "limitations" that the ByteBuffer API
> has in this context, such as the not-so-deterministic, GC-based
> deallocation model, and < 2GB addressing space (not really faults of the
> BB API itself - but, rather, distortions that stem from attempting to
> use this API as a general purpose memory access API).
> 
> [1] - http://cr.openjdk.java.net/~mcimadamore/panama/memaccess.html
> [2] -
> http://cr.openjdk.java.net/~mcimadamore/panama/memaccess_javadoc_v4/javadoc/jdk/incubator/foreign/package-summary.html
Thank you very much for linking this JEP to your much more weighty work.
As you say, the small extensions it proposes, while they benefit from
being immediately available, useful and therefore expedient, are rather
unfortunately constrained by incidental features of the ByteBffer API.

Panama does look like a great way to bypass those limitations. I am very
interested to pursue this link further, especially to see how we can
provide a bridge for users employing the proposed JEP capability to what
Panama might offer. I will study the linked documents and relay whatever
thoughts or feedback it triggers.

regards,


Andrew Dinn
-----------