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