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

Alan Bateman 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).

-Alan.


More information about the hotspot-compiler-dev mailing list