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


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.
> 


More information about the core-libs-dev mailing list