8245121: (bf) XBuffer.put(Xbuffer src) can give unexpected result when storage overlaps
Brian Burkhalter
brian.burkhalter at oracle.com
Tue May 19 21:06:26 UTC 2020
Here [1] is an updated version of the proposed patch. This version adds fences to the X-Buffer version of put($TypeBuffer) and modifies the direct and heap implementations to call super.put().
Specification verbiage is also added:
* If this buffer and
* the source buffer share the same backing memory, then the result will
* be as if the source elements were first copied to an intermediate
* location before being written into this buffer.
If this work goes forward and this doc change is deemed necessary / worthwhile then a CSR will be filed.
Some benchmarks were run to measure the performance of putting the contents of direct, heap, direct view, swapped direct view, heap view, and swapped heap view IntBuffers into direct and heap IntBuffers. The results are at [2]. On the average the proposed version appears to perform better, sometimes substantially, than the current version. A notable exception is for writing views of a byte buffer into a heap IntBuffer for a very small capacity. One would expect that this is due to falling through to the loopy implementation for small copy lengths, but testing did not bear this out. Some more investigation might be needed here.
Thanks,
Brian
[1] http://cr.openjdk.java.net/~bpb/8245121/webrev.01
[2] http://cr.openjdk.java.net/~bpb/8245121/XBufferBench.csv
> On May 15, 2020, at 12:42 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
> As you say it might be worth performing some benchmark, and be more informed whether the fallback to the loop is necessary.
> On May 18, 2020, at 12:57 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> The approach looks reasonable but I suspect this will need a reachability fence for at least src (maybe this too, I need to page some of the details).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200519/0de498cc/attachment.htm>
More information about the nio-dev
mailing list