Regression in GZIPInputStream performance since JDK 23

[Alan Bateman]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260106/a5e7ea10/attachment.htm>