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

Andrew Dinn adinn at redhat.com
Fri Jul 20 14:31:22 UTC 2018


On 20/07/18 15:05, Alan Bateman wrote:
> On 20/07/2018 14:50, Andrew Dinn wrote:
>> I have finally managed to draft a JEP to formally present the proposal I
>> circulated a month or two back regarding support for MappedByteBuffer
>> access to non-volatile memory.
>>
>> JEP JIRA:
>>    https://bugs.openjdk.java.net/browse/JDK-8207851
>>
>> The JEP references a re-implementation of the proposed API:
>>
>>    http://cr.openjdk.java.net/~adinn/pmem/webrev.01/
>>
> The JEP proposes adding a map_persistent method to FileChannel. An
> alternative may be to just add new MapModes that you can specify to the
> existing map method. It would reduce the API surface and I think fit
> better with the existing API.
Doh! that's a good idea (I wish I had thought of that :-)

I'll admit that it looks a tad counter-intuitive to specify the storage
characteristics of the data as part the access mode e.g.

class MapMode {
  public static final MapMode READ_ONLY = ...
  public static final MapMode READ_WRITE = ...
  public static final MapMode PRIVATE = ...
  public static final MapMode READ_ONLY_PERSISTENT = ...
  public static final MapMode READ_WRITE_PERSISTENT = ...
  . . .
}

However, it would make the API a damn sight neater.

Also, there is still the question as to whether existing FileChannel
implementations would correctly reject these new modes if passed them i.e.

  if (mode == MapMode.READ_ONLY) {
    ...
  } else if (mode == MapMode.READ_WRITE) {
    ...
  } else {
    ...
  }

Thoughts?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


More information about the core-libs-dev mailing list