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

[Alan Bateman]

On 28/01/2019 18:39, Viswanathan, Sandhya wrote:
> Hi Alan,
>
> Could you please let us know more on what does it mean to be a jdk-specific feature? How it is to be implemented? An example would be very helpful.
> ByteBuffer is a widely used API and deprecating ByteBuffer any time would make it difficult for more and more Java software frameworks to move up to the latest JDK.
>
In the API docs, you'll see a number of JDK-specific modules with names 
that start with "jdk." instead of "java.". Many of these modules export 
JDK-specific APIs. The jdk.attach module exports the JDK-specific 
com.sun.tools.attach API. The jdk.management module exports the 
com.sun.management API which has defined JDK-specific extensions to the 
management API since JDK 5.

Closer to the feature under discussion are APIs that are extensible to 
allow for support beyond what the Java SE API specifies. The Direct I/O 
feature in JDK 10 defined a JDK-specific OpenOption that you can specify 
to FileChannel.open, e.g.:

   var channel = FileChannel.open(file, StandardOpenOption.WRITE, 
ExtendedOpenOption.DIRECT);

Another example is socket options. Java SE defines  "standard" socket 
options in java.net.StandardSocketOptions but an implementation can 
support many others. The JDK has the jdk.net.ExtendedSocketOption to 
define additional socket options so you can do things like this:

    Socket s = ...
    s.setOption(ExtendedSocketOption.TCP_KEEPIDLE, 5);

The suggestion on the table is to see if we can do the same for file 
mapping modes so that the platform specific MAP_SYNC mode can be used 
with the existing API. This would allow for code like this:

    MappedByteBuffer mbb = fc.map(ExtendedMapMode.READ_WRITE_SYNC, 
position, size);

There's plumbing needed to make this work as the underlying 
implementation would be in java.base but the platform specific map mode 
defined in a JDK-specific module. There are several advantages to the 
approach, the main one is that it doesn't commit Java SE to supporting 
this mode. I'm hoping to meet up with Andrew Dinn at FOSDEM to discuss 
this approach in a bit more detail.

You asked about deprecating ByteBuffer but I don't think there is any 
suggestion to do that here. Once Panama is further along, specifically 
the memory region or scope/pointer API, then interop with ByteBuffer 
will need to be worked out.

-Alan