RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

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, InputStrea

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On Fri, Apr 11, 2025 at 10:50 AM Engebretson, John wrote: > 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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

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). -Johannes On Fri, Apr 11, 2025 at 11:47 AM Archie Cobbs wrote: > To try to loop back on my original point... > > Th

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

To try to loop back on my original point... The "underlying problem" that I think should be addressed by some new internal class (or suite of classes) is the "array builder" problem. This is where you're doing "append, append, append, ..., use read-only thereafter". Currently people use ArrayList

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On Fri, Apr 11, 2025 at 8:11 AM Engebretson, John wrote: > It seems like a good general-purpose list but I wouldn’t recommend it as a > direct replacement for either ArrayList or LinkedList; in the former case > the risk is slower random accesses, and in the latter the risk is to head > modificat

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

At the risk of repeating my previous comment , I agree with Chen. That is to say, there is a separate, more fundamental unsolved problem lurking underneath this discussion, and the two problem "layers" are perhaps better addr

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On 08/04/2025 13:51, Engebretson, John wrote:   Brian, Alan, Markus, Chen – thank you for your feedback on this issue!  At this point we seem to agree that 1) there is merit to this idea, 2) nobody loves a new public class (including me), and 3) this is not a subclass of ByteArrayOutputStream

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

Hi John Engebretson, I still wonder if we can make the byte array allocator a utility to the JDK, at least an internal one. I find that besides replacing BAOS uses, it can also optimize users like InputStream.readNBytes, BufWriterImpl of classfile, and maybe many more usages. Such an internal addit

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

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 On Apr 8, 2025, at 5:51 AM, Engebretson, John wrote: Are we

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

Brian, Alan, Markus, Chen – thank you for your feedback on this issue! At this point we seem to agree that 1) there is merit to this idea, 2) nobody loves a new public class (including me), and 3) this is not a subclass of ByteArrayOutputStream. Are we ready to move this to CSR and continue

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

Other than the read-only aspect, is ByteBuffer pretty close to the builder you are looking for? I would think a thin wrapper over a ByteBuffer might be a suitable alternative. Just a quick thought, I haven’t looked at any proposed code.ScottOn Mar 28, 2025, at 6:09 PM, Archie Cobbs wrote:This is

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

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.getInsta

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

I certainly see the value in the unsynchronized variant and am happy to do that – but that isn’t sufficient to address the original problem of scaling the array. MemoryOutputStream results in 3x improvement and eliminates the hard 2GB cap, and can replace custom logic in Tomcat, Spring, etc.

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

I did not notice that Alan’s comment below, about adding a hint as to the maximum expected size, has been specifically addressed anywhere in this discussion. It might not be all that pertinent to the main thread of discussion, however, but it would certainly be useful for the issue [1], which I

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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' ; Markus KARG

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On 02/04/2025 19:04, Engebretson, John wrote:   Apologies, human error – here’s the message I intended:   Thank you!  I’ve updated the PR accordingly and summarized the benchmarks in the description.  Here’s the short version: * For small payloads, unsynchronized and optimized versions are

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

Apologies, human error – here’s the message I intended: Thank you! I’ve updated the PR accordingly and summarized the benchmarks in the description. Here’s the short version: * For small payloads, unsynchronized and optimized versions are 2-4x faster than base * For large payloads

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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 i

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

Alan – is this what you have in mind: ByteArrayOutputStream.getInstance() // returns existing class ByteArrayOutputStream.getUnsynchronizedInstance() // returns subclass of BAOS that overrides the synchronization ByteArrayOutputStream.getInstance() // returns the new class Clearly naming ne

RE: JDK-8352891 Performance improvements to ByteArrayOutputStream

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 trad

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

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/

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

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,

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

Hi Scott, ByteBuffer can wrap and write into a byte[] array, but it doesn't know how to grow a new, larger array if the original array runs out of room. Also, ByteBuffer.array() provides "public" access to the underlying bytes, so the only way to make them read-only is to copy. FWIW here's

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

This is just a drive-by, opinion-saturated comment, so feel free to ignore... I think the missing puzzle piece here is slightly different/more general than "OutputStream into memory". IMHO what's really missing from the standard toolbox provided by the JDK is the byte equivalent of StringBuilder+S