. Assuming
good results, we consider making it public in future releases.
Could I please get some form of signoff from the core team? I’d really like
to deliver something here soon, otherwise I have to move on.
Thank you very much! 😊
John
From: core-libs-dev On Behalf Of Engebretson
Thank you Alan! I’ll try to address each of your points, apologies if I miss
anything:
Maybe the two efforts should be separated.
I’m good with that, and will operate that way unless someone argues otherwise.
The factory methods can return a different implementation, in part
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
I thought about this over the weekend, and I think the byte[] variant and the
Object[] variant target separate problems: byte[] targets I/O patterns and
Object[]
targets Collections.
So my current mental model is:
public class java.io.VariableLengthByteArray {
// whatever views we want to sup
There is one form of array builder already in the JDK - Stream.builder(). This
doesn't cover off all of the use-cases, but covers some of them (notably not
the byte array case).
Thanks for pointing that out! Under-the-covers it relies on
java.util.stream.SpinedBuffer, which is built on the sam
I would like to see JDK standard "array builders" for primitive types and
reference types that use fixed sized (power-of-two) segments internally.
I want to caution on the power-of-two idea – it leads to large objects faster
than the current implementation, which hurts performance as well as max
I’m prototyping the generic allocator you describe and it’s extremely effective
for Objects – but I’m hamstrung by trying to use generics on primitive byte.
I’m not aware of a way to work around that, and changing the array from byte[]
to Byte[] would be a terrible idea, so I think we’re lookin
Thank you, appreciate the guidance! 😊 Will do.
John
You may of course do as you like, but as a matter of personal preference I
usually find it more expedient not to file a CSR until the discussion about
what it will contain has become quiescent in the PR itself.
Cheers,
Brian
Thank you Archie and Chen!
Chen - I’m prototyping the generic allocator you describe and it’s extremely
effective for Objects – but I’m hamstrung by trying to use generics on
primitive byte. I’m not aware of a way to work around that, and changing the
array from byte[] to Byte[] would be a
I think there is agreement that ByteArrayOutputStream.unsynchronized(int cap)
(or some such method) would be useful. It would not require using a contiguous
byte[] as the backing array so there is scope to experiment with
implementations that don't need to resize like the base BAOS does.
Extend
the API
discussion there?
Thank you very much! 😊
John
From: Engebretson, John
Sent: Monday, April 7, 2025 7:36 AM
To: 'Brian Burkhalter' ; core-libs-dev@openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to
ByteArrayOutputStream
Thank you Brian, I
Thank you Brian, I’m sorry I missed this point! The hint in this case is the
parameter on the overloaded constructor; if set high enough, the
initially-allocated buffer will guarantee exactly one array allocation with no
growth. This is identical to the ByteArrayOutputStream behavior describ
. What’s our next
move there?
Thanks! 😊
John
From: Alan Bateman
Sent: Thursday, April 3, 2025 3:18 AM
To: Engebretson, John ; Markus KARG
; core-libs-dev@openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance improvements to
ByteArrayOutputStream
CAUTION: This email originated
I’ve split the unsynchronized BAOS into its own issue, JDK-8353729, which
shows performance improvements on primitive writes. MemoryOutputStream remains
superior in that case and others.
John
From: Engebretson, John
Sent: Thursday, April 3, 2025 7:45 AM
To: 'Alan Bateman' ; M
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.
John
From: Engebretson, John
Sent: Wednesday, April 2, 2025 12:58 PM
To: '
Thank you! I’ve updated the PR accordingly and summarized the benchmarks in
the description. Here’s the short version:
From: Alan Bateman
Sent: Wednesday, April 2, 2025 5:52 AM
To: Engebretson, John ; Markus KARG
; core-libs-dev@openjdk.org
Subject: RE: [EXTERNAL] JDK-8352891 Performance
::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
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
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
19 matches
Mail list logo
