On 09/04/2019 19:15, Brian Burkhalter wrote:
>
>> On Apr 9, 2019, at 10:59 AM, Alan Bateman <alan.bate...@oracle.com
>> <mailto:alan.bate...@oracle.com>> wrote:
>>
>> There are a couple of implementation details to discuss
>
> I was wondering whether this topic has any synergy / overlap with this
> prior thread [1] the principal sticking point of which was IIRC forcing
> / loading a slice of a MBB.
>
> http://mail.openjdk.java.net/pipermail/nio-dev/2019-February/005871.html
Oh, bonus points for that question ;-)
Currently, for file-backed MBBs, forcing a slice of the MBB has no
effect. That happens because the slice is not provided with an fd when
it is cloned off the MBB. The same applies when creating a view over the
byte buffer memory using some other type e.g. as an int buffer. I don't
know exactly why that decision was made (avoiding profileration of fds?)
but anyway it is a fait accompli and it means you can only force writes
to a slice or view using the original MBB.
When creating a slice (or view) over an NVRAM-backed buffer the
situation is different. It would be perfectly possible for the
slice/view to record that it's originating MBB is backed by NVRAM
without needing to store the fd in the slice/view. It does store the
base address of the originating MBB and its own offset/scaling. So, it
could easily translate the force indices in its own coordinate system
into a corresponding region of the original byte buffer and then write
back the relevant cache lines in the original MBB byte address range.
Much as the above capability would be useful it would mean that
NVRAM-backed buffer slices/views had different semantics to file-backed
backed buffer slices/views. The prototype implementation I provided
earlier chose to follow the existing behaviour so as not to open up any
such difference.
I am interested to hear if anyone thinks the alternative choice is worth
pursuing. It would certainly make life easier for users of NVRAM-backed
buffers as it would enable them to use the new flush API to flush
regions using slice/view coordinates rather than translated coordinates
for the original byte buffer. However, providing this capability only
for NVRAM-backed buffers leaves the solution somewhat half-baked.
No doubt, existing users of file-backed MBB slices/views have already
worked round the current limitation by retaining a handle on the
original MBB and flushing it at suitable points using a full force()
call. However, those existing implementations will not have had to deal
with coordinate translation since the flush is indiscriminate. If they
wish to move to using this new region-based flush then they will have to
record and translate buffer coordinates. I would prefer this requirement
to be fully present or fully removed rather than imposing it for one
case but not the other.
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
