On 16/01/2019 11:23, Andrew Dinn wrote:
Hi Alan/Brian,
I have finally been able to shelve other commitments and return to this
JEP (apologies for the hiatus).
https://openjdk.java.net/jeps/8207851
The JEP has been reviewed positively by Stuart Marks (core libs) and
Vladimir Kozlov (intrinsics). It has also been warmly welcomed by
several potential users in Red Hat and Intel (including, respectively,
Jonathan Halliday and Sandya Viswanathan both in cc).
I think the proposal is good as a short term/tactical solution,
especially as you were able to reduce the API surface down to new
FileChannel map modes. I think it can be looked at again once Project
Panama is further along and there is some notion of "memory region" that
is backed by NVM.
I skimmed through the current draft. In the most recent discussion then
I think we had converged on "SYNC" rather than "PERSISTENT", the
reasoning being that there is persistence already with regular file
mapped files, also it aligns with the MAP_SYNC flag to mmap. I don't
recall if the discussion on isPersistent concluded, that was more of a
naming issue and whether you include an isXXX method or not is not
critical to the proposal. The overload of the force method to specify a
range is a good addition, irrespective of the JEP.
One thing to clarify is the heading "Proposed Restricted Public JDK API
Changes". The proposal (and the early webrevs) exposed writebackMemory
in the internal Unsafe, not sun.misc.Unsafe, which I think is right.
This makes it a JDK internal API so it doesn't need to be in JEP.
Did you get any feedback on the Testing section? Given that the feature
needs special hardware then it will need commitment to test is on a
regular basis. It's a similar issue to the draft "JEP 337: RDMA Network
Sockets" where special hardware is needed to full test the feature. In
the case of JEP 337 then some testing with emulation is possible.
Vladimir and I have reviewed the JEP, it will need an area lead to
endorse, I think it can be Brian or Mikael in this case.
-Alan
