On 06/01/2026 17:19, Patrick Strawderman wrote:
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.
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-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.
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.
-Alan
