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


From: Alan Bateman <alan.bate...@oracle.com>
Sent: Wednesday, April 2, 2025 5:52 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 31/03/2025 16:51, Engebretson, John wrote:

  Alan – is this what you have in mind:

ByteArrayOutputStream.getInstance() // returns existing class
ByteArrayOutputStream.getUnsynchronizedInstance() // returns subclass of BAOS 
that overrides the synchronization
ByteArrayOutputStream.get<Scalable|Memory|Fast|Segmented>Instance() // returns 
the new class


BAOS has been synchronized since JDK 1.0. While undocumented, it's possible 
that existing code depends on this 30 year behavior so I think we are stuck 
with it.

The removal of biased locking has spurred on a few complaints that the class is 
needlessly synchronized. A static factory to return an unsynchronized BOAS 
would help but only if it isn't used with code that assumes all operations are 
synchronized. So I think we will have to look at the API docs for this.

It's not clear that we need to have several implementation with different 
performance tradeoffs. So I think part of the exploration will be to see what 
usages perform better or worse, and whether having a parameter to specify the 
initial size or some hint of the max size would help the discussion.

-Alan

Reply via email to