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

[Maurizio Cimadamore]

Hi,
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

Cheers
Maurizio

On 09/07/2019 20:52, mark.reinhold at oracle.com wrote:
> The following JEP is proposed to target JDK 14:
>
>    352: Non-Volatile Mapped Byte Buffers
>         https://openjdk.java.net/jeps/352
>
> Feedback on this proposal from JDK Project Committers and Reviewers [1]
> is more than welcome, as are reasoned objections.  If no such objections
> are raised by 23:00 UTC on Tuesday, 16 July, or if they’re raised and
> then satisfactorily answered, then per the JEP 2.0 process proposal [2]
> I’ll target this JEP to JDK 14.
>
> - Mark
>
>
> [1] https://openjdk.java.net/census#jdk
> [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html