I've created an issue to track this here: https://bugs.openjdk.org/browse/JDK-8374644
On Tue, Jan 6, 2026 at 11:29 AM Alan Bateman <[email protected]> wrote: > > > 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 > > > >
