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

[Andrew Dinn]

Hi Alan,

On 18/01/2019 13:32, Alan Bateman wrote:

> I had a brief discussion with Brian about this yesterday. He brought up
> the same concern about using MBB as it's not the right API for this in
> the longer term.  So this JEP is very much about a short term/tactical
> solution as we've already concluded here. This leads to the question as
> to whether this JEP needs to evolve the standard/Java SE API or not.
> It's convenient for the implementation of course but we should at least
> explore doing this as a JDK-specific feature.

I disagree with your characterization of use of MBB as a short term/
tactical solution. Despite not being entirely suitable for the task MBB
is a de facto standard way for many applications to gain direct access
to files of data located on persistent storage. The current proposal is
not, as you characterize it, a quick fix to use MBB as a temporary way
to access NVM storage until something better comes along. The intention
is rather to ensure that the current API caters for a new addition to
the persistent memory tier. The imperative is to allow existing code to
employ it now.

Of course, a better API may come along for accessing persistent storage,
whether that be NVM, flash disk or spinning platter. However, I would
hazard that in many cases existing application code and libraries will
still want/need to continue to use the MBB API, including cases where
that storage can most usefully be NVM. Rewriting application code to use
a new API will not always be feasible or cost-effective. Yet, the
improved speed of NVM suggests that an API encompassing this new case
will be very welcome and may well be cost-effective to adopt.

In sum, far from being a stop-gap this proposal should be seen as a step
towards completing and maintaining the existing MBB API for emergent tech.

> To that end, one approach to explore is allowing the FC.map method
> accept map modes beyond those defined by MapMode. There is precedence
> for extensibility in this area already, e.g. FC.open allows you to
> specify options beyond the standard options specified by the method. It
> would require MapMode to define a protected constructor and would
> require a bit of plumbing to support MapMode defined in a JDK-specific
> module but there are examples to point to. Another approach is aanother
> class in a JDK-specific module to define the map method. It would
> require the same plumbing under the covers but would avoid touch the FC
> spec.
I'm not sure what this side-step is supposed to achieve nor how that
relates to the concerns over use of MBB (perhaps it doesn't). I'm not
really clear what problem you are trying to avoid here by allowing the
MapMode enum to be extensible via a protected constructor.

If your desire is to avoid adding extra API surface to FileChannel then
where would you consider it appropriate to add such a surface. Something
is going to have to create and employ the extra enum tags that are
currently proposed for addition to MapMode. How is a client application
going to reach that something?

Perhaps we might benefit form looking at a simple example? Currently, my
most basic test program drives the API to create an MBB as follows:

        . . .
        String dir = "/mnt/pmem/test"; // mapSync should work, since fs
mount is -o dax

        Path path = new File(dir, "pmemtest").toPath();

        FileChannel fileChannel = (FileChannel) Files
                .newByteChannel(path, EnumSet.of(
                        StandardOpenOption.READ,
                        StandardOpenOption.WRITE,
                        StandardOpenOption.CREATE));

        MappedByteBuffer mappedByteBuffer =
fileChannel.map(FileChannel.MapMode.READ_WRITE_PERSISTENT, 0, 1024);
        . . .

Could you give a sketch of an alternative way that you see a client
operating?

One thing I did wonder about was whether we could insert the relevant
behavioural switch in the call to Files.newByteChannel rather than the
map call?

If we passed an ExtendedOpenOption (e.g. ExtendedOpenOption.SYNC) to
this call then method newByteChannel could create and return a
corresponding variant of FleChannelImpl, say an instance of a subclass
called SyncFileChannelImpl. This could behave as per a normal
FileChannelImpl apart from adding the MAP_SYNC flag to the mmap call
(well, also rejecting PRIVATE maps).

Would that be a better way to drive this? Would it address the concerns
you raised above?

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