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

Andrew Dinn adinn at redhat.com
Thu Sep 20 14:20:02 UTC 2018


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


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.

More information about the core-libs-dev mailing list