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
