JDK-8352891 Performance improvements to ByteArrayOutputStream

[Engebretson, John]

  I certainly see the value in the unsynchronized variant and am happy to do that – but that isn’t sufficient to address the original problem of scaling the array.  MemoryOutputStream results in 3x improvement and eliminates the hard 2GB cap, and can replace custom logic in Tomcat, Spring, etc.  What’s our next move there?
  Thanks!  😊
     John

From: Alan Bateman <alan.bateman at oracle.com>
Sent: Thursday, April 3, 2025 3:18 AM
To: Engebretson, John <jengebr at amazon.com>; Markus KARG <markus at headcrashing.eu>; core-libs-dev at openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


On 02/04/2025 19:04, Engebretson, John wrote:

  Apologies, human error – here’s the message I intended:

  Thank you!  I’ve updated the PR accordingly and summarized the benchmarks in the description.  Here’s the short version:

  1.  For small payloads, unsynchronized and optimized versions are 2-4x faster than base
  2.  For large payloads, optimized version is 3x faster than base or unsynchronized

  I discovered a capacity-related incompatibility between ByteArrayOutputStream and MemoryOutputStream: the size() method returns int, but MemoryOutputStream can exceed that value.  I added range checking to size() and a new sizeAsLong() method… but it really makes me wonder MemoryOutputStream belongs as a subclass of ByteArrayOutputStream.  It now has two significant incompatibilities: ignoring the protected fields, and size restrictions.

The protected fields are only accessible to subclasses so it's not an issue. BAOS::toByteArray (in addition to size) means the entire content must fit into a byte[]. A sink capable of accumulating but bytes that this is a different API.

I think we should at least pursue ByteArrayOutputStream.unsynchronized(int cap) and work through the javadoc changes to allow that. It does not need to use buf, we have flexibility on how the bytes are buffered.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250403/78b8e683/attachment-0001.htm>