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 API. > 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
