RFR: 8316156: (ch) Channels.newOutputStream(ch).write(bigByteArray) allocates a lot of direct memory [v5]

[Paul Wagland]

On Mon, 18 Sep 2023 21:55:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> In `ChannelInputStream` and `ChannelOutputStream`, process small chunks of bytes in sequence to avoid running afoul of the `MaxDirectMemorySize`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316156: Revert Channel*Stream changes; add BAIS changes; replace test

> In [7ee65b9](https://github.com/openjdk/jdk/commit/7ee65b90fc6c8e48383a1f2c15626013529f6c3b) the `Channel{In,Out}putStream` changes are reverted and similar changes are implemented in `transferTo` for `BufferedInputStream` and `ByteArrayInputStream`. In retrospect, I doubt that the `BufferedInputStream` changes and concomitant test code are needed.

Doesn't this just fix only the reported problem though? If there is a InputStream out there that that can also drop a large buffer in, or even if there is code that just does a `channelOutputStream.write(largeBuffer)`, that this will still fail?

The main issue that I had when I reported the problem is that I can no longer safely use `Files.copy`, since it relies on the passedInputStream only doing "small" writes, at least in the face of a limited DirectMemory allocation. This fixes the particular InputStream that I was using, but doesn't fix the generic problem, which means that Files.copy is _still_ unsafe?

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

PR Comment: https://git.openjdk.org/jdk/pull/15733#issuecomment-1725161992