JEP proposed to target JDK 14: 352: Non-Volatile Mapped Byte Buffers
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Jul 11 20:41:22 UTC 2019
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
More information about the jdk-dev
mailing list