8245121: (bf) XBuffer.put(Xbuffer src) can give unexpected result when storage overlaps

[Paul Sandoz]

> On May 15, 2020, at 12:29 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Paul,
> 
>> On May 15, 2020, at 11:58 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>> That’s a pleasing result.
>> 
>> - because of the fall back to the loop for small thresholds when the byte order differsI believe the issue can still occur in some cases, correct? In this case we would alas still need to use an explicit temporary buffer for overlap, that’s annoying, so much so it might just be better to remove the threshold (perhaps given copying between different orders is less common)?
> 
> The fallback occurs only if the length is below the threshold *and* base != srcBase. If base != srcBase, then either one buffer is heap and one is direct, or both are heap but refer to different arrays. Because of this second check I don’t think the issue can occur.
> 

Doh, sorry I missed that.

As you say it might be worth performing some benchmark, and be more informed whether the fallback to the loop is necessary. 


>> - can we cleanup the sub-type implementations? For direct buffers I think we can uses the fences and call to super.
> 
> I’ll take a loop. It might be worth it to perform some benchmarking here.
> 
>> - for the test my preference would be to use a data provider to the combinatorial aspect, and you can avoid developing your own test logic for failure, and it’s easier to distinguish what combination of tests failed.
> 
> I did look over EqualsCompareTest. I came up with this approach as it seems to require less code although it is true that failures are not yet adequately described in the output. As a side note, this test has not yet found any failures when the backing memory of the two buffers is disjoint.
> 

Ok. Given the overrides I guess this code is only being hit for certain cases, namely the byte buffer views.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20200515/cb399702/attachment.htm>