<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle30
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle31
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:900674142;
mso-list-template-ids:-388319348;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:2012487719;
mso-list-template-ids:2012650548;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"> 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.<o:p></o:p></p>
<p class="MsoNormal"> John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Engebretson, John <br>
<b>Sent:</b> Thursday, April 3, 2025 7:45 AM<br>
<b>To:</b> 'Alan Bateman' <alan.bateman@oracle.com>; Markus KARG <markus@headcrashing.eu>; core-libs-dev@openjdk.org<br>
<b>Subject:</b> RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> 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. What’s our next move there?<o:p></o:p></p>
<p class="MsoNormal"> Thanks! <span style="font-family:"Segoe UI Emoji",sans-serif">
😊</span><o:p></o:p></p>
<p class="MsoNormal"> John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Alan Bateman <<a href="mailto:alan.bateman@oracle.com">alan.bateman@oracle.com</a>>
<br>
<b>Sent:</b> Thursday, April 3, 2025 3:18 AM<br>
<b>To:</b> Engebretson, John <<a href="mailto:jengebr@amazon.com">jengebr@amazon.com</a>>; Markus KARG <<a href="mailto:markus@headcrashing.eu">markus@headcrashing.eu</a>>;
<a href="mailto:core-libs-dev@openjdk.org">core-libs-dev@openjdk.org</a><br>
<b>Subject:</b> RE: [EXTERNAL] JDK-8352891 Performance improvements to ByteArrayOutputStream<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" style="border-collapse:collapse">
<tbody>
<tr style="height:15.25pt">
<td width="1123" valign="top" style="width:842.35pt;border:solid #ED7D31 1.5pt;padding:0in 5.4pt 0in 5.4pt;height:15.25pt">
<p><strong><span style="font-family:"Calibri",sans-serif;background:#FFFF99">CAUTION</span></strong><span style="background:#FFFF99">: 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.</span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">On 02/04/2025 19:04, Engebretson, John wrote:<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> Apologies, human error – here’s the message I intended:<br>
<br>
Thank you! I’ve updated the PR accordingly and summarized the benchmarks in the description. Here’s the short version:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3">For small payloads, unsynchronized and optimized versions are 2-4x faster than base
<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3">For large payloads, optimized version is 3x faster than base or unsynchronized
<o:p></o:p></li></ol>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> I discovered a capacity-related incompatibility between ByteArrayOutputStream and MemoryOutputStream: the size() method returns int, but MemoryOutputStream can exceed that value. I added range checking to size() and a new 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.<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
The protected fields are only accessible to subclasses so it's not an issue. BAOS::toByteArray (in addition to size) means the entire content must fit into a byte[]. A sink capable of accumulating but bytes that this is a different API.<br>
<br>
I think we should at least pursue ByteArrayOutputStream.unsynchronized(int cap) and work through the javadoc changes to allow that. It does not need to use buf, we have flexibility on how the bytes are buffered.<br>
<br>
-Alan<o:p></o:p></p>
</div>
</div>
</body>
</html>