Thanks a lot Alan! This is very helpful. Best Regards, Sandhya
-----Original Message----- From: Alan Bateman [mailto:alan.bate...@oracle.com] Sent: Monday, January 28, 2019 11:45 AM To: Viswanathan, Sandhya <sandhya.viswanat...@intel.com>; Andrew Dinn <ad...@redhat.com>; Brian Goetz <brian.go...@oracle.com> Cc: core-libs-dev@openjdk.java.net; hotspot compiler <hotspot-compiler-...@openjdk.java.net>; Jonathan Halliday <jonathan.halli...@redhat.com> Subject: Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory 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
