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

[Paul Sandoz]

Hi Brian,

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)?

- can we cleanup the sub-type implementations? For direct buffers I think we can uses the fences and call to super.

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

Paul.

> On May 15, 2020, at 11:33 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Please review the proposed fix [1] of the issue [2]. This replaces the “loopy” XBuffer.put(XBuffer src) fallback code
>     while (src.hasRemaining())
>         dst.put(src.get()); 
> with an implementation which behaves as if the source elements were first copied to a temporary array before being written into the target. The test fails before and passes after the implementation change is applied.
> 
> I am aware of the flagged and commented out sections in the test.
> 
> Thanks,
> 
> Brian
> 
> [1] http://cr.openjdk.java.net/~bpb/8245121/webrev.00/
> [2] https://bugs.openjdk.java.net/browse/JDK-8245121