JDK-8352891 Performance improvements to ByteArrayOutputStream

[Alan Bateman]

On 21/04/2025 17:46, Engebretson, John wrote:
>
> Following up on MemoryOutputStream, etc. – the conversation has 
> considered a few alternatives:
>
>
> 1. Hide the new class behind ByteArrayOutputStream.unsynchronized()
>
> 2. Create a new public class providing views to OutputStream, Channel, 
> InputStream
>
> 3. Something to do with an Object[] variant
>
>   I would personally reject any code review that used 
> “unsynchronized()” to describe this class, since that is only a minor 
> property of the change.  I could live with “scalable” or something 
> along those lines.
>
>   A new public class provides more capabilities than I initially 
> proposed, but of course requires a new public class. 😊
>
>   The Object[] variant is interesting but I have no pressing need for 
> it.  This probably gets a pin in it unless someone provides a use case.
>
>

Maybe the two efforts should be separated.

The removal of biased locking has shinned light on the synchronization 
in BAIS/BAOS. It's been there since JDK 1.0 and too risky to change. We 
need to decide whether to specify this long standing behavior. We also 
need to explore adding a factory method to both to obtain a stream that 
isn't thread safe. The factory methods can return a different 
implementation, in particular BAOS.unsynchronized (or whatever name it 
gets) does not need to collect the bytes in a contiguous array. So 
having a BAOS.unsynchronized may help with some of the scenarios that 
you are looking at.

I think the PR proposing MemoryOutputStream is a bit premature and it 
will take a bit more work, and prototypes, to get a handle on the 
problem and help inform if a standard API makes sense. A sink that can 
collect an unbounded number of bytes could be fun to try to optimize for 
different usages. What isn't clear from the exploration so far is how to 
interface to other APIs. A method to return a byte[], like 
BAOS::toByteArray, is problematic when the number of bytes don't fit in 
an int. Maybe you have explored a segment like API or a cursor or 
consumer API to handle the bytes?

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250422/7e1883f0/attachment.htm>