RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]

[Alan Bateman]

On Thu, 18 Feb 2021 20:35:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Reader.java line 221:
>> 
>>> 219:                     // if the last call to read returned -1 or the number of bytes
>>> 220:                     // requested have been read then break
>>> 221:                 } while (n >= 0 && remaining > 0);
>> 
>> The code for case that the char buffer has a backing array looks okay but I'm not sure about the direct buffer/other cases. One concern is that this is a read method, not a transferXXX method so we shouldn't be calling the underlying read several times. You'll see what I mean if you consider the scenario where you read < rem, then read again and the second read blocks or throws. I'l also concerned about "workBuffer" adding more per-stream footprint for cases where skip or read(CB) is used. Objects such as InputStreamReader are already a problem due to the underlying stream decoder.
>
> I think that's what @AlanBateman intended. The `skip()` changes would revert also (I think) but the C-style array changes can stay. Thanks.

Yes, let's keep bring it back to just eliminating the intermediate array when the buffer has a backing array. The other case that been examined separated if needed but we can't use the approach proposed in the current PR because it changes the semantics of read when there is a short-read followed by a blocking or exception throwing read.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915