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.bate...@oracle.com>
Sent: Thursday, April 3, 2025 3:18 AM
To: Engebretson, John <jeng...@amazon.com>; Markus KARG
<mar...@headcrashing.eu>; core-libs-dev@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
