RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory
Alan.Bateman at oracle.com
Tue Jan 22 16:12:22 UTC 2019
On 18/01/2019 14:28, Peter Levart wrote:
> ...unless you actually want users to construct their own MapMode(s),
> like you mentioned is the case with FileChannel.open() and
> FileAttribute interface. But there this makes sense because the
> backend (FileSystem) is also pluggable, so users can define their own
> FileSystem implementations that consume their own FileAttribute(s)...
> Are you proposing to add an spi for MappedByteBuffer's here? That
> would be an overkill for this feature, I think...
No, we definitely don't want to go there as buffers are closed
abstraction. Instead, this is just about allowing the JDK to support
additional map modes beyond those specified by FileChannel.map. If you
create your own MapMode and call the map method with it then it will be
rejected, probably UOE. With the suggestion, a JDK-specific module would
define READ_WRITE_SYNC and you could pass that mode to FileChannel.map.
There's a bit of plumbing needed make that work but there are examples
of this already (e.g. socket options and file open options).
More information about the hotspot-compiler-dev