4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced

[Brian Burkhalter]

> On Feb 20, 2019, at 7:51 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> On Feb 19, 2019, at 11:00 PM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>> 
>> On 20/02/2019 01:20, Brian Burkhalter wrote:
>>> https://bugs.openjdk.java.net/browse/JDK-4833719 <https://bugs.openjdk.java.net/browse/JDK-4833719>
>>> 
>>> Provide covariant return type overrides for asReadOnlyBuffer(), compact(), duplicate(), and slice() [1]. If desirable, such overrides could also be provided for the bulk get() methods and the put*() methods.
>>> 
>> I don't have cycles to think about this one right now but I suspect this will require study to figure out if spec changes are needed. For example, we might have to clarify how force and loader should behave when invoked on a MBB that is a view or the result of a slice or duplicate.
> 
> Good point. I can investigate. Given the age of this issue it’s not pressing.

For a given page size, the pages mapped are determined by the buffer address and capacity only. These values are the same as in the parent for the buffers returned by asReadOnlyBuffer() and duplicate(). The method compact() returns ‘this’ so the same situation obtains in that case. The buffers returned by slice() and slice(index,length) however will have addresses {address + position(), address + index} and capacities {remaining(), length}, respectively. Consequently the ‘addr’ and ‘len’ values passed to the native methods, e.g., msync() and madvise(), could differ if force() or load() were invoked on a slice. So it does appear as if some specification verbiage would be needed to indicate that force() or load() invoked on a slice will cause writing or loading of only those pages that the slice overlaps. Would adding such verbiage to force() and load() be the appropriate change in the specification?

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190227/5c109ac2/attachment.html>