RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Andrew Haley aph at redhat.com
Tue Sep 25 09:01:03 UTC 2018

On 09/24/2018 09:14 AM, Alan Bateman wrote:

> I'm not questioning the need to support NVM, instead I'm trying to
> see whether MappedByteBuffer is the right way to expose this in the
> standard API. Buffers were designed in JSR-51 with specific
> use-cases in mind but they are problematic for many off-heap cases
> as they aren't thread safe, are limited to 2GB, lack confinement,
> only support homogeneous data (no layout support).

I'm baffled by this assertion. It's true that the 2Gb limit is turning
into a real pain, but all of the rest are nothing to do with
ByteBuffers, which are just raw memory. Adding structure is something
that can be done by third-party libraries or by some future OpenJDK

> So where does this leave us? If support for persistent memory is
> added to FileChannel.map as we've been discussing then it may not be
> too bad as the API surface is small. The API surface is just new map
> modes and a MappedByteBuffer::isPersistent method. The force method
> that specify a range is something useful to add to MBB anyway.

Yeah, that's right, it is. While something not yet planned might be an
alternative, even a better one, the purpose of our faster release
cadence is to "evolve the Java SE Platform and the JDK at a more rapid
pace, so that new features [can] be delivered in timelier
manner". This is timely; waiting for Panama to think of what might be
possible, not so much.

Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the core-libs-dev mailing list