Ping! Could I please get a review of this latest version of the JEP? This includes responses to all previous comments with changes made both to the JEP and the draft implementation. I would like to get this into JDK12 if at all possible 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 On 10/09/18 19:05, Alan Bateman wrote:
On 20/08/2018 16:18, Andrew Dinn wrote:
Hi Alan,
Round 4:
I have redrafted the JEP and updated the implementation in the light of your last feedback:
JEP JIRA: https://bugs.openjdk.java.net/browse/JDK-8207851
Formatted JEP: http://openjdk.java.net/jeps/8207851
New webrev: http://cr.openjdk.java.net/~adinn/pmem/webrev.04/
The updated JEP looks much better.
I realize we've been through several iterations on this but I'm now wondering if the MappedByteBuffer is the right API. As you've shown, it's straight forward to map a region of NVM and use the existing API, I'm just not sure if it's the right API. I think I'd like to see a few examples of how the API might be used. ByteBuffers aren't intended for use by concurrent threads and I just wonder if the examples might need that. I also wonder if there is a possible connection with work in Project Panama and whether it's worth exploring if its scopes and pointers could be used to backed by NVM. The Risks and Assumption section mentions the 2GB limit which is another reminder that the MBB API may not be the right API.
The 2-arg force method to msync a region make sense although it might be more consistent for the second parameter to be the length than the end offset.
A detail for later is whether UOE might be more appropriate for implementations that do not support the XXX_PERSISTENT modes.
-Alan.