JDK-8352891 Performance improvements to ByteArrayOutputStream

[Chen Liang]

Hi John Engebretson,
I still wonder if we can make the byte array allocator a utility to the
JDK, at least an internal one. I find that besides replacing BAOS uses, it
can also optimize users like InputStream.readNBytes, BufWriterImpl of
classfile, and maybe many more usages. Such an internal addition may be
accepted to the JDK immediately because it has no compatibility impact and
does not need to undergo CSR review.

Chen Liang

On Wed, Apr 9, 2025 at 11:35 AM Engebretson, John <jengebr at amazon.com>
wrote:

> I think there is agreement that ByteArrayOutputStream.unsynchronized(int
> cap) (or some such method) would be useful. It would not require using a
> contiguous byte[] as the backing array so there is scope to experiment with
> implementations that don't need to resize like the base BAOS does.
>
> Extending BOAS means the size is limited to an int. To go beyond would be
> a different API and there is lots of scope to do experiments. I think too
> early to create a CSR for MOS, assuming this is what you mean.
>
>   Thank you Alan!  PR [1] is updated with the factory method as suggested;
> MOS is a package-private subclass of BAOS and the Javadoc in BAOS makes no
> promises about the implementation returned.  I allowed MOS to grow beyond
> 2GB and throw an intelligent error if it cannot service a particular call
> (toByteArray, size, etc.).  Performance is unchanged.  Feedback appreciated.
>
>   Thanks!  😊
>
>      John
>
>
>
> [1] https://github.com/openjdk/jdk/pull/24232
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250409/a6701591/attachment.htm>