<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><font face="monospace">Thank you Patrick for reporting this,
providing the JMH benchmark and also narrowing this down to the
actual root cause of the performance regression. A PR addressing
this regression has been proposed
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/pull/29092">https://github.com/openjdk/jdk/pull/29092</a> and with those changes
the JMH benchmark numbers are back to the JDK 22 levels (the one
without the JDK-7036144 change).<br>
<br>
If you have built the JDK project before and are interested in
trying out that proposed change, then it would be good to verify
that PR against your actual application too. Furthermore, if the
library/application which exposed this problem is public and
easy to build, then it would be good to know where it resides -
that might help us run some experiments whenever there are
future changes in this area.</font></p>
<p><font face="monospace">-Jaikiran </font></p>
<div class="moz-cite-prefix">On 07/01/26 3:55 am, Patrick
Strawderman wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAFyquk5NWUE-jttrJTjHnt5U_dxLp_4CgCq5vq9o2-io=0ZYhg@mail.gmail.com">
<div dir="ltr">
<div>I've created an issue to track this here: <a href="https://bugs.openjdk.org/browse/JDK-8374644" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8374644</a></div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Tue, Jan 6, 2026 at
11:29 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">alan.bateman@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> <br>
<br>
<div>On 06/01/2026 17:19, Patrick Strawderman wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><font face="monospace">Wanted to discuss
a performance regression I noticed here before
opening an issue since I'm somewhat surprised it's
flown under the radar and wanted a gut check.</font>
<div><font face="monospace"><br>
</font></div>
<div><font face="monospace">In an application that
does GZIP decoding from byte[] per request, I
noticed in a profile that these calls were
spending a lot of time in
Throwable#fill_in_stack_trace, something I hadn't
seen before. I found JDK-<tt style="box-sizing:border-box;font-size:12px">7036144
[1], and looking into the change I see that when
decoding a single GZIP message we now rely on
exceptions for control flow to detect the end of
input, which is likely the cause.</tt></font></div>
</div>
</blockquote>
<br>
I think you're right, the read of the next header could
handle end of stream to avoid the ZipException. We should
create an issue in JBS to look at this.<br>
<br>
-Alan<br>
<br>
<br>
<font face="monospace"><br>
</font> </div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>