Regression in GZIPInputStream performance since JDK 23

[Patrick Strawderman]

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 <alan.bateman at oracle.com>
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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20260106/afcef03b/attachment.htm>