1234567: [REDO] JDK-8245121 (bf) XBuffer.put(Xbuffer src) can give unexpected result when storage overlaps

Paul Sandoz paul.sandoz at oracle.com
Tue Jun 2 17:37:08 UTC 2020


Changes to X-Buffer.java.template look good.

IIRC for buffer equals/compare tests I had a separate test case. Given the fallback to the loop (and StringCharBuffer being read only) a minimal test seems appropriate.

Paul.

> On Jun 1, 2020, at 5:30 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> 
>> On Jun 1, 2020, at 3:49 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>> Grrr… I should have realized this. When I added mismatch support I probably ran into similar issues with this outlier of an implementation.
> 
> I should have caught it as well.
> 
>> For mismatch I punted on the optimization, because the underlying storage of string might be in compact form, rather than in the same layout as char[]. I am sure its possible to support but I thought the effort was questionable. The same reasoning can apply here too.
> 
> I don’t think the effort worth it either.
> 
>> My inclination here is to generate conditional code that only applies for CharBuffer, and for the other implementations place in an assert on the conditions of null base and direct being true.
>> 
>> The CharBuffer implementation can use arc.charRegionOrder() returning null to drop into the sequential loop (same trick used for mismatch).
> 
> So modified: http://cr.openjdk.java.net/~bpb/8246282/ <http://cr.openjdk.java.net/~bpb/8246282/>webrev.01/
> 
> Thanks,
> 
> Brian

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


More information about the nio-dev mailing list