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

[Alan Bateman]

On 26/09/2018 09:44, Andrew Dinn wrote:
> :
>> If you (collectively) are aware of this and other limitations, then
>> sure, let's proceed with this JEP.
> Well, I'm very happy to proceed if Alan is in agreement. One thing he
> suggested in an earlier post was splitting off the functionality to
> create a persistent ByteBuffer into a separate method so as to avoid any
> issues if we have to deprecate this model at a alter date. I think
> that's a quite reasonable precaution and I'd be happy to propose an
> alternative API or let Alan suggest one. Perhaps Alan can comment?
>
I'm reasonably happy with the approach that we converged on to introduce 
new map modes and use the existing FileChannel.map method. Ideally new 
map modes wouldn't need to be exposed but you've looked into that (to my 
satisfaction at least). One detail that I think may need another 
iteration or two on is whether we need one or two modes. This will 
become clearer once the javadoc is fleshed out a bit further. It maybe 
that one new map mode, "SYNC" for example, that works with the existing 
READ_WRITE mode may be clearer and easier to specify. I think that would 
be consistent with how copy-on-write mappings are exposed with the 
PRIVATE mode. It also provides a 1-1 mapping to the underlying MAP_SYNC 
flag too.

As regards the bigger topic on what the right API is for "memory" then I 
don't think ByteBuffer is the right answer. You've touched on a few of 
the issues in your mail but there are bigger issues around thread safety 
and confinement, also the issue of the buffer position/limit that get in 
the way and the reason why several libraries use Unsafe. There isn't any 
concrete proposal or discussion to point at around splitting out this 
aspect of Project Panama. Stuart and I just pointing out that a better 
solution could emerge which could lead to have an alternative API to map 
a region of NVM as "memory" rather than a mapped byte buffer. If I were 
developing a file system backed by NVM then that is probably the raw API 
that I would want, not MBB.

As regards introducing an API that we could deprecate then that musing 
was about introducing a JDK-specific API. If MapMode were an interface 
then we could have introduce a JDK-specific map mode that wouldn't have 
required rev'ing the standard API. Introducing a completely separate map 
method in a JDK-specific module doesn't seem to be worth it as I think 
we can be confident that the proposed and possible-new.future approaches 
will not conflict.

-Alan