JDK-8352891 Performance improvements to ByteArrayOutputStream

[Markus KARG]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250329/05117c47/attachment.htm>