On a side note, profiling shows similar issues w/ expensive growth on the 
ArrayList class.  The same datastructure would optimize that growth… but it’s a 
far more complex implementation thanks to the random access and in-place 
insertion/removal.  In short, the opportunity is there but the tradeoffs are 
worse.
    John

From: core-libs-dev <core-libs-dev-r...@openjdk.org> On Behalf Of Markus KARG
Sent: Saturday, March 29, 2025 3:56 AM
To: 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.



Supporting what Alan said. Would love to see a static factory for a 
non-synchronized byte-array backed OutputStream, like 
`OutputStream::newByteArrayOutputStream`. John, if you like we can team up for 
authoring this, I have free capacity.
Am 29.03.2025 um 09:33 schrieb Alan Bateman:
On 28/03/2025 13:05, Engebretson, John wrote:

Hi all!  This message is to discuss the proposal for a public class that is 
faster/cheaper than ByteArrayOutputStream.  Details are on the ticket [1] so I 
will only summarize here:
- ByteArrayOutputStream is slower than the provided alternative, and wastes 
memory bandwidth and allocation.
- The new alternative cannot replace ByteArrayOutputStream because BAOS exposes 
two implementation-specific fields.
- The problem is broadly present, and different solutions exist in Spring, 
Tomcat, multiple applications inside my company, and undoubtedly elsewhere.
- There are places within the JDK that will benefit from the improved 
performance.

There are many possible directions and APIs that could be explored here, lots 
of fun.

The JBS issue seems to all about BAOS performance, esp. due to it maintaining a 
contiguous array and needing to resize. Rather than introduce a subclass into 
the API then maybe you instead explore adding a static factory that returns a 
BAOS with a different implementation. For a long time we've been mulling over 
adding a factory method to get a BAOS that isn't thread safe (the undocumented 
synchronization dates from JDK 1.0 and too risky to change after 30 years of 
usage). It would also be feasible to have BOAS use a different implementation 
when used directly vs. when subclassed although that wouldn't be pretty.

-Alan

Reply via email to