
<!DOCTYPE html><html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body>

    <br>

    <br>

    <div class="moz-cite-prefix">On 06/01/2026 17:19, Patrick

      Strawderman wrote:<br>

    </div>

    <blockquote type="cite" cite="mid:CAFyquk6Nf_pv4DvpVNoi_N2d2q6ta-aL-P0tArBidXLK7wAAYw@mail.gmail.com">

      

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

  </body>

</html>