<div dir="ltr"><div>I've created an issue to track this here: <a href="https://bugs.openjdk.org/browse/JDK-8374644">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">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"><u></u>

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